43 aseguramiento de su red

631

Aseguramiento de su Red

43.1. Seguridad en las estaciones de trabajo La seguridad del ambiente Linux c omienza en la estac ión de trabajo. Bien sea que es té bloqueando

su propia máquina personal o asegurando un sistema corporativo, una buena política de seguridad

comienza con el computador personal. Después de todo, una red es tan segura como su nodo más

débil.

43.1.1. Evalua ndo la seguridad en la estación de trabajo

Cuando evalúe la seguridad de una estac ión de trabajo Red Hat Enterprise Linux, cons idere lo

siguiente:

• Seguridad del BIOS y del gestor de arranque — ¿Puede un usuario no autorizado acc eder

fís icamente a la máquina e iniciar una ses ión como usuario único o en modo de rescate sin una

contraseña?

• Seguridad de la contraseña — ¿Qué tan seguras son las cuentas de usuarios en la máquina?

• Controles administrativos — ¿Quién tiene una cuenta en el s is tema y cuánto control administrativo

tienen?

• Servicios de red disponibles — ¿Qué servic ios están escuc hando petic iones desde la red que

realmente deberían es tar en ejecuc ión?

• Cortafuegos personales — ¿Qué tipo de cortafuego o firewall, si existe, es necesario?

• Herramientas de comunicación para mejor seguridad — ¿Qué herramientas debería utilizar para

comunicarse entre estac iones de trabajo y cuáles se deberían evitar?

43.1.2. Seguridad del BIOS y del gestor de arranque

La protecc ión con contraseñas para el BIOS (o equivalentes al BIOS) y para el ges tor de arranque

pueden ayudar a prevenir el acceso físico a sus sistemas por parte de usuarios no autorizados.

Asimismo evita que los sistemas sean iniciados desde medios removibles o que se obtenga acceso

como root a través del modo monousuario. Sin embargo, las medidas de seguridad que uno debería

tomar para protegerse contra tales ataques dependen tanto de la confidencialidad de la informac ión

que las estac iones tengan como de la ubicac ión de la máquina.

For example, if a mac hine is used in a trade show and contains no sens itive information, then it may

not be critical to prevent such attac ks. However, if an employee's laptop with private, unencrypted

SSH keys for the corporate network is left unattended at that same trade show, it could lead to a major

security breach with ramifications for the entire company.

Por otro lado, si la es tac ión de trabajo está loc alizada en un lugar donde sólo los usuarios autorizados

o de confianza tienen acceso, entonces la seguridad del BIOS o del ges tor de arranque puede no ser

nec esaria.

632

Seguridad del BIOS y del gestor de arranque

43.1.2.1. Contraseñas del BIOS

Las dos razones bás ic as por las cuales se debe proteger la BIOS de una computadora con una

contraseña son1:

1. Prevenir cambios a las configuraciones del BIOS — Si un intruso tiene acceso a la BIOS, puede

configurarlo para que arranque desde un diskette o CD-ROM. Esto permite entrar en modo de

rescate o monousuario, lo que a su vez les permite plantar programas dañinos en el s istema o

copiar datos c onfidenc iales.

2. Prevenir el arranque del sistema — Algunas BIOSes le permiten proteger el proc eso de arranque

con una contraseña. Cuando está func ionalidad está activada, un atacante esta forzado a

introducir una contraseña antes de que el BIOS lanze el ges tor de arranque.

Bec ause the methods for setting a BIOS password vary betw een computer manufacturers, consult the

computer's manual for specific instructions.

Si olvida su contraseña del BIOS, usualmente es ta se puede rec onfigurar bien sea a través de los

jumpers en la tarjeta madre o desc onec tando la batería CMOS. Por esta razón, es una buena idea

bloquear el c has is del computador si es posible. Sin embargo, c onsulte el manual del computador o

tarjeta madre antes de proc eder a desc onec tar la batería CMOS.

43.1.2.1.1. Aseguramiento de plataformas di ferentes a x86

Otras arquitectura utilizan programas diferentes para llevar a cabo tareas de bajo nivel similares a

las del BIOS en sistemas x86. Por ejemplo, las computadoras basadas en Intel® Itanium™ utilizan la

shell Extensible Firmware Interface (EFI).

For instructions on password protecting BIOS-like programs on other architectures, refer to the

manufacturer's ins tructions.

43.1.2.2. Contraseñas del gestor de arranque

A continuac ión se muestran las razones princ ipales por las cuales se debe proteger el gestor de

arranque de Linux:

1. Previene el acceso en modo monousuario — Si un atac ante puede arranc ar en modo

monousuario, se convierte en el superusuario de forma automátic a sin que se le solicite la

contraseña de acceso.

2. Previene el acceso a la consola de GRUB — Si la máquina utiliza GRUB como el gestor de

arranque, un atac ante puede usar la interfaz del editor para cambiar su configuración o para

reunir información usando el c omando cat.

3. Previene el acceso a sistemas operativ os inseguros — Si es un s is tema de arranque dual, un

atac ante puede selecc ionar un sis tema operativo en el momento de arranque, tal como DOS, el

cual ignora los controles de acceso y los permisos de archivos.

Red Hat Enterprise Linux para la plataforma x86 se entrega con el ges tor de arranque GRUB.

Consulte el Manual de Instalac ión de Red Hat si desea una visión más profunda de GRUB.

Debido a que los sistem as BIOS varían de acuerdo al f abricante, p uede que alguno s no soporten la protección con co ntraseñ as

de ningún tipo, mientras que otros pueden soportar un tipo pero no el otro.

633


43.1.2.2.1. Protegiendo GRUB con contraseñas

You can configure GRUB to address the first two issues listed in Sección 43.1.2.2, “Contraseñas del

gestor de arranque” by adding a passw ord directive to its configuration file. To do this, first choose a

strong passw ord, open a shell, log in as root, and then type the following command:

/sbin/grub-md5-crypt

Cuando se le pida, escriba la c ontraseña GRUB y pres ione Intro. Esto retornará un hash MD5 para

la c ontraseña.

Luego, modifique el archivo de configurac ión GRUB /boot/grub/grub.conf. Abra el archivo y

debajo de la línea timeout en la secc ión principal del documento, añada la s iguiente línea:

password --md5 <password-hash>

Replace <password-hash> with the value returned by /sbin/grub-md5-crypt2.

La próxima vez que el s istema arranque, el menú de GRUB no le permitirá acc eder al editor o a la

interfaz de comandos si no pres iona primero p seguido por la contraseña de GRUB.

Lamentablemente, esta solución no previene a un atac ante arranc ar en un sistema operativo inseguro

si se está en un ambiente de arranque dual. Para esto, nec es ita editar una parte diferente del archivo

/boot/grub/grub.conf.

Busque la línea title del sis tema operativo inseguro y añada una línea que diga lock directamente

debajo de ella.

Para un sistema DOS, debería c omenzar con algo similar a:

title DOS loc k

Advertencia

Debe tener una línea password en la secc ión principal del archivo /boot/grub/

grub.conf para que este mec anismo funcione adec uadamente. De lo contrario,

un atacante podrá acceder a la interfaz del editor de GRUB y eliminar la línea de

bloqueo.

Para crear una contraseña diferente para un kernel o sistema operativo particular, añada una línea

lock, seguida por una línea de contraseña.

Cada entrada que proteja con una contraseña única debería c omenzar con líneas s imilares a las del

ejemplo siguiente:

title DOS lock password --md5 <password-hash>

GRUB also accepts unencrypted passwords, but it is recom m en ded that an MD5 hash be used for added security.

634


43.1.3. Seguridad de contraseñas

Passw ords are the primary method that Red Hat Enterpr ise Linux uses to verify a user's identity. This

is why password security is so important for protection of the user, the workstation, and the network.

Por razones de seguridad, el programa de instalac ión configura el s istema para usar el Message-

Digest Algorithm (MD5) y contraseñas shadow. Se rec omienda que no cambie esta c onfigurac ión.

Si quita la selecc ión de MD5 durante la instalac ión, se utilizará el formato Data Encryption Standard

(DES). Este formato limita las contraseñas a ocho caracteres alfanuméric os (no permite caracteres de

puntuac ión o espec iales) y proporc iona un modesto nivel de encriptac ión de 56-bits.

Si us ted deselecc iona las contraseñas shadow durante la ins talac ión, todas las contraseñas son

almac enadas como hash de una sola vía en el archivo /etc/passwd, lo que hace al sis tema

vulnerable a ataques de piratas fuera de línea. Si un intruso obtiene acc eso a la máquina como

un usuario regular, puede también copiar el archivo /etc/passwd a su propia máquina y ejecutar

cualquier cantidad de programas de desc ifrado de contraseñas contra él. Si hay una contraseña

insegura en el archivo, es cues tión de tiempo antes de que el maleante informático la desc ubra.

Las contraseñas shadow eliminan este tipo de ataques, almac enando los hash de las contraseñas en

el archivo /etc/shadow , el cual sólo es leído por el usuario root.

Esto obliga al atac ante potenc ial a intentar descubrir la c ontraseña remotamente mediante la conexión

a un servicio de la red en la máquina, tal como SSH o FTP. Este tipo de ataques de fuerza bruta son

mucho más lentos y dejan rastros obvios, pues los intentos fallidos de conexión son regis trados a los

archivos del s istema. Por supues to, si el maleante o crac ker comienza un ataque durante la noc he y

us ted tiene c ontraseñas débiles, éste podría obtener acceso antes del amanec er y editar el archivo de

registro para borrar sus rastros.

Además del formato y el almac enamiento, está el problema del contenido. Lo más importante que un

usuario puede hac er para proteger su cuenta contra un ataque de piratas, es crear una contraseña

robusta.

43.1.3.1. Creación de contraseñas robustas

Cuando se cree una contraseña segura, es una buena idea seguir las siguientes pautas :

• No utilice solamente palabras o números — Nunca debería utilizar únic amente letras o sólo

números en una contraseña.

Algunos ejemplos inseguros inc luyen:

• 8675309

• juan

• atrapame

• No utilice palabras reconocibles — Palabras tales como nombres propios, palabras del diccionario o

hasta términos de shows de televisión o novelas deberían ser evitados, incluso si utiliza números a l

final de éstos.


• john1

635

Seguridad de contraseñas

• DS-9

• mentat123

• No utilice palabras en idiomas extranjeros — Los programas de desc ifrado de c ontraseñas a

menudo verif ican listas de palabras que abarc an dicc ionarios de muchos idiomas. No es seguro

confiarse en un idioma extranjero para asegurar una c ontraseña.


• cheguevara

• bienvenue1

• 1dumbKopf

• No utilice terminología de hack ers — Si piensa que us ted pertenec e a una élite porque utiliza

terminología hacker — también llamado hablar l337 (LEET) — en su contraseña, piense otra vez.

Muc has listas de palabras incluyen lenguaje LEET.


• H4X0R

• 1337

• No utilice información personal — Mantengase alejado de la información personal. Si un atacante

conoc e quién es usted, la tarea de deducir su contraseña será aún más fácil. La lista siguiente

mues tra los tipos de información que debería evitar cuando es té creando una c ontraseña:


• Su nombre

• El nombre de sus masc otas

• El nombre de los miembros de su familia

• Fechas de cumpleaños

• Su número telefónico o código pos tal

• No invierta palabras reconocibles — Los buenos verif ic adores de contraseñas s iempre invierten las

palabras c omunes ; por tanto, invertir una mala contraseña no la hace para nada más segura.


• R0X4H

• nauj

• 9-DS

• No escriba su contraseña — Nunca guarde su contraseña en un papel. Es mucho más seguro

memorizarla.

636


• No utilice la misma contraseña para todas las máquinas — Es importante que c ada máquina tenga

una contraseña diferente. De esta forma, si un sistema es comprometido, no todas sus máquinas

estarán en peligro inmediato.

Las siguientes pautas lo ayudarán a crear una contraseña robusta:

• Cree contraseñas de al menos ocho caracteres — Mientras más larga sea la c ontraseña, mejor. Si

está usando contraseñas MD5, debería ser de 15 caracteres de largo o más. Con las contraseñas

DES, use el largo máximo (ocho caracteres).

• Mezcle letras mayúsculas y minúsculas — Red Hat Enterprise Linux distingue entre mayúsc ulas y

minúsculas, por la tanto mezc le las letras para reforzar su contraseña.

• Mezcle letras y números — Agregando números a las contraseñas, espec ialmente c uando se

añaden en el medio (no solamente al comienzo o al final), puede mejorar la fortaleza de su

contraseña.

• Include Non-Alphanumeric Characters — Spec ial c haracters such as &, $, and > can greatly

improve the strength of a passw ord (this is not possible i f using DES passw ords).

• Seleccione una contraseña que pueda recordar — La mejor c ontraseña en el mundo será de poc a

utilidad si usted no puede recordarla. Por lo tanto utilice acrónimos u otros dispos itivos nemónic os

que lo ayuden a memorizar las contraseñas.

Con todas es tas reglas, puede parec er difícil crear una contraseña que reuna todos estos requis itos

y evite, a la vez, los rasgos de las malas c ontraseñas. Afortunadamente, hay algunos pasos que uno

puede tomar para generar una c ontraseña segura y fácil de rec ordar.

43.1.3.1.1. Metodología para la creación de contraseñas seguras

Hay muc hos métodos que la gente utiliza para crear contraseñas seguras. Uno de los métodos más

populares incluyen acrónimos. Por ejemplo:

• Piense en una frase memorable, tal como:

"over the river and through the woods, to grandmother's house we go."

• Luego, cámbielo a un acrónimo (inc luyendo la puntuac ión).

otrattw,tghwg.

• Añada un poco de complejidad sustituyendo números y símbolos por letras en el acrónimo. Por

ejemplo, sustituya7 por e y el símbolo arroba ( @) por c:

o7r@77w,7ghwg.

• Añada un poco más de complejidad coloc ando mayúscula al menos a una letra, tal como M.

o7r@77w,7gHwg.

• Por último, no utilice esta contraseña de ejemplo en ninguno de sus sistemas.

Mientras que la creac ión de contraseñas seguras es imperativo, manejarlas adec uadamente

es también importante, espec ialmente para los administradores de sistemas dentro de grandes

organizac iones. La próxima secc ión detalla buenos hábitos en la creac ión y manejo de contraseñas

de usuarios dentro de una organizac ión.

mailto:o7r@77w

mailto:o7r@77w

637


43.1.3.2. Creación de cuentas de usuario dentro de la organización Si hay

un número signif icativo de usuarios dentro de una organizac ión, los administradores de s istemas

tienen dos opciones bás ic as disponibles para forzar el uso de buenas contraseñas. Ellos pueden

crear contraseñas para el usuario o dejar que los usuarios c rean sus propias c ontraseñas, a

la vez que verifican que las contraseñas sean de calidad ac eptable.

Al crear las contraseñas para los usuarios se asegura de que las contraseñas sean buenas, pero se

vuelve una tarea agotadora a medida que la organizac ión crec e. También incrementa el r iesgo de que

los usuarios escriban sus contraseñas en papel.

Por estas razones, la mayoría de los administradores de sis temas prefieren dejar que los usuarios

creen sus propias c ontraseñas, pero verifican de una forma activa que las contraseñas sean buenas

y, en algunos c asos, obligan a los usuarios a cambiarlas periódic amente hac iéndolas c aduc ar.

43.1.3.2.1. Forzar la creación de contraseñas robustas

To protect the network from intrusion it is a good idea for system administrators to verify that the

passw ords used within an organization are strong ones. When users are asked to create or change

passw ords, they can use the command line application passwd, which is Pluggable Authentication

Manager (PAM) aw are and therefore chec ks to see if the passw ord is too short or otherw ise easy

to crack. This check is performed using the pam_cracklib.so PAM module. Since PAM is

customizable, it is poss ible to add more passw ord integrity chec kers, such as pam_passwdqc

(available from http://www.openwall.com/passwdqc/) or to write a new module. For a list of available

PAM modules, refer to http://www.kernel.org/pub/linux/libs/pam/modules.html. For more information

about PAM, refer to Sección 43.4, “Pluggable Authentication Modules (PAM)”.

Sin embargo, es importante resaltar que la verificación realizada en las contraseñas al momento de

su creac ión, no desc ubren las malas c ontraseñas de forma tan efectiva como lo haría un programa

espec íf ico para desc ifrado ejec utado sobre las contraseñas dentro de la organizac ión.

Hay muc hos programas de desc ifrado de contraseñas que corren bajo Red Hat Enterprise Linux,

aunque ninguno es suministrado con el sistema operativo. Abajo se muestra una breve lista de

algunos de los programas de desc ifrado de contraseñas más populares :

Nota

Ninguna de estas herramientas son suministradas con Red Hat Enterprise Linux y,

por lo tanto, no son soportadas por Red Hat, Inc. de ninguna manera.

• John The Ripper — Un programa rápido y flexible de desc ifrado de contraseñas. Permite el uso

de múltiples listas de palabras y es capaz de usar descifrado de c ontraseñas con fuerza bruta. Está

disponible en http://www.openwall.com/john/.

• Crack — Perhaps the most well known passw ord cracking software, Crack is also very fast, though

not as easy to use as John The Ripper. It can be found online at http://www.openwall.com/john/.

• Slurpie — Slurpie es similar a John The Ripper y a Crack excepto que está diseñado para

ejec utarse en varias máquina s imultáneamente, creando un ataque de contraseñas distribuido. Se

puede enc ontrar junto a otros grupos de herramientas de evaluac ión de ataques distr ibuidos a la

seguridad en http://www.ussrback.com/distributed.htm.

http://www.openwall.com/passwdqc/

http://www.kernel.org/pub/linux/libs/pam/modules.html

http://www.openwall.com/john/

http://www.openwall.com/john/

http://www.ussrback.com/distributed.htm

638


Advertencia

Siempre obtenga autorizac ión por escrito antes de intentar descifrar las contraseñas

dentro de la organizac ión.

43.1.3.2.2. Envejeci miento de las contraseñas

El envejec imiento de contraseñas es una técnic a utilizada por los administradores de sistemas para

defenderse de las malas contraseñas dentro de la organizac ión. El envejec imiento de contraseñas

significa que luego de un tiempo determinado (usualmente 90 días) se le pide al usuario que creee

una nueva contraseña. La teoría detrás de esto es que si un usuario es forzado a cambiar su

contraseña periódic amente, una c ontraseña que ha sido desc ifrada por un cracker sólo le es útil

por un tiempo determinado. La desventaja del envejec imiento de contraseñas, es que los usuarios

tienden a escribir sus contraseñas.

Existen dos programas princ ipales usados para espec if ic ar la caduc idad de contraseñas bajo Red Hat

Enterprise Linux, el comando chage o la aplic ac ión gráfica Gestor de usuarios (system-config-

users).

The -M option of the chage command spec if ies the maximum number of days the password is valid.

For example, to set a user's passw ord to expire in 90 days, use the following command:

chage -M 90 <userna m e>

In the above c ommand, replac e <username> with the name of the user. To disable passw ord

expiration, it is traditional to use a value of 99999 after the -M option (this equates to a little over 273

years).

También puede utilizar el c omando chage en modo interactivo para modificar múltiples

envejec imientos de contraseñas y otros detalles de la c uenta. Utilice el s iguiente comando para entrar

en modo interactivo:

ch age <userna m e>

El s iguiente es un ejemplo de una ses ión interactiva utilizando es te c omando:

[root@interch-dev1 ~]# chage davido

Changing the aging information for davido

Enter the new value, or pre ss ENTER for the default

Minimum Password Age [0]: 1 0

Maximum Password Age [99999]: 90

Last Password Change (YYYY-MM-DD) [2006-08-18]:

Password Expiration W arnin g [7]:

Password Inac tive [-1]:

Account Expiration Date (YYYY-MM-DD) [1969-12-31]:

[root@interch-dev1 ~]#

Consulte las páginas man de chage para obtener información sobre las opc iones disponibles.

mailto:root@interch-dev1

mailto:root@interch-dev1

639

Controles administrativos

También puede utilizar la aplic ac ión gráfica Gestor de usuarios para crear políticas de

envejec imiento de contraseñas. Tenga en cuenta que us ted nec es itará privilegios administrativos para

utilizar este proc edimiento.

1. En el panel, haga clic en Siste ma, vaya a Administración y haga clic en Usuarios y grupos

para iniciar el Ges tor de usuarios. También puede escribir el c omando system-config-users

en el intérprete de comandos.

2. Haga clic en la pestaña Usuarios y selecc ione el usuario requerido en la liste de usuarios.

3. Haga clic en Propie da des en la barra de herramientas para ver las propiedades de usuario (o

esc oja Propie da des en el menú Archivo).

4. Luego haga clic en la pestaña Información de la contraseña y selecc ione la casilla para Activar

expiración de contrase ña.

5. Introduzc a el valor requerido en el c ampo Días re que ridos antes de cambiar y haga clic en OK.

Figura 43.1. Espec if ic ando las opc iones de envejec imiento de contraseñas

43.1.4. Controles administrativos

When adminis tering a home machine, the user must perform some tasks as the root user or by

acquiring effective root privileges via a setuid program, such as sudo or su. A setuid program is one

that operates with the user ID (UID) of the program's owner rather than the user operating the

program. Such programs are denoted by an s in the owner section of a long format listing, as in the

following example:

640


-rwsr -xr-x 1 root root 47324 May 1 08:09 /bin/su

Nota

La s puede es tar en mayúsc ulas o minúsc ulas. Si aparece en mayúsc ulas signif ic a

que el bit de permisos no ha sido establec ido.

For the system administrators of an organization, however, choic es must be made as to how much

administrative access users within the organization should have to their machine. Through a PAM

module called pam_console.so, some activities normally reserved only for the root user, such as

rebooting and mounting removable media are allowed for the first user that logs in at the phys ical

console (refer to Sección 43.4, “Pluggable Authentication Modules (PA M)” for more information about

the pam_console.so module.) However, other important system administration tasks, such as

alter ing network settings, configuring a new mouse, or mounting network devic es, are not poss ible

without administrative privileges. As a result, system administrators must dec ide how much access the

users on their network should receive.

43.1.4.1. Permitir el acceso como root

Si los usuarios dentro de la organizac ión son de confianza y saben de computac ión, entonc es darles

acceso root quizás no sea una mala idea. Permitir el acceso root a los usuarios significa que los

pequeños problemas, tales como añadir dispos itivos o configurar interfac es de red, pueden ser

manejados por los usuarios individuales, dejando a los administradores de s is temas libres para

manejar la seguridad de la red y otras cosas de mayor importancia.

Por otro lado, dar acceso de superusuario a usuarios individuales puede conllevar a los siguientes

problemas :

• Configuración errónea de las máquinas — Los usuarios con acceso root pueden configurar las

máquinas de forma errónea y luego nec es itar as is tenc ia o peor aún, abrir huec os de seguridad s in

saberlo.

• Ejecutar servicios inseguros — Los usuarios con acceso root pueden correr servic ios inseguros en

sus máquinas, tales como FTP o Telnet, coloc ando potenc ialmente los nombres de usuarios y sus

contraseñas en riesgo. estos servic ios transmiten la información a través de la red en texto llano.

• Ejecutar anexos de correo electrónico como root — Aún cuando es muy raro, si existen viruses qu e

afectan Linux. La única vez en que se convierten en una amenaza, es cuando son ejec utados por e l

usuario root.

43.1.4.2. Desactivación del acceso root

If an administrator is uncomfortable allowing users to log in as root for these or other reasons, the root

passw ord should be kept secret, and access to runlevel one or single user mode should be disallowed

through boot loader password protection (refer to Sección 43.1.2.2, “Contraseñas del gestor de

arranque” for more information on this topic.)

Tabla 43.1, “Métodos para deshabilitar la cuenta root” desc ribes ways that an administrator can further

ensure that root logins are disallowed:

641


Método De scripción Efe ctos No afe cta

Cambiar

el shell de

root.

Modifique el archivo /etc/

pass wd y c ambie el shell

de /bin/bash a /sbin/

nologin.

Previene el acceso a la

shell de root y registrar

cualquier intento de

hacerlo.

Se previene el acceso a la

cuenta root a los siguientes

programas:

· login

· gdm

· kdm

· xdm

· su

· ssh

· scp

· sftp

Programas que no

requieren una shell, como

clientes FTP, clientes de

correo y varios programas

setuid.

A los siguientes programas

no se les previene el

acceso a la cuenta root:

· sudo

· clientes FTP

· Clientes de correo-e

Deshabilitar Un archivo /etc/

Prevenir el acceso a la

Los programas que no

el acceso

root a

través de

cualquier

dispos itivo

de

consola

(tty).

securetty vacío

previene la conexión

como root en cualquier

dispositivo conectado a la

computadora.

cuenta root a través de

la consola o la red. A los

siguientes programas se

les previene el acceso a la

cuenta root:

· login

· gdm

· kdm

· xdm

· Otros servic ios de red que

abren una tty

inician una ses ión como

root pero que ejec utan

tareas de administrac ión

a través de setuid u otros

mec anismos.

A los siguientes programas

no se les previene el

acceso a la cuenta root:

· su

· sudo

· ssh

· scp

· sftp

Deshabilitar Modifique el archivo /

conexiones etc/ssh/sshd_config

Previene el acceso a root

a través del conjunto de

Esto sólo previene el

acceso root al conjunto de

root SSH.

Utilizar

PAM para

limitar el

acceso a

servic ios

desde

root.

y configure el parámetro

PermitRootLogin a no. Edit the file for the

target servic e in

the /etc/pam.d/

directory. Make sure the

pam_listfile.so is

required for authentication.1

herramientas OpenSSH. A

los siguientes programas

se les previene el acceso a

la c uenta de root:

· ssh

· scp

· sftp

Prevenir el acceso a root

a los servic ios de red que

rec onoc en PA M.

A los siguientes servic ios

se les previene el acceso a

la cuenta root:

· clientes FTP

· Clientes de correo-e

· login

· gdm

herramientas OpenSSH.

Programas y servic ios que

no reconozc an PAM.

642


Método De scripción Efe ctos No afe cta

· kdm

· xdm

· ssh

· scp

· sftp

· Cualquier servicio que

rec onozc a PAM

Refer to Sección 43.1.4.2.4, “Deshabilitar root utilizando PAM” for details.

Tabla 43.1. Métodos para deshabilitar la cuenta root

43.1.4.2.1. Deshabilitar el shell de root

To prevent users from logging in directly as root, the system administrator can set the root account's

shell to /sbin/nologin in the /etc/passwd file. This prevents acc ess to the root account through

commands that require a shell, such as the su and the ssh commands.

Importante

Los programas que no requieren acc eso al shell, tales como los clientes de correo

electrónic o o el c omando sudo, aún pueden tener acceso a la cuenta root.

43.1.4.2.2. Deshabilitar las sesiones root

To further limit access to the root account, administrators can disable root logins at the console by

editing the /etc/securetty file. This file lists all devic es the root user is allowed to log into. If the

file does not exist at all, the root user can log in through any communication device on the system,

whether via the console or a raw network interface. This is dangerous, bec ause a user can log in to

his mac hine as root via Telnet, which transmits the passw ord in plain text over the network. By default,

Red Hat Enterprise Linux's /etc/securetty file only allows the root user to log in at the console

physically attac hed to the machine. To prevent root from logging in, remove the contents of this file by

typing the following command:

echo > /etc/securetty

Advertencia

Un archivo /etc/securetty en blanco no previene al usuario root conectarse

remotamente usando el conjunto de herramientas OpenSSH, ya que la consola no se

abre sino hasta después de que se obtenga la autentic ac ión.

43.1.4.2.3. Deshabilitar conexiones root SSH

To prevent root logins via the SSH protocol, edit the SSH daemon's configuration file (/etc/ssh/

sshd_config). Change the line that reads :

# PermitRootLogin yes

643


para que diga lo siguiente:

P erm it Ro o t Lo gin n o

43.1.4.2.4. Deshabilitar root utilizando PAM

PAM, a través del módulo /lib/security/pam_listfile.so, otorga gran flexibilidad en negar

cuentas espec íf ic as. Esto permite al administrador apuntar el módulo a una lista de usuarios que

no tienen derec ho a conec tarse. Abajo se muestra un ejemplo de cómo el módulo es usado por el

servidor FTP vsftpd en el archivo de configuración PAM /etc/pam.d/vsftpd (el c arac ter \ al final

de la primera línea en el ejemplo s iguiente no es necesario si la directiva esta en una sola línea):

auth required /lib/security/pam_listfile.so item=user \

sense=deny file=/etc/vsftpd.ftpusers onerr=succeed

Esto le dice a PAM que consulte el archivo /etc/vsftpd.ftpusers y que niegue el acc eso al

servicio a cualquier usuario que esté listado allí. El administrador tiene la libertad de cambiar el

nombre de este archivo y de mantener una lista separada para cada servicio o de usar una lista

central para negar el acceso a múltiples servic ios.

Si el administrador desea negar el acceso a múltiples servic ios, se puede añadir una línea similar a

los servic ios de configurac ión PAM, tales como /etc/pam.d/pop y /etc/pam.d/imap para los

clientes de correo o /etc/pam.d/ssh para los clientes SSH.

For more information about PAM, refer to Sección 43.4, “Pluggable Authentication Modules (PAM)”.

43.1.4.3. Limitar el acceso root

En vez de negar completamente el acceso al superusuario, el administrador puede permitir el acceso

solamente a través de programas setuid, tales como su o sudo.

43.1.4.3.1. El comando su

Después de ejecutar el comando su, se le solicita al usuario la c ontraseña de root y, luego de la

autentic ac ión, se le presenta un intérprete de comandos de shell.

Una vez conec tado a través de su, el usuario se convierte en el superusuario y tiene acceso

adminis trativo absoluto al s istema3. Además, una vez que el usuario obtiene acc eso root es posible,

en algunos c asos, usar el comando su para cambiarse a cualquier otro usuario en el s is tema sin que

se le solicite una c ontraseña.

Debido a que este programa es tan poderoso, los administradores dentro de la organizac ión pueden

desear limitar el acceso a este c omando.

Una de las formas más fáciles de hac er esto es añadir usuarios al grupo administrativo espec ial

llamado wheel. Para añadir los, esc riba el s iguiente c omando como root:

usermod -G wheel <userna m e>

Este acceso est á sujeto a las restricciones imp uestas por SELinux, si éste está act iv ado.

644


In the previous c ommand, replac e <username> with the username you want to add to the wheel

group.

También puede utilizar el Gestor de usuarios para modificar las membres ías a grupos. Tenga en

cuenta que nec es itará privilegios administrativos para ejecutar es te proc edimiento.

1. En el panel, haga clic en Siste ma, vaya a Administración y haga clic en Usuarios y grupos

para iniciar el Ges tor de usuarios. También puede escribir el c omando system-config-users

en el intérprete de comandos.

2. Haga clic en la pestaña Usuarios y selecc ione el usuario requerido en la liste de usuarios.

3. Haga clic en Propie da des en la barra de herramientas para ver las propiedades de usuario (o

esc oja Propie da des en el menú Archivo).

4. Click the Groups tab, selec t the check box for the wheel group, and then click OK. Refer to

Figura 43.2, “Adding users to the "wheel" group.”.

5. Luego, abra el archivo de configurac ión PAM para su (/etc/pam.d/su) en un editor de texto y

elimine el caracter de comentario # desde la línea s iguiente:

auth required /l ib/secur ity/$ISA/pa m_wheel.so use_uid

Este cambio significa que sólo los miembros del grupo administrativo wheel pueden utilizar el

programa.

Figura 43.2. Adding users to the "wheel" group.

645


Nota

El usuario root es parte del grupo wheel por defecto.

43.1.4.3.2. El comando sudo

El c omando sudo ofrece otra solución para otorgar acceso administrativo a los usuarios. Cuando un

usuario de confianza antecede un comando adminis trativo con sudo, se le pide su propia contraseña.

Luego, una vez autentic ado y asumiendo que el comando es permitido, el comando administrativo es

ejec utado como que si se tratase del usuario root.

El formato bás ic o del comando sudo es el s iguiente:

sudo <com ma nd >

In the above example, <command> would be replac ed by a command normally reserved for the root

user, such as mount.

Importante

Los usuarios del c omando sudo deberían tener cuidado adicional al desconectarse

antes de abandonar sus máquinas puesto que otros pueden utilizar el comando

nuevamente sin que se les solicite contraseña alguna por un período de hasta c inco

minutos. Esta configurac ión se puede alterar a través del archivo de configurac ión, /

etc/sudoers.

The sudo c ommand allows for a high degree of f lexibility. For instanc e, only users listed in the /etc/

sudoers configuration f ile are allowed to use the sudo c ommand and the command is exec uted in

the user's shell, not a root shell. This means the root shell can be completely disabled, as shown in

Sección 43.1.4.2.1, “Deshabilitar el shell de root”.

The sudo c ommand also provides a comprehens ive audit trail. Each successful authentic ation is

logged to the file /var/log/messages and the command issued along with the issuer's user name is

logged to the file /var/log/secure.

Otra ventaja del comando sudo es que un adminis trador puede permitir a usuarios diferentes acceso

a comandos específ ic os basado en sus necesidades.

Los administradores que deseen modificar el archivo de configurac ión de sudo, /etc/sudoers,

deberían usar el comando visudo.

Para otorgarle a un usuario privilegios administrativos completos, escriba visudo y añada una línea

similar a la siguiente en la secc ión de espec if icac ión de privilegios del usuario:

juan ALL=(ALL) ALL

Este ejemplo es tablec e que el usuario, juan, puede utilizar sudo desde c ualquier máquina y ejec utar

cualquier c omando.

646


El ejemplo dado a continuac ión muestra qué tan detallado puede llegar a ser la configurac ión de

sudo:

%users localhost=/sbin/shutdown -h now

Este ejemplo es tablec e que cualquier usuario puede emitir el comando /sbin/shutdown -h now

siempre y cuando sea emitido desde la consola.

La página de manual para sudoers tiene un listado detallado de las opc iones para este arc hivo.

43.1.5. Servicios de red disponibles

Mientras que el acceso de usuarios a los controles adminis trativos es un aspecto importante para

los adminis tradores de s istemas dentro de una organizac ión, también es de suma importanc ia para

el que instala o maneja un s istema Linux mantener un registro sobre c uáles servic ios de red están

activos.

Muchos servicios bajo Red Hat Enterprise Linux se c omportan como servidores de red. Si un servic io

de red está ejecutándose en una máquina, entonc es hay una aplic ación de servidor (llamada

demonio) esc uc hando por conexiones en uno o más puertos de red. Cada uno de estos servidores

debería ser tratado como una avenida potenc ial de ataque.

43.1.5.1. Riesgos a los servicios

Los servicios de red pueden implicar muc hos r iesgos para los sis temas Linux. Abajo se muestra una

lista de algunos de los princ ipales problemas :

• Ataques de rechazo de servicio (Denial of Service, DoS) — Inundando un servicio con petic iones se

puede producir un ataque de rechazo de servicio que llevaría al s is tema a un estado suspendido,

mientras éste intenta responder a c ada petic ión.

• Ataques de vulnerabilidad de scripts — Si un servidor esta usando scripts para ejec utar acc iones

del lado del servidor, como usualmente hac en los servidores Web, un pirata puede montar

un ataque a los scripts que no hayan sido escritos de forma apropiada. Es tos ataques de

vulnerabilidad de scripts podrían llevar a una condición de desbordamiento del buffer o permitir al

atacante alterar archivos en el s istema.

• Ataques de desbordamiento del buffer — Los servic ios que se conectan a puertos del 0 al

1023 deben ser ejec utados como un usuario administrativo. Si la aplicac ión tiene un pos ible

desbordamiento del buffer, un atacante podría ganar acceso al s is tema como el usuario ejec utando

el demonio. Debido a que los desbordamientos del buffer existen, los maleantes informáticos usan

herramientas automatizadas para identif icar vulnerabilidades en los sis temas y una vez que han

obtenido acceso, utilizan kits automatizados para mantener su acceso al sis tema.

647

Servic ios de red disponibles

Nota

ExecShield puede mitigar las amenazas de un desbordamiento de la memoria

intermedia en Red Hat Enterprise Linux. Exec Shield es un ejecutable de

segmentac ión de memoria y una tec nología de protecc ión soportado por los kernels

en uni o multi-proc esadores x86. ExecShield reduce el riesgo del desbordamiento

de memoria intermedia al separar la memoria virtual en segmentos ejec utables y no

ejecutables. Cualquier código de programa que trate de ejec utarse en el segmento

ejec utable (como por ejemplo, código malicioso inyectado desde un ataque de

memoria intermedia) disparará una falla de segmentac ión y se cerrará.

ExecShield también incluye el soporte para la tec nología No eXecute (NX) en las

plataformas AMD64 y la tec nología eXecute Disable (XD), en los sistemas Itanium

y s istemas de 64 bits de Intel®. Estas tecnologías func ionan en conjunto con

ExecShield para prevenir que el código malicioso se ejecute en la porción ejecutable

de la memoria virtual con una granularidad de 4KB de código ejec utable, reduc iendo

el riesgo de un ataque desde un desbordamiento de búfer.

Tip

Para limitar la expos ic ión de ataques sobre la red, se deberían apagar todos los

servic ios que no se estén usando.

43.1.5.2. Identificación y configuración de servicios

Para mejorar la seguridad, la mayoría de los servic ios de red ins talados con Red Hat Enterprise Linux

es tán desac tivados por defecto. Sin embargo, hay algunas exc epc iones importantes :

• cupsd — El servidor de impres ión por defecto para Red Hat Enterprise Linux.

• lpd — Un servidor de impres ión alternativo.

• xinetd — Un super servidor que controla las conexiones a una serie de servidores subordinados,

tal como gssftp y telnet.

• sendmail — El agente de transporte de correos Sendmail (MTA por sus siglas en inglés,Mail

Transport Agent) está ac tivado por defecto, pero sólo escucha conexiones desde localhost.

• sshd — El servidor OpenSSH, el cual es un reemplazo seguro para Telnet.

Cuando se está determinando si se deben dejar estos servic ios en ejec uc ión, es mejor usar el sentido

común y pec ar por el lado de la cautela. Por ejemplo, si usted no tiene impresora, no deje cupsd

ejec utándose. Lo mismo para portmap. Si no tiene volúmenes NFSv3 o utiliza NIS (el servicio

ypbind), entonc es portmap también debería es ta desactivado.

648

Servic ios de red disponibles

Figura 43.3. Services Configuration Tool

If unsure of the purpose for a particular servic e, the Services Configuration Tool has a description

field, illustrated in Figura 43.3, “Services Configuration Tool”, that provides additional information.

Checking which network servic es are available to start at boot time is only part of the story. You should

also check which ports are open and listening. Refer to Sección 43.2.8, “Ver ificar cuáles puertos están

escuchando” for more information.

43.1.5.3. Servicios inseguros

Algunos protocolos de red son inherentemente más inseguros que otros. Esto incluye cualquier

servicio que:

• Pase los nombres de usuarios y contraseñas sobre la red sin encriptar — Mucho protocolos viejos,

tales como Telnet y FTP, no encriptan la ses ión de autentic ac ión y deberían ser evitados s iempre

que sea posible.

• Transmit Sensitiv e Data Over a Network Unencrypted — Many protocols transmit data over the

network unencrypted. These protoc ols include Telnet, FTP, HTTP, and SMTP. Many network file

sys tems, such as NFS and SMB, also transmit information over the network unencrypted. It is the

user's respons ibility when using these protoc ols to limit what type of data is transmitted.

649

Cortafuegos personales

Los servicios de volcado de memoria remota, como netdump, pasan los contenidos de la memoria

sobre la red sin encriptar. Los volc ados de memoria pueden c ontener c ontraseñas o, peor aún,

entradas de la base de datos u otra información confidenc ial.

Otros servic ios como finger y rwhod revelan información sobre los usuarios del s istema.

Algunos ejemplos de servic ios inseguros que han sido heredados son: rlogin, rsh, telnet y

vsftpd.

All remote login and shell programs (rlogin, rsh, and telnet) should be avoided in favor of SSH.

Refer to Sección 43.1.7, “Herramientas de mejoramiento de la seguridad” for more information about

sshd.

FTP is not as inherently dangerous to the security of the system as remote shells , but FTP servers

must be carefully configured and monitored to avoid problems. Refer to Sección 43.2.6, “Protección de

FTP” for more information about securing FTP servers.

Los servicios que deberían ser implementados con sumo cuidado y coloc ados detrás de un

cortafuegos inc luyen:

• finger

• authd (era llamado identd en vers iones anteriores de Red Hat Enterprise Linux).

• netdump

• netdump-server

• nfs

• rwhod

• sendmail

• smb (Samba)

• yppasswdd

• ypserv

• ypxfrd

More information on securing network servic es is available in Sección 43.2, “Seguridad de servidores”.

La próxima secc ión disc ute las herramientas disponibles para configurar un cortafuegos senc illo.

43.1.6. Cortafuegos personales

Una vez configurados los servic ios de red necesarios, es importante implementar un cortafuegos.

Importante

Se debe configurar los servic ios nec esarios e implementar un cortafuegos antes de

conectar el s is tema a Internet o a otra red no confiable.

650

Cortafuegos personales

Firewalls prevent network pac kets from access ing the system's network interface. If a request is made

to a port that is blocked by a firewall, the request is ignored. If a servic e is listening on one of these

blocked ports, it does not receive the pac kets and is effectively disabled. For this reason, care should

be taken when configuring a firewall to block access to ports not in use, while not blocking access to

ports used by configured servic es.

For most users, the best tool for configuring a simple firewall is the graphical f irewall configuration

tool which ships with Red Hat Enterprise Linux: the Security Level Configuration Tool (system-

config-securitylevel). This tool creates broad iptables rules for a general-purpose firewall

using a control panel interfac e.

43.1.7. Herra mie ntas de mejora miento de la seguridad

En la medida que el tamaño y la popularidad de la Internet crec e, así también ha crecido la

interc eptac ión de la comunic ac ión. A lo largo de los años se han desarrollado herramientas para

encriptar la comunic ac ión cuando estas son llevadas sobre la red.

Red Hat Enterprise Linux se entrega con dos herramientas bás ic as que usan algoritmos de

encriptac ión basados en criptografía de llaves pública de alto nivel para proteger la información a

medida que ésta viaja sobre la red.

• OpenSSH — Una implementac ión del protocolo SSH gratuita para la encriptac ión de las

comunic ac iones de la red.

• Gnu Privacy Guard (GPG) — Una implementac ión gratuita de la aplicac ión de encriptac ión PGP

(Pretty Good Privacy) para la encriptac ión de datos.

OpenSS H es una forma más segura de acc eder a una máquina remota. Reemplaza los servic ios no

encriptados anteriores como telnet y rsh. OpenSS H incluye el servicio de red llamado sshd y tres

aplic ac iones cliente de línea de comandos :

• ssh — Un cliente seguro de acceso a consola remota.

• scp — Un c omando seguro para hac er c opias remotas.

• sftp — Un cliente seudo ftp que permite sesiones de transferenc ia de archivos interactivas.

GPG es una exc elente forma de asegurar las comunic ac iones de correo electrónic o. Puede ser

usado tanto para enviar información confidencial a través de correo sobre redes públic as, como para

proteger los datos c onfidenc iales en los disc os duros.

43.2. Seguridad de servidores

Cuando un sistema es usado como un servidor en una red pública, se convierte en un objetivo

de ataques. Por esta razón, es de suma importanc ia para el administrador fortalec er el s istema y

bloquear servic ios.

Antes de extendernos en problemas partic ulares, debería revisar los siguientes c onsejos generales

para mejorar la seguridad del servidor:

• Mantenga todos los servic ios actualizados para así protegerse de las últimas amenazas

informáticas.

• Utilice protoc olos seguros s iempre que sea posible.

651

Asegurando los servic ios con TCP Wrappers y xinetd

• Proporc ione sólo un tipo de servicio de red por máquina s iempre que sea posible.

• Supervise todos los servidores cuidadosamente por actividad sospechosa.

43.2.1. Asegurando los servicios con TCP Wrappers y xinetd

Los TCP wrappers proporc ionan control de acceso a una variedad de servic ios. La mayoría de los

servic ios modernos de redes, tales como SSH, Telnet y FTP, utilizan TCP wrappers como guardias

entre las petic iones entrantes y el servicio solic itado.

Los benefic ios ofrec idos por TCP wrappers son mejorados c uando se usan en conjunto con xinetd,

un super servicio que proporc iona acceso adic ional, conexión, enlac e, redirecc ión y control de la

utilización de recursos.

Las siguientes subsecc iones asumen que ya se tiene un conoc imiento bás ic o de cada tópico y se

enfoca en opc iones de seguridad espec íf ic as.

43.2.1.1. Mejorar la seguridad con TCP Wrappers

Los TCP Wrappers son capaces de mucho más que simplemente negar el acceso a servic ios. Es ta

secc ión ilustra cómo se pueden usar para enviar panc artas de conexión, avisar sobre ataques desde

hosts partic ulares y mejorar la func ionalidad de conexión. Para una lista detallada de la funcionalidad

y el lenguaje de control de los TCP Wrappers, consulte la página del manual de hosts_options.

43.2.1.1.1. Los TCP Wrappers y las pancartas de conexión

Al mostrar una panc arta apropiada c uando los usuarios se c onec tan a un servicio es una buena forma

de advertir a cualquier atacante potenc ial que el administrador del s istema es tá atento y vigilante.

También se puede controlar la información del sistema que se presenta a los usuarios. Para

implementar un mensaje de TCP wrapper para un servicio, utilice la opción banner.

Este ejemplo implementa una panc arta para vsftpd. Para c omenzar, debe crear un archivo de

panc artas. Este puede estar en cualquier lugar en el sis tema, pero debe tener el mismo nombre que

el demonio. Para este ejemplo, el archivo se llamará /etc/banners/vsftpd.

220-He llo, %c

220-All activity on ftp.example.com is logged.

220-Inappropriate use will re sult in your acc ess privile ges being re move d.

La señal %c proporc iona una variedad de información del cliente, tal como el nombre de usuario y del

host o el nombre del usuario y la dirección IP para hac er la conexión aún más intimidante.

Para que esta pancarta sea presentada a las conexiones entrantes, añada la s iguiente línea al

archivo /etc/hosts.allow :

vsftpd : ALL : banners /etc/banners/

43.2.1.1.2. TCP Wrappers y las advertenci as de ataques

Si se ha detectado a un host particular o a una red tratando de atac ar al servidor, se pueden usar

los TCP Wrappers para advertir de ataques subsec uentes desde esa máquina o red a través de la

directiva spawn .

652


En este ejemplo, se asume que se ha detectado al cracker en la red 206.182.68.0/24 intentando

atac ar el servidor. Colocando la s iguiente línea en el archivo /etc/hosts.deny, se niega el intento

de conexión desde la red y se registra a un archivo espec ial:

ALL : 206.182.68.0 : spawn /bin/ 'date' %c %d >> /var/log/intruder_alert

La señal %d suministra el nombre del servicio que el atac ante estaba tratando de acc eder.

Para permitir la conexión y registrarla, coloque la directiva spawn en el archivo /etc/hosts.allow.

Nota

Pues to que la directiva spawn ejecuta cualquier comando del shell, puede crear un

script espec ial para notificar al administrador o ejec utar una cadena de comandos en

el evento de que un cliente particular intente conectarse al servidor.

43.2.1.1.3. TCP Wrappers y el mejoramiento de la conexión

Si ciertos tipos de conexión son de mayor preocupac ión que otros, se puede subir el nivel de

conexión para ese servicio a través de la opción severity.

En este ejemplo, se asume que cualquiera que es té intentando conectarse al puerto 23 (el puerto

de Telnet) en un servidor FTP, es un cracker. Para resaltarlo, coloque una bandera e me rg en los

archivos de registro en vez de la bandera por defecto, info, y niegue la conexión.

Para hac erlo, escriba la s iguiente línea en /etc/hosts.deny:

in.telnetd : ALL : severi ty emerg

Esto usará la facilidad de conexión por defecto authpriv, pero subirá el nivel de prioridad del valor

por defecto de info a eme rg, lo cual manda los mensajes de registro direc tamente a la consola.

43.2.1.2. Aumentando la seguridad con xinetd

Esta sección se centra en el uso de xinetd para establec er un servicio trampa y controlar el nivel

de recursos disponibles para cualquier servicio xinetd. Al es tablec er límites de recursos para los

servic ios dif iculta los ataques de denegación de servicios (DoS). Para una lista de las opciones

disponibles, consulte las páginas man de xinetd y xinetd.conf.

43.2.1.2.1. Colocando una Trampa

Una característic a importante de xinetd es la habilidad de añadir hos ts a una lista global de

no_access. A los hos ts en esta lista se les negará c onexiones a los servic ios manejados por

xinetd por un tiempo determinado o hasta que se reinicie xinetd. Esto se logra usando el atr ibuto

SENSOR. Esta téc nic a es una forma fácil de bloquear máquinas que intenten esc anear un puerto del

servidor.

El primer paso en configurar un SENSOR es selecc ionar un servicio que no planea utilizar. Para este

ejemplo, se utilizará Telnet.

Modifique el archivo /etc/xinetd.d/telnet y cambie la línea flags para que mues tre lo

siguiente:

653


flags = SENSOR

Agregue la línea s iguiente:

deny_time = 3 0

Esto negará al host el acceso al puerto por 30 minutos. Otros valores ac eptables para el atr ibuto

deny_time son FOREVER, que mantiene el bloqueo has ta que se reinicie xinetd, y NEVER, que

permite la conexión y la regis tra.

Finalmente, la última línea debería mostrar lo s iguiente:

disa ble = n o

Esta línea activa la trampa.

Aún cuando el uso de SENSOR es una buena forma de detectar y detener conexiones de máquinas

dañinas, tiene dos desventajas :

• No funcionará contra escaneos s igilosos.

• Un atac atante que sabe que usted está ejec utando un SENSOR puede montar un ataque DoS en

contra de un host particular falsificando sus direcc iones IP y conectándose al puerto prohibido.

43.2.1.2.2. Control de recursos del servidor

Otra característic a importante de xinetd es la c apac idad de controlar la cantidad de rec ursos que los

servic ios bajo su control pueden utilizar.

Esto se hace a través de las siguientes directr ic es :

• cps = <number_of_connections> <wait_period> — Limits the rate of incoming

connections. This directive takes two arguments :

• <number_of_connections> — The number of connections per sec ond to handle. If the rate of

incoming connections is higher than this, the servic e is temporarily disabled. The default value is

fifty (50).

• <wait_period> — The number of seconds to wait before re-enabling the service after it has

been disabled. The default interval is ten (10) seconds.

• instances = <number_of_connections> — Spec if ies the total number of connections

allowed to a service. This directive accepts either an integer value or UNLIMITED.

• per_source = <number_of_connections> — Spec if ies the number of connections allowed to

a servic e by each host. This directive accepts either an integer value or UNLIMITED.

• rlimit_as = <numbe r[K|M]> — Spec if ies the amount of memory address space the servic e

can occupy in kilobytes or megabytes. This directive accepts either an integer value or UNLIMITED.

• rlimit_cpu = <number_of_seconds> — Spec if ies the amount of time in seconds that a

servic e may occupy the CPU. This directive accepts either an integer value or UNLIMITED.

654


El uso de es tas directivas ayuda a prevenir que cualquier servicio xinetd sobresature el s istema,

resultando en una denegac ión de servic io.

43.2.2. Protección de Portmap

El servicio portmap es un demonio de as ignac ión de puertos dinámico para servic ios RPC, tales

como NIS y NFS. Tiene mec anismos de autentic ac ión débiles y la habilidad de as ignar un amplio

rango de puertos para los servic ios que controla. Por estas razones, es difícil de asegurar.

Nota

El asegurar portmap solamente afecta a las implementac iones de NFSv2 y NFSv3 ,

pues to que NFSv4 ya no lo requiere. Si planea implementar un servidor NFSv2 o

NFSv3, entonc es se requiere portma p. La secc ión s iguiente es relevante en dicho

caso.

Si está ejec utando servic ios RPC, debería seguir algunas reglas básicas.

43.2.2.1. Proteja portmap con TCP Wrappers

Es importante utilizar TCP Wrappers para limitar las redes o máquinas que tienen acceso al servic io

portmap pues to que éste no posee autentic ac ión inc orporada.

Además, utilice solamente direcc iones IP cuando esté limitando el acceso al servicio. Evite los

nombres de hos ts, pues estos pueden ser fals if icados a través de envenenamiento de DNS y otros

métodos.

43.2.2.2. Proteja portmap con iptables

Para restringir más aún el acceso al servicio portmap, es ac onsejable añadir reglas de iptables al

servidor para así limitar el acceso a redes espec íf ic as.

A continuac ión se muestran dos ejemplos de comandos iptables. El primero permite conexiones

TCP al puerto 111 (usado por el servicio portmap) desde la red 192.168.0/24. El segundo permite

conexiones TCP al mismo puerto desde el host local. Esto es necesario para el servicio sgi_fam

utilizado por Nautilus. Todos los demás paquetes son desc artados.

iptables -A INPUT -p tc p -s! 192.168.0.0/24 --dport 111 -j DROP

iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT

Para limitar el tráfico UDP de forma similar, utilice el comando s iguiente.

iptables -A INPUT -p udp -s! 192.168.0.0/24 --dport 111 -j DROP

43.2.3. Protección de NIS

The Network Information Service (NIS) is an RPC servic e, called ypserv,--> which is used in

conjunction with portmap and other related servic es to distribute maps of usernames, passw ords,

and other sens itive information to any computer claiming to be within its domain.

655

Protecc ión de NIS

Un servidor NIS esta c ompues to de varias aplic ac iones. Ellas incluyen las siguientes :

• /usr/sbin/rpc.yppassw dd — También llamado el servicio yppasswdd, es te demonio permite a

los usuarios cambiar sus contraseñas NIS.

• /usr/sbin/rpc.ypxfrd — También llamado ypxfrd, es el demonio responsable de las

transferenc ias de mapas NIS sobre la red.

• /usr/sbin/yppush — Esta aplic ac ión propaga las bases de datos NIS modific adas a múltiples

servidores NIS.

• /usr/sbin/ypserv — Este es el demonio del servidor NIS.

NIS is somew hat insecure by today's standards. It has no host authentic ation mec hanisms and

transmits all of its information over the network unencrypted, including passw ord hashes. As a result,

extreme care must be taken when setting up a network that uses NIS. This is further complicated by

the fact that the default configuration of NIS is inherently insec ure.

It is recommended that anyone planning to implement an NIS server first secure the portmap servic e

as outlined in Sección 43.2.2, “Protección de Portmap”, then address the following issues, such as

network planning.

43.2.3.1. Planee la red cuidadosamente

Debido a que NIS pasa información confidencial sin enc riptar sobre la red, es importante que se

ejec ute el servicio detrás de un cortafuegos y en una red segmentada y segura. Cada vez que se

transmite información NIS a través de una red insegura, hay riesgos de que sea interc eptada. Un

cuidadoso diseño de la red en este aspecto puede ayudar a prevenir violac iones de la seguridad.

43.2.3.2. Utilice un nombre de dominio NIS y de host de tipo contraseña

Any machine within an NIS domain can use commands to extract information from the server without

authentic ation, as long as the user knows the NIS server's DNS hos tname and NIS domain name.

Por ejemplo, si alguien conec ta una portátil a la red o irrumpe en la red desde afuera (y logra simular

una dirección IP interna), el c omando s iguiente revelará el mapa /etc/passwd:

ypcat -d <NIS_ dom ain > -h <D NS _h o stnam e> p ass wd

Si este atacante es un usuario root, podrá obtener el archivo /etc/shadow escribiendo el comando

siguiente:

ypcat -d <NIS_ dom ain > -h <D NS _h o stnam e> shado w

Nota

Si se utiliza Kerberos, el archivo /etc/shadow no se almacena dentro del mapa

NIS.

Para hac er el acceso a los mapas NIS más difícil para un atac ante, cree una cadena de caracteres

aleatoria para el nombre DNS de la máquina, tal como o7hfawtgmh wg.domain.com. De la misma

656

Protecc ión de NIS

manera, cree un nombre aleatorio diferente para el nombre de dominio NIS. Esto hará mucho más

difícil a un atacante accesar el servidor NIS.

43.2.3.3. Modifique el archivo /var/yp/securenets

NIS escuchará a todas las redes si el archivo /var/yp/securenets está en blanco o no existe

(este es el caso predeterminado después de una instalac ión). Una de las primeras c osas que debería

hacer es colocar los pares máscaras/redes en el archivo para que ypserv sólo responda a las

petic iones desde la red adecuada.

A continuac ión se muestra una entrada de ejemplo de un archivo /var/yp/securenets:

255.255.255.0 192.168.0.0

Aviso

Nunca arranque el servidor NIS por primera vez sin crear el archivo /var/yp/

securenets.

Esta técnic a no proporc iona protección ante un ataque de simulac ión de IP (IP spoofing), pero al

menos coloca límites en qué redes servirá el servidor NIS.

43.2.3.4. Asigne puertos estáticos y uso de reglas iptables

A todos los servidores relac ionados con NIS se les pueden as ignar puertos específ ic os excepto por

rpc.yppasswdd — el demonio que permite a los usuarios cambiar sus contraseñas de conexión.

Asignar puertos a los otros dos demonios de servidores NIS, rpc.ypxfrd y ypserv, permite crear

reglas de cortafuegos para proteger aún más los demonios del servidor NIS contra los intrusos.

Para hac er esto, añada las líneas s iguientes a /etc/sysconfig/network:

YPSERV_ARGS="-p 834" YPXFRD_ARGS="-p 835"

Las siguientes reglas iptables se pueden emitir para establec er la red a la cual el servidor escucha a

través de estos puertos :

iptables -A INPUT -p ALL -s! 192.168.0.0/24 --dport 834 -j DROP

iptables -A INPUT -p ALL -s! 192.168.0.0/24 --dport 835 -j DROP

Lo que signif ica que el servidor solo permite conexiones a los puertos 834 y 835 si las petic iones

provienen de la red 192.168.0.0/24 y sin importar el protocolo.

43.2.3.5. Utilice autenticación Kerberos

Una de las debilidades inherentes más resaltantes cuando se utiliza NIS para autentic ac ión, es que

cada vez que un usuario se c onec ta a una máquina se envia el hash de la contraseña desde /etc/

shado w a través de la red. Si un intruso obtiene acc eso a un dominio NIS y rastrea el tráfico de la

red, puede reunir fác ilmente los nombres de usuarios y c ontraseñas. Con el tiempo sufic iente, un

657

Protecc ión de NFS

programa de desc ifrado de contraseñas puede adivinar las contraseñas débiles y el atac ante puede

obtener acc eso a una cuenta válida en la red.

43.2.4. Protección de NFS

Importante

The version of NFS included in Red Hat Enterprise Linux, NFSv4, no longer requires

the portmap servic e as outlined in Sección 43.2.2, “Protección de Portmap”. NFS

traffic now utilizes TCP in all vers ions, rather than UDP, and requires it when using

NFSv4. NFSv4 now inc ludes Kerberos user and group authentic ation, as part of the

RPCSEC_GSS kernel module. Information on portmap is still included, since Red Hat

Enterprise Linux supports NFSv2 and NFSv3, both of which utilize portmap.

43.2.4.1. Planee la red cuidadosamente

Debido a que NFSv4 tiene la habilidad de pasar toda la información encriptada sobre la red usando

Kerberos, es importante que el servicio sea configurado correctamente si se encuentra detrás de un

cortafuegos o en un segmento de la red. NFSv2 y NFSv3 aún envían la información de forma

insegura. Un diseño cuidadoso en es te aspec to puede ayudar a prevenir violac iones de la seguridad.

43.2.4.2. Cuidado con los errores sintácticos

El servidor NFS determina c uáles s is temas de archivos exportar y a cuáles máquinas exportar estos

directorios a través del archivo /etc/exports. Tenga cuidado de no añadir espac ios adic ionales

cuando edite este arc hivo.

Por ejemplo, la línea s iguiente en el archivo /etc/exports c omparte el directorio /tmp/nfs/ al

host bob.example.com con permisos de lectura y escritura.

/tmp/nfs / bob.e xa mple.c om(rw)

Por otro lado, esta línea en el archivo /etc/exports, comparte el mismo directorio con el host

bob.example.com con permisos de sólo lectura y lo comparte con todo el mundo con permisos de

lectura y escritura debido al espac io en blanco luego del nombre de la máquina.

/tmp/nfs / bob.example.com (rw)

Es un buen hábito verificar cualquier directorio compartido NFS usando el comando showmount para

verificar que está s iendo compartido:

sh o wm o unt - e <h o stn a m e >

43.2.4.3. No utilice la opción no_root_squash

Por defecto, los directorios compartidos NFS cambian el usuario root por el usuario nfsnobo dy , una

cuenta de usuario sin privilegios. De esta forma, todos los archivos creados por root son propiedad

del usuario nfsnobody , lo que previene la c arga de programas con el bit setuid establec ido.

658

Protecc ión de NFS

Si se utiliza no_root_squash, los usuarios remotos podrán cambiar cualquier archivo en el sistema

de archivos compartido y dejar aplicac iones con troyanos para que otros usuarios las ejecuten

inadvertidamente.

43.2.5. Protegiendo el servido r Apache HTTP

El Servidor Apac he HTTP es uno de los servic ios más estables y seguros que se entregan con

Red Hat Enterprise Linux. Hay una cantidad impres ionante de opc iones y téc nic as disponibles para

asegurar el servidor Apache HTTP — demasiadas para verlas en profundidad en es te doc umento.

Los administradores de sistemas deben ser cuidadosos c uando utilicen las siguientes opc iones de

configurac ión:

43.2.5.1. FollowSymLinks

Esta directiva está activada por defecto, por lo tanto tenga c uidado al crear enlaces s imbólic os al

doc umento raíz del servidor Web. Por ejemplo, es una mala idea proporc ionar un enlac e simbólico a

/.

43.2.5.2. La directiva Indexes

Esta directiva está activada por defecto, pero puede que no sea rec omendable. Si no desea que los

usuarios hojeen los archivos en el servidor, es mejor que elimine esta direc tiva.

43.2.5.3. La directiva UserDir

La directiva Use rDir es tá desac tivada por defecto porque puede confirmar la presenc ia de una

cuenta de usuario en el s is tema. Si desea activar la navegac ión del directorio del usuario en el

servidor, utilice las directivas s iguientes :

UserDir enabled

UserDir disa ble d root

Es tas directivas activan la navegac ión del directorio del usuario para todos los directorios de usuarios

excepto /root. Si desea añadir usuarios a la lista de cuentas deshabilitadas, añada una lista de

usuarios separadas por espac ios en la línea UserDir disabled.

43.2.5.4. No elimine la directiva IncludesNoExec

Por defecto, el módulo Server-Side Includes (SSI no pueden ejec utar c omandos. No se recomienda

modificar esta configurac ión a menos que tenga absoluta nec es idad de hacerlo, pues to que

potenc ialmente habilita a que un atac ante pueda ejec utar c omandos en el s is tema.

43.2.5.5. Limite los permisos para los directorios ejecutables

Asegúrese de que solamente el usuario root tenga permisos de escritura para cualquier directorio que

contenga scripts o CGIs. Esto se puede lograr escribiendo los comandos s iguientes :

cho wn root <directory _name >

chmod 755 <directory_name>

659

Protecc ión de FTP

Importante

Verifique que cualquier script que esté ejec utando en el s is tema funcione como se

espera antes de colocarlos en producción.

43.2.6. Protección de FTP

The File Transfer Protocol (FTP) is an older TCP protocol des igned to transfer files over a network.

Bec ause all transactions with the server, including user authentic ation, are unencrypted, it is

cons idered an insec ure protocol and should be carefully configured.

Red Hat Enterprise Linux proporc iona tres servidores FTP.

• gssftpd — Un demonio FTP kerberizado basado en xinetd que no pasa información de

autentic ac ión sobre la red.

• Red Hat Content Accele rator (tux) — Un servidor Web con espac io kernel que posee

capac idades de FTP.

• vsftpd — Una implementac ión de servicio FTP independiente y orientado a la seguridad.

Las siguientes pautas de seguridad son para la configuración del servicio FTP vsftpd.

43.2.6.1. Pancarta de saludo de FTP

Antes de suministrar un nombre de usuario y c ontraseña, a todos los usuarios se les presenta una

panc arta de saludo. Por defecto, esta panc arta incluye información relac ionada con la versión, lo que

es útil para los maleantes informáticos que es tén intentando averiguar las debilidades del s istema.

Para c ambiar la panc arta de bienvenida para vsftpd, añada la directiva s iguiente a /etc/vsftpd/

vsftpd.conf:

ftpd_banner=<insert_greeting_here >

Replac e <insert_greeting_here> in the above directive with the text of the greeting message.

Para pancartas de varias líneas, es mejor utilizar un archivo de pancartas. Para simplificar la

adminis trac ión de múltiples panc artas, coloque todas las panc artas en un nuevo directorio llamado

/etc/banners/. El archivo de panc artas para las conexiones FTP en este ejemplo será /etc/

banners/ftp.msg. Abajo se muestra un ejemplo de como se vería tal archivo:

## # ## # ## # # Hola, toda activida d en ftp.exa mple.com es registrada. ## # ## # ## #

Nota

It is not necessary to begin each line of the file with 220 as spec if ied in

Sección 43.2.1.1.1, “Los TCP Wrappers y las pancartas de conexión”.

Para hac er referenc ia a este archivo de pancartas desde vsftpd, añada la siguiente directiva al

archivo /etc/vsftpd/vsftpd.conf :

660

Protecc ión de FTP

ba nne r_f ile =/e tc/ba nners /f tp.msg

Importante

Make sure that you specify the path to the banner f ile correctly in /etc/vsftpd/

vsftpd.conf, or else every attempt to connec t to vsftpd will result in the

connection being c losed immediately and a 500 OOPS: cannot open banner

<path_to_banner_file> error message.

Note that the banner_file directive in /etc/vsftpd/vfsftpd.conf takes prec edenc e over any

ftpd_banner directives in the configuration file: i f banner_file is spec if ied, then ftpd_banner is

ignored.

It also is poss ible to send additional banners to incoming connections us ing TCP Wrappers as

described in Sección 43.2.1.1.1, “Los TCP Wrappers y las pancartas de conexión”.

43.2.6.2. Acceso anónimo

La presenc ia del directorio /var/ftp/ activa la c uenta anónima.

La forma más fácil de crear este directorio es instalando el paquete vsftpd. Este paquete c onfigura

un árbol de directorios y configura los permisos en estos directorios como de sólo lectura para los

usuarios anónimos.

Por defecto los usuarios anónimos no pueden escribir a estos director ios.

Atención

Si es tá activando el acceso anónimo a un servidor FTP, tenga cuidado de dónde

guarda información confidenc ial.

43.2.6.2.1. Carga anóni ma

Si desea permitir a los usuarios anónimos que c arguen archivos al servidor, se rec omienda que cree

un directorio de sólo escritura dentro de /var/ftp/pub/.

Utilice el comando s iguiente.

mkdir /var /f tp/pub/uploa d

Luego, cambie los permisos para que los usuarios anónimos no puedan ver qué hay dentro del

directorio:

chmod 730 /var /ftp/pub/uploa d

Un listado de formato largo del directorio debería verse c omo:

drwx-wx--- 2 root ftp 4096 Feb 13 20:05 upload

661

Asegurando Sendmail

Aviso

Los administradores que permiten a los usuarios anónimos leer y escribir en

directorios, a menudo enc uentran que sus servidores se convierten en depós itos de

software robado.

Adic ionalmente, bajo vsftpd, añada la línea s iguiente a /etc/vsftpd/vsftpd.conf :

an o n_ up lo a d_ en able = YE S

43.2.6.3. Cuentas de usuarios

Debido a que FTP pasa los nombres de usuarios y c ontraseñas sobre redes inseguras s in encriptar,

es una buena idea negar a los usuarios del s istema el acceso al servidor desde sus cuentas de

usuario.

Para inhabilitar las cuentas de usuarios en vsftpd, añada la s iguiente directiva a /etc/vsftpd/

vsftpd.conf:

local_enable=NO

43.2.6.3.1. Restri ngir cuentas de usuarios

También es pos ible desactivar las cuentas de usuario dentro de cada servicio directamente.

Para deshabilitar una cuenta de usuario espec íf ic a en vsftpd, añada el nombre de usuario a /etc/

vsftpd.ftpusers.

43.2.6.4. Usar TCP Wrappers para controlar el acceso

Use TCP Wrappers to control access to either FTP daemon as outlined in Sección 43.2.1.1, “Mejorar

la seguridad con TCP Wrappers”.

43.2.7. Asegurando Sendmail

Sendmail es un Agente de transporte de correos (MTA) que utiliza el protocolo simple de transferenc ia

de correo electrónico (SMTP, según sus siglas en inglés) para entregar mensajes electrónic os entre

otros MTA y a clientes de correo o agentes de entrega. Aún cuando muc hos MTAs son capaces

de encriptar el tráfico entre unos y otros, la mayoría no lo hac en, por tanto el envío de correos

electrónic os sobre redes públic as es cons iderado una forma insegura de comunicac ión.

Se rec omienda que cualquiera que esté planeando implementar un servidor Sendmail, tenga en

cuenta los siguientes problemas.

43.2.7.1. Limitar los Ataques de Rechazo de Servicio (DoS)

Debido a la naturaleza del correo electrónic o, un atac ante determinado puede inundar fácilmente el

servidor con correos y de esta manera causar un rechazo de servicio. Se puede limitar la efectividad

de tales ataques coloc ando límites a las siguientes directr ic es en /etc/mail/sendmail.mc.

662

Asegurando Sendmail

• confCONNECTION_RATE_THROTTLE — El número de conexiones que el servidor puede recibir por

segundo. Por defecto, Sendmail no limita el número de c onexiones. Si se establece un límite y este

es alc anzado, las conexiones s iguientes son retrasadas.

• confMAX_DAEMON_CHILDREN — El máximo número de proc esos hijo que se pueden producir por

el servidor. Por defecto, Sendmail no as igna un límite al número de proc esos hijos. Si se coloca un

límite y este es alc anzado, las conexiones s iguientes son retrasadas.

• con fMIN_F REE_BLO CKS — El número mínimo de bloques libres que debe haber disponible para

que el servidor ac epte c orreos. Por defecto es 100 bloques.

• confMAX_HEADERS_LENGTH — El tamaño máximo ac eptable (en bytes) para la cabecera de un

mensaje.

• confM AX_MES S AGE_SIZE — El tamaño máximo ac eptable (en bytes) para cualquier mensaje.

43.2.7.2. NFS y Sendmail

Nunca coloque el directorio spool de correos, /var/spool/mail/, en un volumen compartido NFS.

Bec ause NFSv2 and NFSv3 do not maintain control over user and group IDs, two or more users can

have the same UID, and receive and read eac h other's mail.

Nota

Con NFSv4 usando Kerberos, este no es el c aso, pues to que el módulo del kernel

SECRPC_GSS no utiliza una autentic ac ión basándose en UID. Sin embargo, se

cons idera una buena práctic a el no ubicar el directorio spool de correos en un

volumen compartido NFS.

43.2.7.3. Usuarios de correo únicamente

Para ayudar a prevenir explotac iones del usuario local en el servidor Sendmail, es mejor que los

usuarios de correo electrónico solamente accedan al servidor Sendmail usando un programa de

correo. No deberían permitirse las cuentas shell en el servidor de correo y todos los usuarios shell en

el archivo /etc/passwd deberían ser coloc ados a /sbin/nologin (con la posible exc epc ión del

usuario root).

43.2.8. Verificar cuáles puertos están escuchando

After configuring network servic es, it is important to pay attention to which ports are actually listening

on the system's network interfaces. Any open ports can be evidenc e of an intrus ion.

Existen dos soluc iones bás ic as para listar los puertos que están escuchando en la red. La soluc ión

menos confiable es c onsultar la pila de la red escribiendo c omandos tales como netstat -an o

lsof -i. Este método es menos confiable puesto que es tos programas no conectan a la máquina

desde la red, solo verifican que está ejecutándose en el sistema. Por esta razón, estas aplicaciones

son objetivos frec uentes de atacantes que reemplazan netstat y lsof con sus propias vers iones

para intentan cubrir sus rastros c uando abren puertos no autorizados.

Una forma más confiable de verificar qué puertos es tán esc uc hando en la red es usar un escaner de

puertos como nmap.

663

Verificar cuáles puertos están esc uc hando

El c omando s iguiente ejec utado desde la c onsola, determina c uáles puertos están esc uchando por

conexiones TCP desde la red:

nmap -sT -O loca lhos t

La salida de este c omando es parec ida a lo s iguiente:

Starting nmap 3.55 ( http://www.insecure.org/nmap/ ) a t 2004-09-24 13:49 EDT

Interesting ports on localhost. loc aldoma in (127.0.0.1):

(The 1653 ports scanned but not sh o wn belo w are in state: close d)

PORT STATE SERVICE

22/tc p open ssh

25/tcp open smtp

111/tc p ope n rpcbind

113/tcp ope n auth

631/tc p open ipp

834/tcp open unknown

2601/tc p open ze bra

32774/tcp open sometimes-rpc11

Device type: ge neral purpose

Running: Linux 2.4.X|2.5.X|2.6.X OS details: Linux 2.5.25 - 2.6.3 or Ge ntoo 1.2 Linux 2.4.19

rc 1-rc 7)

Uptime 12.857 days (since Sat Sep 11 17:16:20 2004)

Nmap run completed -- 1 IP address (1 host up) scanne d in 5.190 seconds

Esta salida muestra que el s istema está ejec utando portmap debido a la presenc ia del servic io

sunrpc. Sin embargo, existe también un servicio misterioso en el puerto 834. Para verificar si el

puerto está asociado con la lista oficial de servic ios c onoc idos, escriba:

cat /etc/services | grep 834

Este comando no devuelve ninguna salida. Esto indica que aunque el puerto está en el rango

reservado (es decir del 0 al 1023) y requiere ac c eso root para ser abierto, no está asociado con un

servicio conoc ido.

Luego, puede verif icar la información sobre el puerto usando netstat o lsof. Para verificar el

puerto 834 usando netstat, utilice el comando s iguiente:

netstat -anp | grep 834

El c omando devuelve la s iguiente salida:

tc p 0 0 0.0.0.0:834 0.0.0.0:* LISTEN 653/ypbind

La presenc ia de un puerto abierto en netstat es tranquilizante pues to que un maleante abriendo un

puerto furtivamente en un sistema violado, pos iblemente no se revelaría a través de es te c omando.

Además, la opción [p] revela el id del proc eso (PID) del servicio que abrió el puerto. En este caso,

el puerto abierto pertenec e a ypbind (NIS), que es un servicio RPC manejado en conjunto con el

servicio portmap.

El c omando lsof revela información similar a la dada por netstat pues to que es capaz de enlazar

puertos abiertos a servic ios :

http://www.insecure.org/nmap/

664

Verificar cuáles puertos están esc uc hando

lsof -i | grep 834

A continuac ión se enc uentra la porción relevante de la salida de este c omando:

ypbind

65 3

0

7 u

IPv4

13 1 9

TCP *:8 3 4 (LIST E N)

ypbind 65 5 0 7 u IPv4 13 1 9 TCP *:8 3 4 (LIST E N) ypbind 65 6 0 7 u IPv4 13 1 9 TCP *:8 3 4 (LIST E N) ypbind 65 7 0 7 u IPv4 13 1 9 TCP *:8 3 4 (LIST E N)

Estas herramientas pueden revelar bastante información sobre el estado de los servic ios

ejec utándose en la máquina. Estas herramientas son flexibles y pueden proporc ionar gran cantidad

de información sobre los servic ios de red y la configurac ión. Se rec omienda la revis ión de las páginas

man para lsof, netstat, nmap, y services.

43.3. Single Sign-on (SSO)

43.3.1. Intro ducción

La func ionalidad SSO de Red Hat Enterprise Linux reduc e el número de veces que los usuarios de

escritorios Red Hat Enterprise Linux deben introducir sus contraseñas. Varias aplic ac iones utilizan los

mismos mec anismos de autentic ac ión y autorización para que los usuarios puedan registrarse en Red

Hat Enterprise Linux desde una pantalla de registro y luego no tengan que introducir la contraseña de

nuevo. Estas aplic ac iones se detallan a continuac ión.

Además, los usuarios pueden registrarse a sus máquinas incluso si no existe una red (modo fuera de

línea) o donde la conexión a la red no es confiable, como es el caso del acceso inalámbric o. En este

último caso, los servic ios son degradados progres ivamente.

43.3.1.1. Aplicaciones soportadas

Las siguientes aplicac iones están actualmente soportadas por el esquema de registro unificado en

Red Hat Enterprise Linux:

• Regis tro

• Salvapantalla

• Firefox y Thunderbird

43.3.1.2. Mecanismos de autenticación soportados

Red Hat Enterprise Linux actualmente soporta los siguientes mec anismos de autentic ac ión:

• Registro nombre/c ontraseña de Kerberos

• Tarjetas inteligentes/PIN

43.3.1.3. Tarjetas inteligentes soportadas

Red Hat Enterprise Linux has sido verificado con tarjetas y lec tores Cyberflex e-gate pero cualquier

tarjata que acate las espec if ic ac iones Java card 2.1.1 y Global Platform 2.0.1 debe operar

correctamente. Así mismo, cualquier lector que es soportado por PCSC-lite debe funcionar.

665

Iniciando con su nueva tarjeta inteligente

Red Hat Enterprise Linux también ha sido probado con tarjetas de acceso común (CAC por sus siglas

en inglés). El lector soportado para CAC es SCM SCR 331 USB Reader.

As of Red Hat Enterprise Linux 5.2, Gemalto smart cards (Cyberflex Acc ess 64k v2, standard with

DER SHA1 value configured as in PKCSI v2.1) are now supported. These smart cards now use

readers compliant with Chip/Smart Card Interface Devices (CCID).

43.3.1.4. Ventajas de SSO en Red Hat Enterprise Linux

Actualmente existen varios mec anismos de seguridad que utilizan un gran número de protocolos y

credenc iales. Entre éstos se enc uentran SSL, SSH, IPsec y Kerberos. SSO de Red Hat Enterprise

Linux pretende unificar estos esquemas para soportar los requerimientos lis tados anteriormente. Es to

no significa reemplazar Kerberos con certif icados X.509v3, pero unificarlos para reducir la carga tanto

en los usuarios de los sis temas como de los administradores que los administran.

Para alc anzar es te objetivo, Red Hat Enterprise Linux:

• Proporc iona una biblioteca compartida NSS crypto única en cada s istema operativo.

• Ships the Certificate System's Enterprise Security Client (ESC) with the base operating sys tem.

The ESC application monitors smart card insertion events. If it detec ts that the user has inserted

a smart card that was des igned to be used with the Red Hat Enterprise Linux Certificate System

server product, it displays a user interfac e instructing the user how to enroll that smart card.

• Unifica Kerberos y NSS para que los usuarios que se regis tran en el s istema operativo utilizando

una tarjeta inteligente también puedan obtener las credenc iales de Kerberos ( lo cual les permitirá

regis trarse en servidores de archivos y otros).

43.3.2. Iniciando con su nueva tarjeta intelige nte

Antes de que pueda utilizar la tarjeta inteligente para regis trarse a su sistema y aprovec har las

ventajas de seguridad que esta tec nología proporc iona, usted tendrá que ejecutar algunas tareas

básicas de instalac ión y configurac ión. Estas tareas se describen a continuac ión:

Nota

Esta sección proporc iona una visión general de la utilización de tar jetas inteligentes.

Información más detallada puede enc ontrarse en el Manual de Clientes de Seguridad

Empresarial del Sis tema de Certif icados de Red Hat.

1. Registrese con su nombre y c ontraseña de Kerberos

2. Asegúrese de que el paquete nss-tools esté cargado.

3. Desc argue e instale su certificado root específ ic o para la corporac ión. Utilice el s iguiente

comando para instalar el certificado CA root:

certutil - A -d /etc/pki/nssdb -n "root ca cert" -t " CT,C, C" -i ./

ca_cert_in_base 64_format.crt

4. Verifique que tiene los siguientes RPM ins talados en su sistema: esc, pam_pkcs11, coolkey, ifd-

egate, ccid, gdm, authconfig y authconfig-gtk.

666

Iniciando con su nueva tarjeta inteligente

5. Activar el soporte de registro de la tarjeta inteligente

a. On the Gnome Title Bar, select System->Adminis tration->Authentic ation.

b. Type your mac hine's root passw ord i f necessary.

c. En el diálogo de configurac ión de la autentic ac ión, haga clic en la pestaña Autenticación.

d. Selecc ione la casilla de verificación Activar soporte de tarjetas inteligentes.

e. Haga clic en el botón Configurar tarjeta inteligente... para ver el diálogo de parámetros de

la tarjeta inteligente y espec if ique los parámetros requeridos :

• Re quiere tarjeta inteligente para entrar — Desac tive es ta casilla de verificación. Una

vez usted ha iniciado una ses ión de forma satisfactoria con la tarjeta inteligente, us ted

puede selecc ionar es ta opción para prevenir que los usuarios se regis tren s in tar jetas

inteligentes.

• Acción de remoción de tarjeta — Esto controla la acción a tomar una vez usted remueva

la tarjeta inteligente después de haber iniciado la ses ión. Las opc iones disponibles son:

• Lock — Al remover la tar jeta se bloqueará la pantalla X.

• Ignore — La remoción de la tarjeta no tiene ningún efecto.

6. Si nec es ita activar el Online Certif icate Status Protocol (OCSP), abra el archivo /etc/

pam_pkcs11/pam_pkcs11.conf y ubique la línea s iguiente:

enable_ocsp = false;

Cambie es te valor a "true", como se señala a continuac ión:

enable_ocsp = true;

7. Inscriba su tarjeta inteligente

8. Si está utilizando una tarjeta CAC, deberá también ejec utar los siguientes pasos:

a. Desde una c uenta de root cree un archivo llamado /etc/pam_pkcs11/cn_map.

b. Añada la s iguiente entrada al archivo cn_map:

MY.CAC_CN.123454 -> myloginid

Donde <MY.CAC_CN.123454> es el nombre común en su CAC y <mi-login-id> es su

login ID de UNIX.

9. Logout

43.3.2.1. Solución de problemas

Si tiene problemas al tratar de hac er funcionar su tarjeta inteligente, intente el siguiente comando para

ubicar la fuente del problema:

pklogin_finder de bug

667

Cómo funciona la inscripción de las tarjetas inteligentes

Si ejecuta la herramienta pklogin_finder en modo de depurac ión mientras un tarjeta inteligente

inscrita está c onec tada, se intentará obtener la información sobre la validez de los certif icados y

verificará si se puede relac ionar el login ID con uno de los certif ic ados presentes en la tar jeta.

43.3.3. Cómo funciona la inscripció n de las tarjetas inteligentes

Las tarjetas inteligentes están inscritas c uando han recibido un certificado firmado por una autoridad

certif ic adora (CA por sus siglas en inglés,Certif icate Authority). Este proc eso incluye los pasos que se

describen a continuac ión:

1. El usuario introduce la tarjeta inteligente en el lector de tar jatas de la es tac ión de trabajo. Este

evento es reconoc ido por el cliente de seguridad empresarial (ESC).

2. The enrollment page is displayed on the user's desktop. The user completes the required details

and the user' s sys tem then c onnec ts to the Token Proc ess ing System (TPS) and the CA.

3. El TPS inscribe la tarjeta inteligente utilizando el certificado firmado por el CA.

Figura 43.4. Cómo funciona la inscripción de las tar jetas inteligentes

43.3.4. Cómo funciona el registro de las tarjetas inteligentes

Esta sección describe brevemente el proc eso de registro utilizando una tarjeta inteligente.

1. When the user inserts their smart card into the smart card reader, this event is recognized by the

PAM facility, which prompts for the user's PIN.

2. The system then looks up the user's current certif ic ates and verifies their validity. The certificate is

then mapped to the user's UID.

668

Cómo funciona la inscripción de las tarjetas inteligentes

3. Éste es validado con el KDC y el login es concedido.

Figura 43.5. Cómo funciona el registro de las tar jetas inteligentes

Nota

Usted no puede regis trarse con una tarjeta que no ha sido inscrita, incluso si ésta

tiene el formato correcto. Deberá regis trarse con una tarjeta formateada e inscrita -o

con otro método diferente, antes de inscribir una nueva tarjeta.

43.3.5. Configuración de Firefox para utilizar Kerberos con SSO

Usted puede configurar Firefox para utilizar Kerberos con SSO. Para que esta func ionalidad func ione

apropiadamente, tendrá que configurar su navegador para que envíe credenc iales Kerberos al KDC

apropiado.

1. En la barra de direcc iones de Firefox, escriba about:config para ver la lista de opc iones de

configurac ión ac tuales.

2. En el campo Filter escriba negotiate para restringir la lista de opc iones.

3. Haga doble clic en la entrada network.negotiate-auth.trusted-uris para ver la ventana de diálogo

Enter string value.

669

Configuración de Firefox para utilizar Kerberos con SSO

4. Introduzc a el nombre del dominio desde el cual desea llevar a cabo la autenticac ión (p. ej.

.ejemplo.com).

5. Repita el proc edimiento anterior para la entrada network.negotiate-auth.delegation-uris y utilice el

mismo dominio.

Nota

Puede dejar este valor en blanco ya que el pase de tiquetes de Kerberos no es

requerido.

Si no encuentra estas dos opc iones listadas, su versión de Firefox es demasiado

vieja y podría no soportar la negoc iac ión de la autentic ac ión. En dicho caso,

us ted debería c ons iderar actualizar Firefox.

Figura 43.6. Configurac ión de Firefox para SSO con Kerberos

Ahora debe asegurarse de tener tickets de kerberos. En un intérprete de comandos de shell escriba

kinit para obtener tickets de Kerberos. Para ver la lista de tickets disponibles escriba klist. A

continuac ión se presenta un ejemplo de la respuesta de dicho comando:

[user@host ~] $ kinit

Password for [email protected]:

[user@host ~] $ klist

Ticket cache: FILE:/tmp/krb5cc_10920

De fa ult pr inc ipa l: [email protected]

Valid starting Expires Service principal

10/26/06 23:47:54 10/27/06 09:47:54 krbtgt/[email protected]

ren e w until 10/26/06 23:47:54

Kerberos 4 tic ket c ac he: /tmp/tkt10920

mailto:user@host

mailto:[email protected]:

mailto:user@host

mailto:[email protected]

mailto:[email protected]

670

Configuración de Firefox para utilizar Kerberos con SSO

klist: You have no tickets cached

43.3.5.1. Solución de problemas

Si ha seguido los pasos de configurac ión anteriores y la negoc iac ión de la autentic ac ión no está

func ionando, puede activar la salida verbosa del registro del proc eso de autentic ac ión. Esto puede

ayudarlo a encontrar la causa del problema. Para activar la salida verbosa del registro, utilice el

siguiente proc edimiento:

1. Cierre todas las ventanas de Firefox.

2. Abra una consola e introduzca el s iguiente comando:

export N SP R_ LOG_ MODULES=n egotiateauth:5

export NSPR_LOG_FILE=/tmp/moz.log

3. Reinicie Firefox desde esa consola y vis ite el sitio web al cual no pudo autentic arse anteriormente.

La información será registrada en /tmp/moz.log. Ésta le dará pistas sobre el problema. Por

ejemplo:

-1208550944[90039d0]: enter ing nsNe gotiate Auth::GetNe xtToken()

-1208550944[90039d0]: gss_init_sec _c onte xt() failed: Miscellaneous failure

No crede ntia ls cac he found

Esto indica que usted no tiene tickets de Kerberos y nec es ita ejec utar kinit.

Si puede ejec utar kinit satis factoriamente desde su máquina pero no puede autentic arse, verá un

mensaje similar al s iguiente en el archivo de registro:

-1208994096[8d683d8]: entering nsAuthGSSAPI::GetNe xtToke n()

-1208994096[8d683d8]: gss_init_sec _c onte xt() failed: Miscellaneous failure

Server not found in Kerberos database

Esto generalmente indica que hay un problema en la configurac ión de Kerberos. Asegúrese de tener

las entradas c orrectas en la secc ión [domain_realm] del archivo /etc/krb5.conf. Por ejemplo:

.example.com = EXAMPLE.COM

ex am p le.co m = EXAMPLE.COM

Si nada aparece el el archivo de registro es posible que usted esté conectándose a un proxy y que

és te está c ortando las cabeceras HTTP requeridas para la negoc iac ión de la autenticac ión. Para

soluc ionar este problema, usted puede c onectarse al servidor utilizando HTTPS; esto permitirá que la

solicitud pase sin ser modificada. Luego continúe con la depurac ión utilizando el archivo de registro

como se describió anteriormente.

43.4. Pluggable Authentication Modules (PAM) Programs that grant users access to a system use authentication to verify eac h other's identity (that is,

to establish that a user is who they say they are).

671

Las ventajas de PAM

Históric amente, c ada programa tiene su forma particular de realizar la autentic ac ión. Bajo Red

Hat Enterprise Linux, muchos programas son configurados para usar un proc eso de autenticac ión

centralizado llamado PAM (Pluggable Authentication Modules).

PAM utiliza una arquitectura conectable y modular, que otorga al administrador del sistema de una

gran flexibilidad en establec er las políticas de autentic ac ión para el s is tema.

In most situations, the default PAM configuration file for a PAM-aware application is sufficient.

Sometimes, how ever, it is necessary to edit a PAM configuration f ile. Because misconfiguration of

PAM can compromise system security, it is important to understand the structure of these files before

making any modifications. Refer to Sección 43.4.3, “Formato del archivo de configuración PAM” for

more information.

43.4.1. Las ventajas de PAM

PAM ofrece las ventajas s iguientes :

• un esquema de autentic ac ión común que se puede usar con una gran variedad de aplic ac iones.

• gran flexibilidad y control de la autentif ic ación tanto para los adminis tradores de sistemas c omo

para los desarrolladores de la aplicac ión.

• una biblioteca bien documentada que permite a los desarrolladores de aplic ac iones desarrollar

programas sin tener que crear sus propios esquemas de autentic ac ión.

43.4.2. archivos de config uració n PAM

El directorio /etc/pam.d/ contiene los arc hivos de configurac ión de PAM para cada aplic ac ión tipo

PAM. En vers iones antiguas de PAM se utilizaba /etc/pam.conf, pero este archivo ya no se utiliza

y solamente es usado si el directorio /etc/pam.d/ no existe.

43.4.2.1. Archivos de servicios PAM

Cada aplic ac ión tipo PAM o servicios tiene un archivo dentro del directorio /etc/pam.d/. Cada uno

de estos arc hivos llevan el nombre del servicio para el cual controla el acceso.

Depende del programa tipo PAM definir el nombre de su servicio e instalar su archivo de

configurac ión en el directorio /etc/pam.d/. Por ejemplo, el programa login define su nombre de

servicio como login e instala el archivo de configuración PAM /etc/pam.d/login.

43.4.3. Formato del archivo de config uración PAM

Cada archivo de configurac ión PAM contiene un grupo de directivas formateadas como sigue:

<mo du le interface> <c ontrol flag> <mo du le name> <m o d u le a rg u m en ts >

En las siguientes secc iones se explican cada uno de estos elementos.

43.4.3.1. Interfaz de módulo

Hay cuatro tipos de módulos PAM disponibles. Cada uno corresponde con un aspecto diferente del

proc eso de autorizac ión:

672

Las ventajas de PAM

• auth — Esta interfaz de módulo autentif ican el uso. Por ejemplo, solicita y verif ica la validez de una

contraseña. Los módulos con esta interfaz también pueden es tablec er credenc iales, tales como

membrec ías de grupo o tickets Kerberos.

• account — Esta interfaz de módulo verifica que sea permitido el acceso. Por ejemplo, puede

verificar que la cuenta no haya caduc ado o que el usuario tenga permiso de iniciar sesiones a una

hora del día particular.

• password — Este módulo se usa para establec er y verificar contraseñas .

• session — This module interfac e configures and manages user sessions. Modules with this

interfac e can also perform additional tasks that are needed to allow access, like mounting a user's

home directory and making the user's mailbox available.

Nota

Un módulo individual puede proporc ionar una o todas las interfaces de módulos

menc ionadas anteriormente. Por ejemplo, pam_unix.so proporc iona todas las

cuatro interfaces.

En un archivo de configurac ión PAM, la interfaz del módulo es el primer campo a definir. Por ejemplo,

una línea típica de una configurac ión sería:

auth re quired pam_unix.so

This instructs PAM to use the pam_unix.so module's auth interfac e.

43.4.3.1.1. Apilar interfaces de módulos

Module interfac e directives can be stack ed, or plac ed upon one another, so that multiple modules are

used together for one purpose. If a module's control flag uses the "sufficient" or "requisite" value (refer

to Sección 43.4.3.2, “Indicadores de control” for more information on these flags), then the order in

which the modules are listed is important to the authentic ation proc ess.

El hec ho de apilarlos hace que sea más fácil para que el administrador exija diversas condic iones

antes de permitir la autentic ac ión del usuario. Por ejemplo, el comando reboot utiliza generalmente

una pila de módulos, como se ve en su archivo de configuración:

[root@MyServer ~]# ca t /etc/pa m.d/re boot

#%PAM-1.0

auth sufficient pam_rootok.so

auth re quired pa m_c onsole.so

#auth include system-a uth

account re quire d pam_permit.so

• La primera línea es un comentario y no es procesada.

• auth sufficient pam_rootok.so — Esta línea utiliza el módulo pam_rootok.so para

revisar si el usuario actual es root, verificando que su UID sea igual a 0. Si esta prueba tiene éxito,

ningún otro módulo es consultado y el c omando es ejec utado. De lo contrario se c onsultará el

siguiente módulo.

mailto:root@MyServer

673

Formato del archivo de configuración PAM

• auth required pam_console.so — Esta línea utiliza el módulo pam_console.so para

intentar autentic ar al usuario. Si este usuario ya tiene una ses ión en la c onsola, pam_console.so

revisa si hay un archivo en el directorio /etc/security/console.apps/ con el mismo nombre

que el servicio (reboot). Si dicho archivo existe, la autentic ac ión pasa y el control es pasado al

siguiente módulo.

• #auth include system-auth — Esta línea es un comentario y no será procesada.

• account required pam_permit.so — Esta línea utiliza el módulo pam_permit.so para

permitir que el usuario root o cualquiera con una ses ión en la consola puede reiniciar el s istema.

43.4.3.2. Indicadores de control

Todos los módulos PAM generan un resultado de éxito o fracaso cuando se les llama. Los indic adores

de control le dicen a PAM qué hac er con el resultado. Como los módulos pueden apilarse en un

determinado orden, los indic adores de control le dan la posibilidad de fijar la importanc ia de un

módulo con respec to al objetivo final del proc eso de autenticac ión para el servicio.

Hay cuatro indic adores de control definidos :

• required — El resultado del módulo debe ser exitoso para que la autenticac ión continue.

Si la prueba falla, el usuario no es notificado hasta que los resultados en todos los módulos

referenc iando esa interfaz sean completados.

• requisite — El resultado del módulo debe ser exitoso para que la autentic ación continúe. Sin

embargo, si la prueba falla, el usuario es notif icado inmediatamente con un mensaje reflejando el

primer módulo required o requisite fallido.

• sufficient — El resultado del módulo es ignorado si falla. Pero si el resultado del módulo con el

indicador sufficient es exitoso y ningún módulo con indicador required ha fallado, entonc es

no se requiere ningún otro resultado y el usuario es autentic ado para el servicio.

• optional — Se ignora el resultado del módulo.Un módulo con una bandera optional sólo es

nec esario para la autentic ac ión exitosa cuando no hay otros módulos hac iendo referenc ia a la

interfaz.

Importante

El orden en el cual se llaman los módulos required no es crítico. Las banderas o

indic adores de control sufficient y requisite provocan que el orden se vuelva

importante.

Ahora PAM dispone de una nueva sintaxis de control de banderas que permite un control más

prec iso.

The pam.d man page, and the PAM doc umentation, loc ated in the /usr/share/doc/

pam-<version-number>/ directory, where <version-number> is the version number for PAM on

your system, describe this newer syntax in detail.

43.4.3.3. Nombre del módulo

El nombre del módulo le proporc iona a PAM el nombre del módulo que contiene la interfaz del módulo

espec if ic ada. Bajo las vers iones anteriores de Red Hat Enterprise Linux, se proporc ionaba la ruta

674

Formato del archivo de configuración PAM

completa al módulo dentro del archivo de configurac ión PAM. Sin embargo, desde el advenimiento de

s istemas multilib, que almacenan módulos PAM de 64-bits dentro del directorio /lib64/security/,

el nombre del directorio es omitido debido a que las aplic ac iones son enlazadas a la vers ión

apropiada de libpam, el cual puede ubicar la versión correcta del módulo.

43.4.3.4. Argumentos de módulo

PAM utiliza argumentos para transmitir información a un módulo conec table durante la autentic ac ión

para algunos módulos.

Por ejemplo, el módulo pam_userdb.so usa información almac enados en un archivo Berkeley DB

para autentic ar a los usuarios. La base de datos Berkeley DB es una base de datos de código abierto

incorporada en muchas aplic ac iones. El módulo toma un argumento db para que la base de datos

Berkeley DB conozc a qué base de datos usar para el servicio solic itado.

The following is a typical pam_userdb.so line in a PAM configuration. The <path-to-file> is the

full path to the Berkeley DB database file:

auth re quire d pam_userdb.so db= <path- to-file >

Los argumentos inválidos generalmente son ignorados y no afectan en ningún modo el éxito o frac aso

del módulo PAM. Sin embargo, algunos módulos reportarán un error al archivo /var/log/secure.

43.4.4. Muestras de archivos de config uració n PAM

A continuac ión se presenta una mues tra de archivo de configurac ión de la aplicac ión PAM:

#%PAM-1.0

auth require d pa m_sec uretty.so

auth re quire d pam_unix.so nullok

auth re quired pam_nologin.so

account required pam_unix.so

password required pa m_crac klib.so retry=3

password required p am _ un ix . so sh ado w nullok use_authtok

session require d pam_unix.so

• La primera línea es un comentario como lo es toda línea que inicie con el carácter #.

• Las líneas dos, tres y cuatro apilan tres módulos a usar para autentif icac iones de inicio de ses ión.

auth required pam_securetty.so — Este módulo se asegura de que si el usuario está

tratando de conec tarse como root, el tty en el cual el usuario se está c onec tando está listado en el

archivo /etc/securetty, si ese archivo existe.

Si el tty no se lista en el archivo, cualquier intento de iniciar una ses ión como root fallará con el

mensaje Login incorrect.

auth required pam_unix.so nullok — Este módulo le solicita al usuario una c ontraseña y

luego verif ica la contraseña usando la información almac enada en /etc/passwd y, si existe, en /

etc/shadow.

• El argumento nullok instruye al módulo pam_unix.so a que permita una contraseña en

blanc o.

675

Creac ión de módulos PAM

• auth required pam_nologin.so — Este es el paso final de la autentic ac ión. Verifica si el

archivo /etc/nologin existe. Si existe y el usuario no es root, la autentic ación falla.

Nota

En este ejemplo, los tres módulos auth son revisados, aún si el primer módulo

auth falla. Esto previene que el usuario sepa en qué nivel la autentic ación falla.

Tal conoc imiento en las manos de una persona mal intenc ionada le permitiría violar

el s istema fác ilmente.

• account required pam_unix.so — Este módulo realiza cualquier verif icación de cuenta

nec esaria. Por ejemplo, si las contraseñas shadow han sido activadas, el componente de la

cuenta del módulo pam_unix.so verif icará para ver si la cuenta ha expirado o si el usuario no ha

cambiado la contraseña dentro del período de gracia otorgado.

• password required pam_cracklib.so retry=3 — Si la c ontraseña ha expirado, el

componente de la c ontraseña del módulo pam_cracklib.so le pide una nueva c ontraseña. Luego

evalúa la nueva c ontraseña para ver si puede ser fác ilmente determinada por un programa que

desc ubre las contraseñas basadas en diccionarios.

• El argumento retry=3 espec if ic a que si la prueba falla la primera vez, el usuario tiene dos

opc iones más para crear una contraseña mejor.

• password required pam_unix.so shadow nullok use_authtok — This line spec if ies

that if the program changes the user's passw ord, it should use the password interfac e of the

pam_unix.so module to do so.

• The argument shadow instructs the module to create shadow passw ords when updating a user's

passw ord.

• El argumento nullok indica al módulo que permita al usuario c ambiar su contraseña desde

una contraseña en blanco, de lo contrario una contraseña vacía o en blanco es tratada como un

bloqueo de cuenta.

• El argumento final de esta línea, use_authtok, proporc iona un buen ejemplo de la importanc ia

del orden al apilar módulos PAM. Este argumento advierte al módulo a no solicitar al usuario

una nueva contraseña. En su lugar se acepta c ualquier c ontraseña que fue registrada por un

módulo de contraseña anterior. De este modo, todas las nuevas c ontraseñas deben pasar el test

de pam_cracklib.so para contraseñas seguras antes de ser aceptado.

• session required pam_unix.so — La última línea espec if ic a que el componente de la ses ión

del módulo pam_unix.so gestionará la ses ión. Este módulo registra el nombre de usuario y el

tipo de servicio a /var/log/secure al inicio y al final de cada sesión. Puede ser complementado

apilándolo con otros módulos de ses ión si nec es ita más funcionalidad.

43.4.5. Creación de módulos PAM

Puede crear o añadir nuevos módulos PAM en cualquier momento para utilizar con aplic ac iones que

soporten PAM .

676

Creac ión de módulos PAM

Por ejemplo, un desarrollador puede crear un método de creac ión de c ontraseña de una sola vez y

escribir un módulo PAM que lo soporte. Los programas que soporten PAM pueden inmediatamente

usar el nuevo módulo y el método de c ontraseña s in tener que compilar de nuevo o realizar alguna

otra modificac ión.

Esto le permite a los desarrolladores y administradores de s istemas mezc lar y coincidir, así como

también evaluar, métodos de autenticac ión para programas diferentes sin tener que compilarlos

nuevamente.

Doc umentation on writing modules is included in the /usr/share/doc/pam-<version-number>/

directory, where <version-number> is the version number for PAM on your system.

43.4.6. PAM y el caché de credenciales administrativas

Varias herramientas gráfic as administrativas bajo Red Hat Enterprise Linux otorgan a los usuarios

privilegios espec iales por un tiempo máximo de 5 minutos a través del módulo pam_timestamp.so.

Es importante entender cómo funciona este mec anismo puesto que un usuario que deja su terminal

mientras pam_timestamp.so está en efecto, deja la máquina abierta a la manipulac ión por

cualquiera con acceso físico a la consola.

Bajo el esquema de marc as de tiempo de PAM, la aplic ación administrativa gráfica pide al usuario la

contraseña de root cuando se ejecuta. Una vez autentic ado, el módulo pam_timestamp.so crea un

archivo de marc a de tiempo (timestamp) dentro del directorio /var/run/sudo/ por defecto. Si el

archivo timestamp ya existe, otros programas gráficos administrativos no le pedirán la contraseña. En

vez de esto, el módulo pam_timestamp.so refresc ará el archivo times tamp, reservando unos cinco

minutos extra de acceso administrativo para el usuario.

You can verify the actual state of the timestamp file by inspecting the /var/run/sudo/<user> f ile.

For the desktop, the relevant f ile is unk no wn:root. If it is present and its times tamp is less than five

minutes old, the credentials are valid.

La existenc ia de arc hivos timestamp se indica con un icono de autentic ac ión que aparece en el área

de notificación del panel.

Figura 43.7. El icono de autentic ac ión

43.4.6.1. Eliminar el archivo timestamp

Es recomendable que antes de dejar desatendida una c onsola donde está activo un timestamp

PAM, se des truya el archivo timestamp. Para hac erlo desde un ambiente gráfico, pulse en el icono

de autentic ac ión en el panel. Cuando aparezc a una ventana de diálogo, pulse en el botón Olvidar

autorización

677

PAM y propiedad del dispos itivo

Figura 43.8. Diálogo de rechazo de la autenticac ión

Debe tener en cuenta los siguientes s iguientes aspec tos ac erc a del archivo timestamp de PAM:

• Si está conectándose a un sis tema remotamente usando ssh, utilice el c omando /sbin/

pam_timestamp_check -k root para destruir el archivo times tamp.

• Debe ejec utar el comando /sbin/pam_timestamp_check -k root desde la misma ventana de

terminal desde la cual usted ejec utó la acción privilegiada.

• Debe estar c onectado como el usuario que invocó originalmente el módulo pam_timestamp.so

para poder utilizar el comando /sbin/pam_timestamp_check -k. No se conecte como usuario

root para ejec utar es te c omando.

• Si desea eliminar las credenc iales en el escritorio (sin utilizar Olvidar autorización en el icono),

utilice el s iguiente comando:

/sbin/pam_timestamp_check -k root </de v/null >/de v/null 2>/de v/null

Si el uso de este c omando falla, sólo se removerá la credenc ial (si ésta existe) del pty donde se

ejec uta el comando.

Para información sobre cómo destruir el archivo timestamp usando pam_timestam p_che ck ,

ref iérase a la página man de pam_timestamp_che ck .

43.4.6.2. Directivas pam_timestamp comunes

El módulo pam_timestamp.so ac epta muc has directivas. Abajo están las opc iones más

comúnmente usadas:

• timestamp_timeout — Espec if ic a el número de segundos durante los cuales el archivo

timestamp es válido. El valor por defecto es 300 segundos (cinco minutos).

• timestampdir — Espec if ic a el directorio en el cual se almacena el archivo de estampilla de

tiempo. El valor por defecto es /var/run/sudo .

Refer to Sección 43.4.8.1, “Documentación instalada” for more information about controlling the

pam_timestam p.so module.

43.4.7. PAM y pro pieda d del dispositivo

Red Hat Enterprise Linux permite que el primer usuario que se conecte en una consola física de la

máquina pueda manipular algunos dispos itivos y realizar algunas tareas normalmente reservadas

para el usuario root. Esto es controlado por un módulo PAM llamado pam_console.so.

678

PAM y propiedad del dispos itivo

43.4.7.1. Propiedad del dispositivo

Cuando un usuario inicia una ses ión en un sistema Red Hat Enterprise Linux, el módulo

pam_console.so es llamado por login o los programas de inicio de ses ión gráfica, gdm, kdm y

xdm. Si este usuario es el primero en conectarse en la consola física — llamado usuario de consola

— el módulo le conc ede al usuario la propiedad de algunos dispos itivos que normalmente pertenec en

a root. El usuario de la consola posee estos dispos itivos hasta que la última ses ión local para ese

usuario f inalice. Una vez que el usuario se ha desc onec tado, la propiedad de los dispos itivos vuelve a

root.

Los dispos itivos afectados incluyen, pero no son limitados, las tar jetas de sonido, las unidades de

disco y las unidades de CD-ROM.

Esto permite que el usuario local manipule es tos dispos itivos sin llegar a tener acceso root

simplificando así las tareas c omunes para el usuario de la consola.

Puede modificar la lista de dispos itivos c ontrolados por pam_console.so si se editan las siguientes

lineas :

• /etc/security/console.perms

• /etc/security/console.perms.d/50-default.perms

Usted puede cambiar los permisos de diferentes dispos itivos que aquellos lis tados en los archivos

anteriores o sobreescribir las espec if ic ac iones predeterminadas. En vez de modificar el archivo 50-

default.perms, usted debe crear un nuevo archivo (por ejemplo, xx-name.perms) e introducir

la modificación requerida. El número del nuevo archivo predeterminado debe iniciar con un número

superior a 50 (por ejemplo 51-default.perms). Esto sobreescribirá los valores predeterminados en

el archivo 50-default.perms

Atención

If the gdm, kdm, or xdm display manager configuration file has been altered to allow

remote users to log in and the host is configured to run at runlevel 5, it is advisable

to change the <console> and <xconsole> directives in the /etc/security/

console.perms to the following values :

<c onsole >=tty[0-9][0-9]* vc/[0-9][0-9]* :0\.[0-9] :0

<xconsole >=:0\.[0-9] :0

Ésto previene que los usuarios remotos obtengan acc eso a los dispos itivos y a las

aplicac iones restr ingidas en la máquina.

If the gdm, kdm, or xdm display manager configuration file has been altered to allow

remote users to log in and the host is configured to run at any multiple user runlevel

other than 5, it is advisable to remove the <xconsole> directive entirely and c hange

the <console> directive to the following value:

<console >=tty[0-9][0-9]* vc/[0-9][0-9]*

679

Rec ursos adic ionales

43.4.7.2. Acceso de la aplicación

También se le permite al usuario de la c onsola el acceso a ciertos programas configurados para este

fin en /etc/security/console.apps/.

Este directorio contiene archivos de configurac ión que permiten que el usuario de la consola ejec ute

ciertas aplic ac iones en /sbin y /usr/sbin.

Estos arc hivos de configuración tienen el mismo nombre que las aplic ac iones que configuran.

Un grupo notable de aplic ac iones a las que tiene acceso el usuario de la consola son tres programas

que cierran o abren el s istema:

• /sbin/halt

• /sbin/reboot

• /sbin/poweroff

Debido a que estas aplic ac iones soportan PAM, ellas llaman al módulo pam_console.so como un

requerimiento para el uso.

Refer to Sección 43.4.8.1, “Documentación instalada” for more information.

43.4.8. Recursos adicionales

Los siguientes rec ursos explican los métodos para el uso y configurac ión de PAM. Además de estos

rec ursos, lea los archivos de configurac ión de PAM en el s is tema para entender mejor como están

estruc turados.

43.4.8.1. Documentación instalada

• Las páginas man relac ionadas con PAM — Hay un número de páginas man para las diferentes

aplic ac iones y archivos de configurac ión relac ionados con PAM. :La lista siguiente muestra algunas

de las páginas man más importantes.

Archivos de configurac ión

• pam — Información de introducción sobre PAM. Incluye la estructura y propós itos de los

archivos de configurac ión de PAM.

Tenga en cuenta que es ta página man discute tanto /etc/pam.conf como los archivos de

configurac ión individuales en el directorio /etc/pam.d/. Por defec to, Red Hat Enterprise

Linux utiliza los archivos de configuración individuales en el directorio /etc/pam.d/,

ignorando /etc/pam.conf incluso si éste exis te

• pam_console — Describe el propós ito del módulo pam_console.so. También describe la

sintaxis adecuada para una entrada en el archivo de configurac ión PAM.

• console.apps — Describe el formato y las opciones disponibles dentro de /etc/

security/console.apps, el archivo de configurac ión que define c uáles aplic ac iones

permiten acceso al usuario de la c onsola as ignado por PAM.

• console.perms — Describe el formato y las opciones disponibles dentro de /etc/

security/console.perms, el archivo de configuración para los permisos del usuario de la

consola as ignado por PAM.

680


• pam_timestamp — Describe el módulo pam_timestamp.so.

• /usr/share/doc/pam-<version-number> — Contains a System Administrators' Guide, a

Module Writers' Manual, and the Application Developers' Manual, as well as a copy of the PAM

standard, DCE-RFC 86.0, where <version-number> is the version number of PAM.

• /usr/share/doc/pam-<version-number>/txts/README.pam_timestamp — Contains

information about the pam_timestamp.so PAM module, where <version-number> is the

version number of PAM.

43.4.8.2. Sitios web útiles

• http://www.kernel.org/pub/linux/libs/pam/ — El sitio web de distribución primario para el

proyecto Linux-PAM, conteniendo información sobre varios módulos PAM, una secc ión FAQ y

doc umentac ión PAM adic ional.

Nota

La documentac ión en el sitio web menc ionado anteriormente describe la última

versión de PAM y puede que no sea completamente compatible con la versión de

PAM incluida en Red Hat Enterprise Linux.

43.5. TCP Wrappers y xinetd Controlling access to network servic es is one of the most important security tasks facing a server

adminis trator. Red Hat Enterprise Linux provides several tools for this purpose. For example, an

iptables-based firewall filters out unwelcome network pac kets within the kernel's network stack.

For network servic es that utilize it, TCP Wrappers add an additional layer of protection by defining

which hosts are or are not allowed to connect to "wrapped" network services. One such wrapped

network servic e is the xinetd super server. This service is called a super server bec ause it controls

connections to a subset of network servic es and further refines access c ontrol.

Figura 43.9, “Control de acceso a los servicios de red” is a basic illustration of how these tools work

together to protect network servic es.

http://www.kernel.org/pub/linux/libs/pam/

681

TCP Wrappers

Figura 43.9. Control de acceso a los servic ios de red

43.5.1. TCP Wrappers

El paquete TCP wrappers (tcp_wrappers) está instalado por defecto y proporc iona control de

acceso basado en host a los servicios de red. El componente más importante dentro del paquete es

la biblioteca /usr/lib/libwrap.a. En términos generales, un servicio TCP wrapped es uno que ha

sido compilado con la biblioteca libwrap.a.

When a connection attempt is made to a TCP-wrapped service, the servic e first referenc es the host's

access files (/etc/hosts.allow and /etc/hosts.deny) to determine whether or not the client is

allowed to connec t. In most cases, it then uses the syslog daemon (syslogd) to write the name of the

requesting client and the requested servic e to /var/log/secure or /var/log/messages.

Si a un cliente se le permite conectarse, los TCP Wrappers liberan el control de la conexión al servic io

solicitado y no interfieren más con la comunicac ión entre el cliente y el servidor.

Además del control de acceso y registro, los TCP Wrappers pueden activar comandos para

interactuar con el cliente antes de negar o liberar el control de la conexión al servicio solicitado.

Bec ause TCP Wrappers are a valuable addition to any server administrator's arsenal of security tools,

most network servic es within Red Hat Enterprise Linux are linked to the libwrap.a library. Some

suc h applic ations include /usr/sbin/sshd, /usr/sbin/sendmail, and /usr/sbin/xinetd.

682

TCP Wrappers

Nota

Para determinar si un servicio de red binario está enlazado con la librería

libwrap.a, escriba el comando s iguiente como usuario root:

ldd <binary-name> | grep libwra p

Replace <binary-name> with the name of the network servic e binary.

Si el comando retorna al intérprete de comandos sin ninguna salida, entonc es el

servicio de red no está enlazado con libwrap.a.

El s iguiente ejemplo muestra que /usr/sbin/sshd está enlazado a libwrap.a:

[root@myserver ~]# ldd /usr/sbin/sshd | gre p libwrap

libwra p.so.0 => /usr/lib/libwrap.so.0 (0x00655000)

[root@myserver ~]#

43.5.1.1. Ventajas de los TCP Wrappers

Los TCP Wrappers ofrec en las siguientes ventajas bás ic as c omparado con las otras técnicas de

control de servic ios de red:

• Transparencia tanto para el host cliente y el servicio de red encapsulado — Tanto el cliente que

está realizando la conexión como el servicio de red enc apsulado no están al tanto de que TCP

Wrappers está s iendo usado. Los usuarios legítimos son registrados y c onectados al servicio

solicitado mientras que las conexiones de clientes prohibidos fallan.

• Administración centralizada de múltiples protocolos. — Los TCP Wrappers operan separadamente

de los servic ios de red que ellos protegen, permitiendo a muc has aplic ac iones de servidor compartir

un conjunto común de archivos de configurac ión para una administrac ión más sencilla.

43.5.2. Archivos de config uració n de Wrappers TCP

Para determinar si una máquina cliente tiene permitido c onec tarse a un servicio, los TCP Wrappers

consultan los siguientes dos archivos, los cuales se c onoc en comúnmente como archivos de acceso a

host :

• /etc/hosts.allow

• /etc/hosts.deny

Cuando un servicio que usa TCP-w rappers recibe una petición de un cliente, se s iguen los siguientes

pasos:

1. Referencias a /etc/hosts.allow . — El servicio wrapped TCP analiza sec uenc ialmente

el archivo /etc/hosts.allow y aplica la primera regla espec if ic ada para ese servicio. Si

enc uentra una regla que coincide, permite la conexión. De lo contrario continúa con el paso

siguiente.

mailto:root@myserver


683

Archivos de configurac ión de Wrappers TCP

2. Referencia a /etc/hosts.deny. — El servicio wrapped TCP analiza sec uenc ialmente el archivo

/etc/hosts.deny. Si encuentra una regla que coincide, rechaza la conexión. De lo contrario, el

acceso al servicio es c oinc idido.

Los puntos s iguientes se deben c ons iderar cuando se usen TCP-wrappers para proteger servic ios de

red:

• Pues to que las reglas de acceso en hosts.allow son aplic adas primero, ellas toman

prec edenc ia 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 enc uentra ninguna regla para el servicio en ninguno de los archivos, o si no existe ninguno

de los archivos, se c onc ede el acceso al servic io.

• Los sevic ios encapsulados con TCP wrappers no hac en c ac hé de las reglas desde los archivos de

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 pres ionar 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. Es te

es también el caso para reglas que se expanden en múltiples líneas s in usar la barra

oblicua. El ejemplo s iguiente 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: miss ing ne wline or line too long

43.5.2.1. Formatear reglas de acceso

Los formatos para /etc/hosts.allow y /etc/hosts.deny son idénticos. Cualquier línea en

blanco o que comienc e con un símbolo de numeral (#) será ignorada.

Las reglas se tienen que formatear de la s iguiente manera:

<da emon list>: <client list> [: <o p tio n >: <o p tio n >: ...]

• <daemon list> — A c omma-separated list of proc ess names (not service names) or the ALL

wildcard. The daemon list also acc epts operators (refer to Sección 43.5.2.1.4, “Operadores”) to

allow greater flexibility.

• <client list> — A comma-separated list of hos tnames, host IP addresses, spec ial patterns, or

wildcards which identify the hosts affec ted by the rule. The client list also acc epts operators listed in

Sección 43.5.2.1.4, “Operadores” to allow greater f lexibility.

684


• <option> — An optional action or colon-separated list of actions performed when the rule is

triggered. Option fields support expans ions, launch shell commands, allow or deny access, and alter

logging behavior.

Nota

En esta guía puede encontrar mayor información sobre los términos espec ializados

arriba menc ionados :

• Sección 43.5.2.1.1, “Comodines”

• Sección 43.5.2.1.2, “Patrones”

• Sección 43.5.2.2.4, “Expansiones”

• Sección 43.5.2.2, “Campos de opciones”

A continuación una mues tra bás ic a de una regla de acceso:

vs ftpd : .example.com

Esta regla instruye a los TCP Wrappers a que estén atentos por conexiones al demonio FTP

(vsftpd) desde c ualquier host en el dominio example.com. Si esta regla aparece en

hosts.allow, la conexión será ac eptada. Si esta regla aparece en hosts.deny, la conexión será

rec hazada.

El próximo ejemplo de regla de acceso es un poco más compleja y utiliza dos campos de opc iones :

sshd : .example.com \ : sp awn /bin/echo `/bin/date` access de nie d>>/var /log/sshd. log \ : den y

Note que cada c ampo de opción está prec edido por una barra oblicua invertida (\). Use la barra para

prevenir que falle la regla debido al largo de la misma.

This sample rule states that if a connection to the SSH daemon (sshd) is attempted from a host in

the example.com domain, exec ute the echo c ommand to append the attempt to a spec ial log file,

and deny the connection. Bec ause the optional de ny directive is used, this line denies access even

if it appears in the hosts.allow file. Refer to Sección 43.5.2.2, “Campos de opciones” for a more

detailed look at available options.

43.5.2.1.1. Comodi nes

Los comodines permiten a los TCP Wrappers coincidir más fácilmente grupos de demonios o hos ts.

Son usados con mayor frecuenc ia en el campo de lista de cliente de las reglas de acceso.

Se pueden utilizar los siguientes c omodines :

• ALL — Hace corresponder todo. Se puede usar tanto para la lista de demonios como para la lista

de clientes.

• LOCAL — Hace corresponder todos los nombres de máquinas que no contengan un punto (.), tal

como localhost.

685


• KN OWN — Hace corresponder todas las máquinas cuyos nombres y direcc iones son conoc idos o

donde el usuario es c onoc ido.

• UNKN OWN — Hace corresponder todas las máquinas cuyos nombres y direcc iones sean

desc onoc idas o en el caso en el que se desconozca el usuario.

• PARANOID — Hace corresponder todas las máquinas cuyo nombre no se c orresponda con la

dirección.

Atención

Los comodines KN OWN, UN KN OWN y PARANOID que usarse con cuidado ya que

dependen de servidores DNS en funcionamiento para una correcta operac ión.

Cualquier error en la resoluc ión de nombres puede impedir que usuarios legítimos

accedan al servicio.

43.5.2.1.2. Patrones

Los patrones se pueden utilizar en el campo de lista de cliente de las reglas de acceso para

espec if ic ar de forma más prec isa grupos de host clientes.

La s iguiente es una lista de los patrones más comúnmente ac eptados 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 c ompartiendo los componentes listados del nombre. El

ejemplo siguiente aplic arí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 c ompartiendo 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 expres iones de máscaras de red también pueden ser usadas

como un patrón de control de acceso a un grupo particular de direcc iones IP. El ejemplo s iguiente

aplic arí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 espac io de direcc iones de IPv4, no se soporta el

largo del par dirección/prefijo (prefixlen). Sólo las reglas IPv6 pueden utilizar este

formato.

686


• 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 direcc iones IPv6. El

ejemplo siguiente aplic arí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 asterisc os pueden ser usados para coincidir grupos completos de nombres de

host o direcc iones IP, s iempre y cuando no se mezc len en la lista de cliente c onteniendo otros tipos

de patrones. El ejemplo s iguiente aplic aría a cualquier host dentro del dominio example.com:

ALL : *.example.com

• La barra oblicua (/) — Si una lista de cliente inicia con una barra, ésta es tratada como un nombre de

archivo. Esta caracterís tic a es útil si se necesitan reglas que espec if iquen un gran número de hosts.

El ejemplo s iguiente se refiere a los TCP Wrappers en el archivo /etc/telnet.hosts para todas

las conexiones de Telnet:

in.telnetd : /etc/telnet.hosts

Otros patrones menos usados son también ac eptados por los TCP Wrappers. Consulte la página man

(5) de hosts_access para obtener mayor informac ión.

Aviso

Pres te espac ial atenc ión al usar nombres de host y de dominio. Los invasores

pueden usar una variedad trucos para burlar las resoluc ión de nombres. Además,

cualquier interrupción en el servicio DNS podría impedir el acceso a servic ios inc luso

a la usuarios que tienen el permiso. Lo mejor es utilizar direcc iones IP s iempre que

sea posible.

43.5.2.1.3. Portmap y Wrappers TCP

Portmap's implementation of TCP Wrappers does not support host look-ups, which means

portmap can not use hos tnames to identify hosts. Consequently, acc ess control rules for portmap in

hosts.allow or hosts.deny must use IP addresses, or the keyword ALL, for specifying hosts.

Cambios a las reglas de control de acceso de portmap pueden que no tomen efecto de inmediato.

Usted si no se reinicia el servicio portmap.

Los servic ios ampliamente usados, tales como NIS y NFS, dependen de portmap para funcionar, por

lo tanto esté c onsc iente de estas limitac iones.

43.5.2.1.4. Operadores

Ac tualmente, 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.

687


El operador EXCEPT permite exc epc iones específ ic as a coinc idenc ias más amplias dentro de la

misma regla.

En el ejemplo s iguiente desde un archivo hosts.allow, todos los hosts de example.com pueden

conectarse a todos los servic ios exc epto cracker.example .com :

ALL: .example.com EXCEPT cracker.example.com

En el otro ejemplo desde un archivo hosts.allow, c lientes desde la red 192.168.0.x pueden usar

todos los servic ios exc epto para FTP:

ALL EXCEPT vsftpd: 192.168.0.

Nota

Organizac ionalmente, a menudo es más fácil evitar el uso de operadores EXCEPT.

Esto permite a otros administradores esc anear rápidamente los archivos adecuados

para ver qué hos ts deberían tener o no acceso a los servic ios, sin tener que revisar

varios operadores EXCEPT.

43.5.2.2. Campos de opciones

Además de las reglas bás ic as para permitir o prohibir el acceso, la implementac ión de Red Hat

Enterprise Linux de TCP Wrappers soporta extens iones al lenguaje de control de acceso a través

de los campos de opciones. Mediante el uso de campos de opc iones dentro de las reglas de acceso

al host, los adminis tradores 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.

43.5.2.2.1. Registro

Los campos de opc iones le permiten a los administradores cambiar fácilmente la facilidad de regis tro

y el nivel de prioridad para una regla usando la directiva severity.

En el ejemplo s iguiente, las conexiones al demonio SSH desde c ualquier host en el dominio

example.com son registrados a la facilidad por defecto authpriv syslog (debido a que no se

espec if ic a un valor de facilidad) con una prioridad de emerg:

sshd : .example.com : sever ity e merg

Es también posible espec if ic ar una facilidad utilizando la opción severity. El ejemplo s iguiente

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

688


Nota

En práctic a, este ejemplo no func ionará hasta que el demonio syslog (syslogd) sea

configurado para regis trar a la facilidad local0. Consulte la página del manual de

syslog.conf para información sobre la configurac ión de las fac ilidades de registro

personalizadas.

43.5.2.2.2. Control de acceso

Los campos de opc iones también le permiten a los administradores explíc itamente otorgar o prohibir

el acceso de máquinas en un sola regla, añadiendo la directiva allow o de ny al f inal de la opc ión.

Por ejemplo, las dos reglas s iguientes permiten conexiones SSH desde client-1.example.com,

pero prohiben c onexiones desde client-2.example.com:

sshd : client-1.e xample.com : allow

sshd : client-2.e xample.com : den y

Al permitir el control de acceso por regla, el campo de opc iones permite a los adminis tradores

consolidar todas las reglas de acceso en un sólo archivo: bien sea hosts.allow o hosts.deny.

Algunos cons ideran que esta es una forma más fácil de organizar reglas de acceso.

43.5.2.2.3. Comandos de la Shell

Los campos de opc iones permiten a las reglas de acceso lanzar comandos de la shell a través de las

directivas s iguientes :

• spawn — Lanza un comando de la shell como un proc eso 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 solic itante o la creac ión de archivos de registro espec iales usando el comando echo.

En el ejemplo s iguiente, los clientes intentando acc eder a servic ios de Telnet desde el dominio

example.com son registrados discretamente a un archivo espec ial:

in.telnetd : .example.com \

: sp awn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \

: allow

• twist — Replac es the reques ted servic e with the spec if ied command. This directive is often used

to set up traps for intruders (also called "honey pots"). It can also be used to send messages to

connecting clients. The twist directive must occur at the end of the rule line.

En el ejemplo s iguiente, los clientes que intentan acc eder al servicio FTP desde el dominio

example.com se les envía un mensaje a través del comando echo:

vs ftpd : .example.com \

: twis t /bin/ec ho "421 This domain has been black-listed. Access de nie d!"

Para obtener mayor información sobre las opc iones de comando de la shell, consulte la página del

manual de hosts_options.

689


43.5.2.2.4. Expansiones

Las expans iones, c uando se utilizan en conjunto con las directr ic es spawn y twist, proporc ionan

información sobre el cliente, servidor y los proc esos relac ionados.

A continuac ión se presenta una lista de las expans iones soportadas :

• %a — Returns the client's IP address.

• %A — Returns the server's IP address.

• %c — Proporc iona 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 — Proporc iona el nombre del proc eso demonio.

• %h — Returns the client's hostname (or IP address, if the hos tname is unavailable).

• %H — Returns the server's hostname (or IP address, if the hostname is unavailable).

• %n — Returns the client's hostname. If unavailable, unknown is printed. If the client's hostname and

host address do not match, paranoid is printed.

• %N — Returns the server's hostname. If unavailable, unknown is printed. If the server's hostname

and host address do not match, paranoid is printed.

• %p — Returns the daemon's proc ess ID.

• %s — Suministra información varia del servidor como el proc eso demonio y la máquina o la

dirección IP del servidor.

• %u — Returns the client's username. If unavailable, unknown is printed.

El ejemplo siguiente usa una expans ió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,

ejec ute el comando e cho para regis trar el intento, inc luyendo el nombre del host cliente (usando la

expans ión %h), a un archivo espec ial:

sshd : .example.com \

: sp awn /bin/echo `/bin/date` access denied to %h>>/va r/log/s shd.log \

: den y

De forma similar, las expans iones se pueden utilizar para personalizar mensajes de vuelta al

cliente. En el ejemplo siguiente, los clientes que intentan acc eder al servicio FTP desde el dominio

example.com son informados que se les ha prohibido acc eder al servidor:

vs ftpd : .example.com \

: twis t /bin/ec ho "421 %h has been banned from this server!"

Para una explicac ión completa de las expans iones disponibles, así como también opc iones de

control de acceso adic ionales, revise la secc ión 5 de la página man para hosts_access (man 5

hosts_access) y la página man de hosts_options.

690


Refer to Sección 43.5.5, “Recursos adicionales” for more information about TCP Wrappers.

43.5.3. xinetd

El demonio xinetd es un super servicio que utiliza TCP-wrappers. Éste controla el acceso a un

subc onjunto de servic ios de red populares inc luyendo FTP, IMAP y Telnet. También proporc iona

opc iones de configurac ión específ ic as al servicio para el control de acceso, registro mejorado,

redirecc ionamiento y control de utilización de recursos.

Cuando un cliente intenta conec tarse a un servicio de red controlado por xinetd, el super servic io

recibe la petición y revisa las reglas de control de acceso de TCP Wrappers.

Si el acceso es permitido, xinetd verifica que la conexión este permitida bajo sus propias reglas de

acceso para ese servicio. Asimismo verifica que el servicio no tiene más recursos as ignados a él y

que éste cumpla las reglas definidas.

Si todas estas c ondic iones son cumplidas (se permite al acceso al servicio; el servicio no ha llegado

a su límite de rec ursos ; y el servicio no viola ninguna regla), xinetd inicia una instanc ia del servic io

solicitado y pasa el control de la c onexión a éste. Una vez la c onexión se ha establec ido, xinetd no

toma parte en la comunic ac ión entre el servidos y el cliente.

43.5.4. Archivos de config uració n de xinetd

Los archivos de configurac ión para xinetd son los siguientes :

• /etc/xinetd.conf — El archivo de configurac ión global de xinetd.

• /etc/xinetd.d/ — El directorio que contiene todos los archivos específ ic os al servic io.

43.5.4.1. El archivo /etc/xinetd.conf

The /etc/xinetd.conf file contains general configuration settings which affect every servic e under

xinetd's control. It is read when the xinetd servic e is first star ted, so for configuration changes to

take effect, you need to restart the xinetd servic e. The following is a sample /etc/xinetd.conf

file:

defaults

{

ins ta nce s = 6 0

log_type = SYSLOG authpriv

log_on_success = HOST PID

log_on_failure = HOST

cps = 25 30

}

includedir /etc/xinetd.d

Estas líneas c ontrolan los s iguientes aspec tos de xinetd:

• instances — Configura el máximo número de petic iones que xinetd puede manejar

simultáneamente.

• log_type — Configura xinetd para usar la facilidad de registro authpriv, el cual escribe las

entradas de registro al archivo /var/log/secure. Al agregar una directiva tal como FILE /

var/log/xinetdlog aquí, creará un archivo de registro personalizado llamado xinetdlog en el

directorio /var/log/.

691

Archivos de configurac ión de xinetd

• log_on_success — Configures xinetd to log successful connection attempts. By default, the

remote host's IP address and the proc ess ID of the server proc ess ing the request are rec orded.

• log_on_failure — Configura xinetd para regis trar si hay una falla de conexión o si la conexión

no es permitida.

• cps — Configura xinetd para no permitir más de 25 conexiones por segundo a cualquier servic io

dado. Si se alcanza este límite, el servicio es retirado por 30 segundos.

• includedir /etc/xinetd.d/ — Includes options dec lared in the service-spec if ic configuration

files loc ated in the /etc/xinetd.d/ directory. Refer to Sección 43.5.4.2, “El directorio /etc/

xinetd.conf” for more information.

Nota

Often, both the log_on_success and log_on_failure settings in /etc/

xinetd.conf are further modified in the service-specif ic configuration files. More

information may therefore appear in a given servic e's log file than the /etc/

xinetd.conf file may indic ate. Refer to Sección 43.5.4.3.1, “Opciones de registro”

for further information.

43.5.4.2. El directorio /etc/xinetd.conf

El directorio /etc/xinetd.d/ contiene los archivos de configuración para cada servicio manejado

por xinetd y los nombres de los archivos que se correlac ionan con el servicio. Como sucede c on

xinetd.conf, este archivo sólo es leído cuando el servicio xinetd es arranc ado. Para que los

cambios tengan efecto, el administrador debe reiniciar el servicio xinetd.

El formato de los archivos en el directorio /etc/xinetd.d/ usan las mismas c onvenc iones que /

etc/xinetd.conf. La razón principal por la que la configurac ión para cada servicio es almacenada

en un archivo separado es hacer más fácil la personalizac ión y que sea menos probable afectar otros

servic ios.

Para tener una idea de cómo estos arc hivos están estructurados, cons idere el archivo /etc/

xinetd.d/krb5-telnet:

service telnet

{

flags = REUSE

socket_type = stream

wait = n o

use r = root

serve r = /usr/kerberos/sbin/telnetd

log_on_failure += USERID

disa ble = yes

}

Estas líneas c ontrolan varios aspectos del servicio telnet:

• service — Define el nombre del servicio, usualmente uno listado en el archivo /etc/services.

• flags — Configura cualquier número de atr ibutos para la conexión. REUSE instruye xinetd a

reutilizar el socket para una conexión Telnet.

692


Nota

La opción REUS E está fuera de uso. Todos los servic ios utilizan implic itamente la

opción REUSE.

• socket_type — Configura el soc ket de red a escribir a stream.

• wait — Define si el servicio es de un sólo hilo (yes) o de múltiples hilos (no).

• user — Define bajo qué ID de usuario se ejec utará el proc eso.

• server — Define el binario ejec utable a lanzar.

• log_on_failure — Define los parámetros de registro para log_on_failure además de

aquellos ya definidos en xinetd.conf.

• disable — Espec if ic a si el servicio es tá desac tivado (yes) o activado (no).

Consulte la página man de xinetd.conf para obtener mayor información sobre es tas opc iones y su

uso.

43.5.4.3. Modificando los archivos de configuración de xinetd

Existe una gran cantidad de directivas disponibles para los servic ios protegidos por xinetd. Es ta

secc ión resalta algunas de las opc iones usadas más comúnmente.

43.5.4.3.1. Opciones de registro

Las siguientes opc iones de registro están disponibles para /etc/xinetd.conf y los archivos de

configurac ión específ ic os al servicio en el directorio /etc/xinetd.d/.

A continuac ión se presenta una lista de las opc iones de registro usadas más comúnmente:

• ATTEMPT — Indica que se intentó realizar una conexión pero que ésta falló (log_on_failure).

• DURATION — Indica el tiempo que un sis tema remoto usa un servicio (log_on_success).

• EXIT — Indica el estado de salida o la señal de término del servicio (log_on_success).

• HOST — Logs the remote host's IP address (log_on_failure and log_on_success).

• PID — Indica el ID del proc eso del servidor que recibe la petición (log_on_success).

• US ERID — Regis tra el usuario remoto que está usando el método definido en RFC 1413 para todos

los servic ios de multi proc esos (log_on_failure y log_on_success).

Para obtener una lista completa de las opc iones de registro, consulte la página de manual de

xinetd.conf.

43.5.4.3.2. Opciones de control de acceso

Users of xinetd servic es can c hoose to use the TCP Wrappers hosts acc ess rules, provide access

control via the xinetd configuration files, or a mixture of both. Refer to Sección 43.5.2, “Archivos de

configuración de Wrappers TCP” for more information about TCP Wrappers hosts acc ess control files.

693


Esta sección discute el uso de xinetd para controlar el acceso a servic ios.

Nota

A diferenc ia de los TCP Wrappers, los cambios al control de acceso sólo tengan

efecto si el administrador de xinetd reinicia el servicio xinetd.

A diferenc ia de los TCP Wrappers, el control de acceso a través de xinetd sólo

afec ta a los servic ios controlados por xinetd mismo.

The xinetd hosts access control differs from the method used by TCP Wrappers. While TCP

Wrappers plac es all of the access configuration within two files, /etc/hosts.allow and /etc/

hosts.deny, xinetd's access control is found in each servic e's configuration file in the /etc/

xinetd.d/ directory.

Las opc iones de acceso a host siguientes son soportadas por xinetd:

• only_from — Sólo permite que las máquinas espec íf ic as usen el servic io.

• no_access — Impide que estas máquinas usen el servicio.

• access_times — Espec if ic a el intervalo de tiempo en el que un determinado servicio puede ser

usado. El rango de tiempo debe espec if ic arse en formato de 24 horas, HH:MM-HH:MM.

Las opc iones only_from y no_access pueden usar una lista de direcc iones IP o nombres de

hos ts, o pueden espec if ic ar una red completa. Como los TCP Wrappers, c ombinando el control del

acceso xinetd con una configurac ión de conexión apropiada puede mejorar la seguridad mediante

el bloqueo de petic iones de hosts vetados mientras que graba c ada intento de conexión.

Por ejemplo, el s iguiente archivo /etc/xinetd.d/telnet puede ser usado para bloquear e l

acceso a Telnet desde un un grupo de red particular y restringir el rango de tiempo general que

inclusive los usuarios permitidos pueden c onectarse:

service telnet

{

disa ble = n o

flags = REUSE


wait = n o

use r = root



no_access = 172.16.45.0/24

log_on_success += PID HOST EXIT

access_times = 09:45-16:15

}

En este ejemplo, cuando un sistema cliente desde la red 10.0.1.0/24, tal como 10.0.1.2, intenta

acc eder el servicio Telnet, recibirá un mensaje indic ando lo s iguiente:

Connection closed by foreign host.

Además, sus intentos de conexión son regis trados en /var/log/messages como sigue:

694


Sep 7 14:58:33 localhost xinetd[5285]: F AIL: te lne t a ddre ss f rom= 172.16.45.107

Sep 7 14:58:33 localhost xinetd[5283]: START: telnet pid=5285 from=172.16.45.107

Sep 7 14:58:33 localhost xinetd[5283]: EXIT: telnet status=0 pid=5285 dura tion=0(sec)

Cuando esté usando TCP Wrappers en conjunto con controles de acceso xinetd, es importante

entender la relación entre los dos mec anismos de control de acceso.

A continuac ión se muestra el orden de las operac iones seguido por xinetd cuando un cliente solic ita

una conexión:

1. El demonio xinetd accede a las reglas de acceso a hos ts TCP Wrappers a través de una

llamada a la librería libwrap.a. Si alguna regla de rec hazo coincide con el host cliente, la

conexión se rechaza. Si una regla de ac eptac ión coincide con el host cliente, la conexión pasa a

xinetd.

2. El demonio xinetd verifica sus propias reglas de acceso para el servicio xinetd y el servic io

solicitado. Si una regla de rec hazo coincide con el host cliente la conexión es rec hazada. De lo

contrario, xinetd inicia una ins tanc ia del servicio solicitado y pasa el control de la conexión al

mismo.

Importante

Se debe tener espec ial c uidado cuando se use el control de acc eso wrappers TCP

en conjunto con los controles xinetd. Un error en la configuración puede generar

resultados no deseados.

43.5.4.3.3. Vincular y redirigir opciones

Los ficheros de configurac ión de servic ios para el comando xinetd también soportan la vinculación

del servicio a una dirección IP y el desvío de las petic iones entrantes para dicho servicio a otra

dirección IP, nombre de la máquina o puerto.

La vinculación es controlada con la opción bind que se encuentra en el archivo de configuración

espec íf ico del servicio, y une específ icamente el servicio a una dirección IP del sistema. Una vez

configurada, la opción bind sólo permite petic iones para la dirección IP apropiada para acceder al

servicio. De esta forma se pueden vincular servic ios diferentes a interfac es de red diferentes según

sea necesario.

Esto es útil sobre todo para los sis temas con múltiples adaptadores de red o con múltiples direcc iones

IP. En tales sistemas, los servic ios inseguros como Telnet, se pueden configurar de modo que solo

escuche a la interfaz conectada a una red privada, y no a la interfaz conectada a Internet.

La opción redirect acepta la dirección IP o el nombre de la máquina seguido del número de puerto.

Dice al servicio que desvíe todas las petic iones para dicho servicio a una localización y número de

puerto específ ic os. Esta característic a se usa para establec er otro número de puerto en el mismo

sis tema, desviar la petición a otra dirección IP en la misma máquina, c ambiar la petición a otro

s istema y puerto completamente diferentes o con la combinación de cualquiera de estas opciones.

De esta manera, un usuario que es tá c onec tado a un determinado servicio en un sistema puede ser

redirigido a otro sistema sin ninguna interrupc ión.

695


El demonio xinetd lleva a cabo es te desvío lanzando un proc eso que mantenga la c onexión entre

la máquina cliente que es tá mandando la petición y la máquina que está dando en ese momento el

servicio, transfir iendo los datos de un sis tema a otro.

El mayor beneficio de estas dos opc iones (bind y redirect) se obtiene c uando se usan juntas.

Vinculando un servicio a una dirección IP determinada en un sistema y luego desviando las petic iones

de dicho servicio a una segunda máquina que sólo puede ver la primera máquina, se puede usar

un sistema interno que ofrezca servic ios para una red completamente diferente. Alternativamente,

es tas opc iones se pueden usar para limitar la expos ic ión de un servicio determinado a una dirección

IP conoc ida, así como desviar todas las petic iones a ese servicio a otra máquina configurada

específ ic amente para ese objetivo.

Por ejemplo, cons idere un s istema que se usa como firewall con la caracterís tic a s iguiente para su

servicio Telnet:

service telnet

{


wait = n o


log_on_success += DUR ATI ON USERID


bind = 123.123.123.123

redirect = 10.0.1.13 23

}

Las opc iones bind y redirect en este archivo aseguran que el servicio Telnet en la máquina esté

enlazado con la dirección IP externa (123.123 .123 .123), la que se encarga de Internet. Además,

todas las petic iones del servicio Telnet enviadas a 123.123 .123 .123 son redir igidas a través de una

segunda tarjeta de red a una dirección IP interna (10.0.1.13) a la que solo tienen acceso el firewall

y los sis temas internos. El f irewall manda luego la comunic ac ión entre los dos sistemas y el s istema

que se es tá c onectando piensa que está c onectado a 123 .123.123.123 mientras que, de hec ho,

es tá c onectado a otra máquina.

Esta caracterís tic a es útil para los usuarios con conexiones de banda anc ha y con una única direcc ión

IP fija. Cuando se usa la NAT (de las siglas en inglés de Network Address Trans lation ), los sistemas

detrás de la máquina gatew ay, que están usando direcc iones IP internas, no están disponibles desde

afuera del s istema gatew ay. Sin embargo, c uando determinados servic ios controlados por xinetd

son configurados con las opc iones bind y redirect, la máquina gatew ay puede funcionar como

un proxy entre los sistemas externos y una máquina interna particular configurada para proporc ionar

el servicio. Además, las opc iones de control de acceso xinetd y de conexión están también

disponibles para protección adic ional.

43.5.4.3.4. Opciones de admi nistración de recursos

El demonio xinetd puede añadir un nivel bás ic o de protección de un ataque Denial of Servic e (DoS).

Abajo se encuentra una lista de las directivas que pueden ayudar en limitar la efectividad de tales

ataques:

• per_source — Define el número máximo de ins tanc ias para un servicio por dirección IP.

Acepta sólo enteros como argumentos y puede ser usado en xinetd.conf y los archivos de

configurac ión específ ic os al servicio xinetd.d/.

696


• cps — Define el máximo número de conexiones por segundo. Esta directiva toma dos argumentos

enteros separados por un espac io en blanco. El primero es el número máximo de conexiones

permitidas por segundo. El segundo es el número de segundos que xinetd debe esperar antes

de reactivar el servicio. Sólo acepta enteros como argumentos y puede ser usado en ambos

xinetd.conf y los archivos de configurac ión específ icos al servicio en el directorio xinetd.d/.

• max_load — Indica el umbral de uso del CPU para un servicio. Acepta un argumento en forma de

número de punto flotante.

El promedio de carga es una medición aproximada del número de proc esos que están activos en

un tiempo dado. Vea los comandos uptime, who, procinfo para obtener mayor informac ión

sobre el promedio de carga.

Hay más opc iones de administrac ión de recursos disponibles para xinetd. Consulte la página del

manual de xinetd.conf.


En la documentac ión del s is tema y en el web puede enc ontrar información adicional conc erniente a

los TCP Wrappers y a xinetd.


La documentac ión en su sistema es un buen lugar para comenzar a busc ar información sobre los

Wrappers TCP, xinetd y las opc iones de control de acceso.

• /usr/share/doc/tcp_wrappers-<version>/ — This directory contains a R EA D M E f ile that

discusses how TCP Wrappers work and the various hos tname and host address spoofing risks that

exis t.

• /usr/share/doc/xinetd-<version>/ — This directory contains a R EA D M E f ile that discusses

aspects of access control and a sample.conf file with various ideas for modifying service-specif ic

configuration f iles in the /etc/xinetd.d/ directory.

• Las páginas man relac ionadas a TCP wrappers y xinetd — Hay un buen número de páginas man

para las varias aplicac iones y archivos de configurac ión relac ionados con TCP wrappers y xinetd.

La s iguiente es una lista con las páginas man más importantes.

Aplic aciones de servidor

• man xinetd — La página del manual para xinetd.

Archivos de configurac ión

• man 5 hosts_access — La página del manual para los archivos de control de acceso TCP

Wrappers.

• man hosts_options — La página del manual para los campos de opc iones de TCP

Wrappers.

• man xinetd.conf — La página del manual listando las opc iones de configurac ión xinetd.

43.5.5.2. Sitios Web de utilidad

• http://www.xinetd.org/4

— El sitio principal de xinetd, contiene arc hivos de configuración de

ejemplo, una lista completa de las característic as y una secc ión de Preguntas más frecuentes FAQ.

http://www.xinetd.org/

697

Redes privadas virtuales (VPNs)

• http://www.macsecurity.org/resources/xinetd/tutorial.shtml — Un tutorial completo que disc ute las

diferentes formas de ajustar los archivos de configuración xinetd por defecto para cubrir objetivos

específ ic os.

43.5.5.3. Libros relacionados

• Hacking Linux Exposed por Brian Hatch, James Lee y George Kurtz; Osbourne/McGraw-Hill — Un

rec urso exc elente de seguridad con información sobre TCP Wrappers y xinetd.

43.6. Redes privadas virtuales (VPNs) Las organizac iones con varias oficinas satelitales se c onec tan a menudo con líneas dedic adas para

proteger los datos c onfidenc iales en tránsito. Por ejemplo, muchos negoc ios utilizan frame relay o

líneas ATM (Asynchronous Transfer Mode), como una solución de redes para enlazar una oficina con

las otras. Esto puede ser una propuesta c ostosa, espec ialmente para negoc ios pequeños o medianos

(SMB) que desean extenderse sin tener que pagar los altos costos asoc iados a circuitos digitales

dedic ados de nivel corporativo.

Para resolver este problema, se desarrollaron las Redes privadas virtuales (VPN). Siguiendo los

mismos principios func ionales de los circuitos dedic ados, las VPN permiten una comunicac ión digital

segura entre dos partes (o redes), creando una red de área amplia (WAN) a partir las Redes de área

local (LAN) exis tentes. La diferencia con respecto a frame relay o ATM está en el medio de transporte.

Las VPN transmiten sobre IP usando datagramas como capa de transporte, hac iendo un conducto

seguro a través de la Internet hasta la dirección de destino. La mayoría de las implementac iones de

software libre de VPN inc orporan es tándares abiertos y encriptac ión para enmasc arar aún más el

tránsito de datos.

Algunas organizac iones emplean soluc iones de hardw are VPN para aumentar la seguridad, mientras

que otras utilizan las implementac iones basadas en software o protocolos. Hay muchos fabric antes

con soluc iones de hardw are VPN tales como Cisco, Nortel, IBM y Checkpoint. Hay una solución

libre de VPN basada en software para Linux llamada FreeS/Wan que utiliza una implementac ión

es tandarizada de IPSec (o Protocolo de Seguridad de Internet). Estas soluc iones VPN, sin importar

si están basadas en hardw are o software, actúan como enrutadores espec ializados que se colocan

entre la conexión IP desde una oficina a la otra.

43.6.1. ¿Có mo funciona un VPN?

Cuando un paquete es transmitido desde un cliente, éste se envía a través de un router o gatew ay

VPN, el cual añade el Encabezado de autenticación (AH) para enrutamientos y autentic ación. Los

datos son luego encriptados y, finalmente, cerrados con una Carga de seguridad de encapsulación

(ESP). Esta última constituye las instrucc iones de control y desencriptac ión.

El enrutador VPN rec eptor extrae la informac ión, desencripta los datos y la enruta a su destino

(bien sea una estac ión de trabajo o un nodo en la red). Usando una conexión de red-a-red, el nodo

rec eptor en la red local recibe los paquetes desc ifrados y listos para ser proc esados. El proceso de

encriptac ión/desc ifrado en una conexión VPN de red-a-red es transparente al nodo local.

Con tal nivel de seguridad, un crac ker debe no sólo interc eptar un paquete, sino además desc ifrarlo.

Los intrusos que empleen el tipo de ataque "Hombre en el medio" entre un servidor y el cliente deben

también tener acceso al menos a una de las llaves privadas para la autentic ac ión de ses iones. Puesto

que solamente emplean varias capas de autentic ac ión y encriptac ión, las VPN son una forma efectiva

y segura de conectar nodos remotos múltiples para actuar como una única Intranet.

http://www.macsecurity.org/resources/xinetd/tutorial.shtml

698

Redes privadas virtuales (VPNs)

43.6.2. VPNs y Red Hat Enterprise Linux

Red Hat Enterprise Linux proporc iona varias opc iones para implementar una solución de

software para conectarse de forma segura a sus WAN. El Internet Protocol Security o IPsec es la

implementac ión VPN soportada por Red Hat Enterprise Linux que resuelve de forma completa las

necesidades de utilización de las organizac iones con suc ursales o con usuarios remotos.

43.6.3. IPsec

Red Hat Enterprise Linux es compatible con IPsec para la conexión entre hos ts y redes remotos

utilizando un túnel seguro en un transportador de red común tal como la Internet. IPsec se puede

implementar usando una conexión host-a-hos t (una computadora a la otra) o de red-a-red (una LAN/

WAN a la otra).

La implementac ión IPsec en Red Hat Enterprise Linux utiliza el Intercambio de llaves en Internet

(IKE), el cual es un protocolo implementado por el Internet Engineering Task Force (IETF), a ser

usado para la autentic ac ión mutua y asoc iac iones seguras entre sistemas c onectándose.

43.6.4. Creando una conexión IPsec

An IPsec connec tion is split into two logical phases. In phase 1, an IPsec node initializes the

connection with the remote node or network. The remote node or network chec ks the requesting

node's credentials and both parties negotiate the authentic ation method for the connection.

En s istemas Red Hat Enterprise Linux, una conexión IPsec utiliza el método de llave pre-compartida

de autentic ac ión de nodo IPsec. En una conexión IPsec de llaves prec ompartidas, ambos hos ts

deben utilizar la misma llave para pasar a la fase dos de la conexión IPsec.

Es en la fase 2 de la conexión IPsec donde se crea una asociación de seguridad (SA) entre nodos

IPsec. Esta fase establec e una base de datos SA con información de configurac ión, tal como el

método de encriptac ión, parámetros de intercambio de llaves secretas y más. Esta fase maneja

realmente la conexión IPsec entre nodos remotos y redes.

La implementac ión de Red Hat Enterprise Linux de IPsec utiliza IKE para compartir las llaves entre

hos ts a través de la Internet. El demonio de manejo de llaves racoon se encarga de la distr ibución

e interc ambio de llaves IKE. Consulte las páginas man de racoon para obtener mayor información

sobre este demonio.

43.6.5. Instalación de IPsec

La implementac ión de IPsec requiere que esté instalado el paquete RPM ipsec-tools en todos los

hos ts IPsec (si se está utilizando una configurac ión de host-a-host) o enrutadores (si se está usando

una configuración de red-a-red). El paquete RPM contiene las bibliotec as esenc iales, los demonios y

los archivos de configuración para ayudar en la configurac ión de una conexión IPsec, inc luyendo:

• /sbin/setkey — manipula la administrac ión de llaves y los atr ibutos de seguridad de IPsec en

el kernel. Este ejecutable es controlado por el demonio de manejo de llaves racoon. Para más

información sobre setkey, c onsulte la página man setkey(8).

• /usr/sbin/racoon — the IKE key management daemon, used to manage and control security

assoc iations and key sharing betw een IPsec-connected systems.

• /etc/racoon/racoon.conf — El archivo de configuración del demonio racoon utilizado para

configurar los diferentes aspec tos de la conexión IPsec, inc luyendo los métodos de autentic ac ión

699

Configurac ión IPsec de host-a-host

y algoritmos de encriptac ión usados en la conexión. Para ver un listado completo de las directivas

disponibles, consulte la página man de racoon.conf(5).

Para configurar IPsec en Red Hat Enterprise Linux, usted puede utilizar la Herramienta de

administración de red o editar manualmente los archivos de configurac ión de red y IPsec.

• To connec t two network-c onnected hosts via IPsec, refer to Sección 43.6.6, “Configuración IPsec de

host-a-host ”.

• To connec t one LAN /W AN to another via IPsec, refer to Sección 43.6.7, “Configuración de IPsec de

red-a-red”.

43.6.6. Config uración IPsec de host-a-host

IPsec se puede configurar para conec tar un escritorio o estac ión de trabajo a otro a través de una

conexión host-a-host. Este tipo de conexión utiliza la red a la cual están conectados los hosts para

crear un túnel seguro entre ellos. Los requerimientos de una conexión host-a-host son mínimos, como

lo es la configuración de IPsec en cada host. Los hos ts solamente nec es itan una conexión dedic ada

al transportador de red (tal como la Internet) y Red Hat Enterprise Linux para crear la conexión IPsec.

43.6.6.1. Configuración host-a-host

Una conexión IPsec hos t-a-host en una conexión encriptada entre dos sis temas que ejec utan IPsec

con la misma llave de autentic ac ión. Con la conexión IPsec activa, todo el tráfico de red entre los dos

hosts es encriptada.

Para configurar una conexión IPsec, utilice los siguientes pasos para cada hos t:

Nota

Debe ejec utar los siguientes pasos en la máquina que esta configurando. Evite

configurar y establec er conexiones IPsec remotamente.

1. En un intérprete de comandos escriba system-config-network para iniciar la Herramienta de

administración de redes.

2. En la pestaña IPse c, haga clic en Nue vo para iniciar el ayudante de configuración.

3. Haga clic en Adelante para iniciar la configurac ión de una conexión IPsec de host-a-host:

4. Introduzc a un nombre único para la conexión, por ejemplo, ipsec0. Si se requiere, selecc ione

la casilla de verificación para automáticamente activar la conexión cuando el computador inicie.

Haga clic en Adelante para continuar.

5. Selecc ione Encriptación de host a host como tipo de conexión y haga clic en Adelante.

6. Selecc ione el tipo de encriptac ión a usar: manual o automática.

Si selecc iona encriptac ión manual, una llave de encriptac ión debe ser proporc ionada

pos teriormente. Si selecc iona encriptac ión automátic a, el demonio racoon administra la llave

de encriptac ión. El paquete ipsec-tools debe ser instalado si desea utilizar encriptac ión

automátic a.


700


7. Introduzc a la dirección IP del host remoto.

Para determinar la dirección IP del host remoto, utilice el s iguiente comando en el host remoto:

[root@myServer ~] # /sbin/ifconfig <d evice >

where <device> is the Ethernet device that you want to use for the VPN connection.

Si sólo una tarjeta Ethernet existe en su s istema, el nombre de dispositivo es generalmente eth0.

El s iguiente ejemplo muestra la información relevante de este c omando (tenga en c uenta que es

un ejemplo de la salida únicamente):

eth0 Link encap:Ethernet HWaddr 00:0C:6E:E8:98:1D

inet a ddr:172.16.44.192 Bcast:172.16.45.255 Mask:255.255.254.0

La dirección IP es el número que va después de inet addr:

Nota

Para las conexiones hos t-a-host, ambos host deben tener una dirección pública y

enrutable. Alternativamente, ambos hosts pueden tener una dirección privada no

enrutable (por ejemplo, de los rangos 10.x.x.x o 192.168.x.x) si ambos están en

la misma LAN.

If the hosts are on different LANs, or one has a public address while the other has

a private address, refer to Sección 43.6.7, “Configuración de IPsec de red-a-red”.


8. If manual encryption was selec ted in step 6, specify the encryption key to use, or click Generate to

create one.

a. Espec if ique una llave de autenticac ión o haga clic en Generar para generar una llave. Puede

ser cualquier combinac ión de números y letras.

b. Haga clic en Adelante para continuar.

9. Verifique la información en la página IPse c — Resume n y haga clic en Aplicar.

10. Click File > Save to save the configuration.

Podría tener que reiniciar la red para que los cambios surtan efecto. Para reiniciar la red utilice el

siguiente comando:

[root@myServer ~]# service network restart

11. Selecc ione la conexión IPsec desde la lista y haga clic en Activar.

12. Repeat the entire procedure for the other host. It is essential that the same keys from step 8 be

used on the other hosts. Otherw ise, IPsec will not work.

mailto:root@myServer


701


After configuring the IPsec connection, it appears in the IPsec list as shown in Figura 43.10, “IPsec

Connection”.

Figura 43.10. IPsec Connec tion

Los siguientes archivos son creados cuando la c onexión IPsec es configurada:

• /etc/sysconfig/network-scripts/ifcfg-<nicknam e>

• /etc/sysconfig/network-scripts/keys-<nicknam e>

• /etc/racoon/<remote-ip>.conf

• /etc/racoon/psk.txt

Si se selecc iona la encriptac ión automátic a, el archivo /etc/racoon/racoon.conf es también

creado.

When the interfac e is up, /etc/racoon/racoon.conf is modified to include <remote-ip>.conf.

702


43.6.6.2. Configuración manual de IPsec de host-a-host

El primer paso en la creac ión de una conexión es reunir la información del sistema y de la red de cada

estac ión de trabajo. Para una c onexión host-a-host, nec es ita la información siguiente:

• La dirección IP para ambos hosts

• Un nombre único, por ejemplo, ipsec1. Éste es utilizado para identificar la conexión IPsec y para

distinguirla de otros dispos itivos y conexiones.

• Una llave encriptada fija o una generada automátic amente por racoon

• Una llave de autentic ac ión pre-c ompartida que se utiliza para iniciar la conexión e intercambiar las

llaves de encriptac ión durante la ses ión

Por ejemplo, suponga que la Estac ión A y la Es tac ión B desean conectarse a través de un túnel

IPsec. Ellas desean conectarse usando una llave pre-c ompartida con el valor de Ke y_Value 01 y los

usuarios ac uerdan dejar que racoon automátic amente genere y c omparta una llave de autentic ac ión

entre cada host. Ambos usuarios de los hos ts dec iden nombrar sus conexiones como ipsec1.

Nota

Usted debería esc oger un PSK que utilice mayúsc ulas y minúsc ulas, números y

caracteres de puntuac ión. Un PSK que sea fácil de adivinar constituye un riesgo de

seguridad.

No es necesario utilizar el mismo nombre de conexión para cada host. Debería

esc oger un nombre que es s ignif icativo y conveniente para su instalac ión.

El s iguiente es el archivo de configurac ión IPsec para una conexión IPsec de host-a-host para

la Estac ión A con la Estac ión B. El nombre único para identificar la conexión en este ejemplo es

ipsec1, por lo cual el archivo resultante es llamado /etc/sysconfig/network-scripts/

ifcfg-ipsec1

DS T =X.X.X.X

TYPE=IPSEC

ONBOOT=no

I KE_ M ET HO D= P S K

Para la Estac ión A, X.X.X.X es la dirección IP de la Estac ión B. Para la Estac ión B, X.X.X.X

es la dirección IP de la Es tac ión A. Esta conexión no está configurada para iniciarse durante

el inicio del s is tema (ONBOOT=no) y utiliza el método de autentic ac ión de llave pre-compartida

(IKE_METHOD=PSK).

El s iguiente es el c ontenido del archivo de llave pre-compartida ( llamado /etc/sysconfig/

network-scripts/keys-ipsec1) que ambas es tac iones de trabajo nec es itan para autentic arse

mutuamente. Los contenidos de este archivo deberían ser idéntic os en ambas es tac iones de trabajo y

solamente el usuario root debería ser capaz de leer o escribir en el mismo.

IKE_P SK=Key _ Value01

703


Importante

Para c ambiar el archivo keys-ipsec1 para que solamente el usuar io root pueda

leerlo o modificarlo, ejec ute el comando s iguiente después de crear el archivo:

[root@myServer ~] # chmod 600 /etc /sysc onfig/ne twork-sc ripts /ke ys- ipse c 1

Para c ambiar la llave de autentic ac ión en cualquier momento, modifique el archivo keys-ipsec1 en

ambas estac iones de trabajo. Ambas llaves deben ser idénticas para una conectividad apropiada.

El s iguiente ejemplo muestra la configurac ión específ ica para la fase 1 de la conexión al host remoto.

El archivo es llamado X.X.X.X.conf (reemplac e X.X .X .X con la dirección IP del enrutador IPsec

remoto). Observe que este archivo es generado automátic amente una vez que el túnel IPsec es

activado y no se debería modificar directamente.

remote X.X.X.X

{

ex ch an ge_ m o de aggress ive, main;

my_ide ntif ier a ddress;

proposal {

encryption_a lgorithm 3des ;

hash_algor ithm sha 1;

authentication_method pre_shared_ke y;

dh_group 2 ;

}

}

El archivo de configurac ión predeterminado para la fase 1 creado cuando se inicializa una conexión

IPsec c ontiene las siguientes dec larac iones utilizadas por la implementac ión Red Hat Enterprise Linux

de IPsec :

remote X.X.X .X

Espec if ic a que las estrofas subsec uentes de este archivo de configurac ión sólo se aplican al nodo

remoto identificado por la dirección IP X.X.X.X

exc hange_mode aggress ive

La configurac ión predeterminada para IPsec en Red Hat Enterprise Linux utiliza un método

de autentic ac ión agres ivo, que reduc e la sobrec arga de la c onexión a la vez que permite la

configurac ión de muc has conexiones IPsec con múltiples hosts.

my_identif ier address

Define el método de autentic ac ión a utilizar cuando se autentif ican nodos. Red Hat Enterprise

Linux utiliza direcc iones IP para identificar a los nodos.

encryption_algorithm 3des

Define el cifrado de encriptac ión utilizado durante la autentic ac ión. Por defec to, se utiliza Triple

Data Encryption Standard (3DES).

hash_algorithm sha1;

Espec if ic a el algoritmo hash utilizado durante la negoc iac ión de la fase 1 entre nodos. Por

defec to, se utiliza el Sec ure Hash Algorithm versión 1.


704


authentic ation_method pre_shared_key

Define el método de autentic ac ión utilizado durante la negoc iac ión de nodos. Por defecto, Red

Hat Enterprise Linux utiliza llaves pre-c ompartidas para la autenticac ión.

dh_group 2

Espec if ic a el número de grupo Diffie-Hellman para establec er llaves de sesión generadas

dinámicamente. Por defec to, se utiliza modp1024 (grupo 2).

43.6.6.2.1. El archivo de configuración de Racoon

The /etc/racoon/racoon.conf f iles should be identical on all IPsec nodes except for the

include "/etc/racoon/X.X.X.X.conf" statement. This statement (and the file it referenc es)

is generated when the IPsec tunnel is activated. For Workstation A, the X.X.X.X in the include

statement is Workstation B's IP address. The oppos ite is true of Workstation B. The following shows a

typical racoon.conf f ile when the IPsec connec tion is activated.

# Raco on IKE daem on conf iguration file.

# See 'ma n rac oon.c onf' for a description of the format and entries.

path include "/etc/racoon";

path pre_shared_key "/etc/racoon/psk.txt";

path certificate "/etc/racoon/certs";

sainfo anonymous

{

pfs_group 2;

life time time 1 hour ;

encryption_algor ithm 3des, blowfish 448, rijndael ;

authe ntica tion_algorithm hmac_sha1, hmac_ m d5 ;

compression_algorithm deflate ;

}

include " /etc/racoon/X.X.X.X.c onf";

Este archivo racoon.conf predeterminado incluye rutas definidas para la configurac ión de IPsec,

archivos de llaves pre-c ompartidas y certif icados. Los campos en sainfo anonymous describen

la fase 2 SA entre nodos IPsec — la naturaleza de la conexión IPsec (inc luyendo los algoritmos de

encriptac ión soportados) y el método de intercambio de llaves. La lista siguiente define los campos de

la fase 2.

sainfo anonymous

Denota que SA puede inic ializarse de forma anónima con cualquier par siempre que las

credenc iales IPsec coinc idan.

pfs_group 2

Define el protocolo de intercambio de llaves Diffie-Hellman, el cual determina el método en el cual

los nodos IPsec establec en una ses ión temporal mutua para la segunda fase de conectividad de

IPsec. Por defecto, la implementac ión de Red Hat Enterprise Linux de IPsec utiliza el grupo 2 (o

modp1024) de los grupos de intercambio de llaves criptográfic as de Diffie-Hellman. El grupo 2

utiliza un exponente modular de 1024 bits que evita que los atac antes desc ifren transmis iones

IPsec previas aún si una llave privada está c omprometida.

lifetime time 1 hour

Este parámetro espec if ic a el ciclo de vida de un SA y se puede cuantificar por veces o por bytes

de datos. La implementac ión predeterminada de Red Hat Enterprise Linux de IPsec espec if ica un

tiempo de vida de una hora.

705

Configuración de IPsec de red-a-red

encryption_algorithm 3des, blowfish 448, rijndael

Espec if ic a los códigos de encriptac ión soportados para la fase 2. Red Hat Enterprise Linux

soporta 3DES, 448-bit Blowfish y Rijndael (el código utilizado en el Advanced Encryption Standard

o AES).

authentic ation_algorithm hmac _sha1, hmac _md5

Lista los algoritmos hash soportados para la autenticac ión. Los modos soportados son los

códigos de autentic ac ión de mensajes en hash (HMAC) sha1 y md5.

compress ion_algorithm deflate

Define el algoritmo de compres ión Deflate para el soporte de IP Payload Compress ion (IPCOMP),

lo que permite transmis iones potenc iales más rápidas de datagramas IP sobre c onexiones más

lentas.

Para iniciar la conexión, utilice el s iguiente c omando en cada hos t:

[root@myServer ~]# /sbin/ifup <n ickn am e>

where <nickname> is the name you spec if ied for the IPsec connection.

Para verificar la conexión IPsec, ejec ute la utilidad tcpdump para ver los paquetes de red que están

siendo transferidos entre los hosts y verificar que están encriptados con IPsec. El paquete debería

incluir una cabecera AH y se deberían mostrar como paquetes ESP. ESP significa que están

encriptados. Por ejemplo:

[root@myServer ~]# tcpdump -n -i eth0 host <targetSystem>

IP 172.16.45.107 > 172.16.44.192: AH(spi=0x0954ccb6,seq=0xbb): ESP(spi=0x0c9f2164,seq=0xbb)

43.6.7. Configuración de IPsec de red-a-red

IPsec can also be configured to connec t an entire network (such as a LAN or WAN) to a remote

network using a network-to-network connection. A network-to-network connection requires the

setup of IPsec routers on each side of the connecting networks to transparently proc ess and route

information from one node on a LAN to a node on a remote LAN. Figura 43.11, “A network-to-network

IPsec tunneled connection” shows a network-to-network IPsec tunneled connection.

Figura 43.11. A network-to-network IPsec tunneled c onnection

El diagrama muestra dos LAN separadas por la Internet. Estas LAN utilizan enrutadores IPsec para

autentic ar e iniciar una conexión usando un túnel seguro a través de la Internet. Los paquetes que



706


son interceptados en tránsito requerirán un desc ifrado de fuerza bruta para poder desc ifrar el código

protegiendo los paquetes entre las LAN. El proc eso de comunic ac ión desde un nodo en el intervalo

IP 192.168.1.0/24 al otro en 192.168.2.0/24 es completamente transparente a los nodos pues to que

el proc esamiento, encriptac ión/desc ifrado y el enrutamiento de los paquetes IPsec es manejado

completamente por el enrutador IPsec.

La información nec esaria para la conexión red-a-red inc luye:

• Las direcc iones IP acc es ibles externamente de los enrutadores IPsec dedic ados

• Los intervalos de direcc iones de red de las LAN/WAN servidas por los enrutadores IPsec (tales

como 192.168.0.0/24 o 10.0.1.0/24)

• Las direcc iones IP de los dispos itivos de puertas de enlac e que enrutan los datos desde un nodo de

la red a la Internet:

• Un nombre único, por ejemplo, ipsec1. Éste es utilizado para identificar la conexión IPsec y para

distinguirla de otros dispos itivos y conexiones.

• Una llave encriptada fija o una generada automátic amente por racoon

• Una llave de autentic ac ión pre-c ompartida que se utiliza para iniciar la conexión e intercambiar las

llaves de encriptac ión durante la ses ión

43.6.7.1. Conexión (VPN) de red-a-red

Una conexión IPsec de red-a-red utiliza dos routers IPsec, uno para cada red, por los cuales el tráf ico

de red para la subred privada es dir igido.

For example, as shown in Figura 43.12, “Network-to-Network IPsec”, if the 192.168.1.0/24 private

network sends network traffic to the 192.168.2.0/24 private network, the pac kets go through gatew ay0,

to ipsec0, through the Internet, to ipsec 1, to gatew ay1, and to the 192.168.2.0/24 subnet.

Los enrutadores IPsec requieren direcc iones IP públic amente acc es ibles y un segundo dispositivo de

Ethernet conectado a sus respectivas redes privadas. El tráfico sólo pasa a través de enrutador IPsec

si es dir igido a otro enrutador IPsec con el cual tiene una conexión encriptada.

Figura 43.12. Network-to-Network IPsec

Entre las opc iones de configuración de red alternativas se enc uentra un cortafuego entre cada

enrutador IP y la Internet y un cortafuegos de intranet entre cada enrutador IPsec y la puerta de

enlac e de la subred. El enrutador IPsec y la puerta de enlac e para la subred pueden ser un sistema

707


con dos dispos itivos Ethernet: uno con una dirección IP pública que ac túa como enrutador IPsec y

otro con una dirección IP privada que actúa como puerta de enlac e para la subred privada. Cada

enrutador IPsec puede utilizar la puerta de enlac e para su red privada o una puerta de enlac e públic a

para enviar los paquetes al otro enrutador IPsec.

Utilice el siguiente proc edimiento para configurar una conexión IPsec de red-a-red:

1. En un intérprete de comandos escriba system-config-network para iniciar la Herramienta de

administración de redes.

2. En la pestaña IPse c, haga clic en Nue vo para iniciar el ayudante de configuración.

3. Haga clic en Adelante para iniciar la configurac ión de una conexión IPsec de red-a-red.

4. Introduzc a un sobrenombre único para la conexión, por ejemplo, ipsec0. Si se requiere,

selecc ione la casilla de verificación para activar automátic amente la conexión cuando el

computador inicie. Haga clic en Adelante para continuar.

5. Selecc ione Encriptación de red a red (VPN) como el tipo de conexión y haga clic en Adelante.

6. Selecc ione el tipo de encriptac ión a usar: manual o automática.

Si selecc iona encriptac ión manual, una llave de encriptac ión debe ser proporc ionada

pos teriormente. Si selecc iona encriptac ión automátic a, el demonio racoon administra la llave

de encriptac ión. El paquete ipsec-tools debe ser instalado si desea utilizar encriptac ión

automátic a.


7. En la página Red Local introduzca la s iguiente información:

• Dirección de red local — La dirección IP del dispositivo en el enrutador IPsec conectado a la

red privada.

• Máscara de subre d local — La máscara de subred de la dirección IP de la red local.

• Puerta de enlace local — La puerta de enlac e para la puerta de enlac e privada.


708


Figura 43.13. Local Network Information

8. En la página Red remota, introduzca la s iguiente información:

• Dirección IP remota — La dirección IP públic amente acc es ibles del enrutador IPsec para

la otra red privada. En nuestro ejemplo, para ipsec 0, introduzc a la dirección IP públicamente

acc es ible de ipsec11 y vic eversa.

• Dirección de red remota — La dirección de red de la subred privada detrás del otro enrutador

IPsec. En nuestro ejemplo, introduzca 192.168.1.0 si se está c onfigurando ipsec1, e

introduzc a 192.168.2.0 si configura ipsec 0.

• Máscara de subre d remota — La máscara de subred de la dirección IP remota.

• Puerta de enlace remota — La dirección IP de la puerta de enlac e para la dirección de red

remota.

• If manual encryption was selec ted in step 6, specify the encryption key to use or click Gene rate

to create one.

Espec if ique una llave de autenticac ión o haga clic en Generar para generar una. Esta llave

puede ser una combinac ión de números y letras.


709


Figura 43.14. Remote Network Information

9. Verifique la información en la página IPse c — Resume n y haga clic en Aplicar.

10. Select File > Save to save the configuration.

11. Selecc ione la conexión IPsec desde la lista y haga clic en Activar para activar la conexión.

12. Activar reenvío IP

a. Modifique /etc/sysctl.conf y configure net.ipv4.ip_forward a 1.

b. Utilice el siguiente c omando para activar el cambio:

[root@myServer ~]# /sbin/sysctl -p /etc/sysctl.conf

El script de red para activar la conexión IPsec crea automátic amente los enrutadores de red para

enviar los paquetes a través del enrutador IPsec s i es necesario.

43.6.7.2. Configuración manual de IPsec de red-a-red

Suponga que LAN A (lana.example.com) y LAN B (lanb.example.com) desean conectarse entre ellas

a través de un túnel IPsec. La dirección de red para la LAN A están en el intervalo 192.168.1.0/24,

mientras que LAN B utiliza el intervalo 192.168.2.0/24. La dirección IP de la puerta de enlac e es

192.168.1.254 para LAN A y 192.168.2.254 para LAN B. Los enrutadores IPsec están separados

de cada puerta de enlac e de las LAN y utilizan dos dispos itivos de redes : eth0 está asignado a una

dirección IP estátic a acces ible externamente que tiene acceso a la Internet, mientras que eth1 ac túa

como un punto de enrutamiento para proc esar y transmitir paquetes LAN desde un nodo de la red a

los nodos de redes remotos.


710


La conexión IPsec entre cada red utiliza una llave pre-compartida con el valor de r3dh4tl1nux y

los adminis tradores de A y B ac uerdan dejar que racoon genere automátic amente y c omparta una

llave de autenticac ión entre cada enrutador IPsec. El administrador de la LAN A dec ide nombrar

la conexión IPsec ipsec0, mientras que el adminis trador de la LAN B llama a su conexión IPsec

ipsec1.

El s iguiente ejemplo muestra el contenido de un archivo ifcfg para una conexión IPsec de red-a-red

para la LAN A. El nombre único para identificar la conexión en este ejemplo es ipsec0, por lo que el

archivo resultante es llamado /etc/sysconfig/network-scripts/ifcfg-ipsec0.

TYPE=IPSEC

ONBOOT=yes

IKE_METHOD=PSK

SRC GW =19 2.1 68.1.2 54

DST GW =19 2.1 68.2.2 54

SR C NET =1 9 2.16 8.1.0 /2 4

D ST NET =1 9 2.16 8.2.0 /2 4

DS T =X.X.X.X

La siguiente lista desc ribe el contenido de este ejemplo :

TYPE=IPSEC

Espec if ic a el tipo de conexión.

ONBOOT=yes

Espec if ic a que la conexión debe ser iniciada durante el periodo de arranque.

IKE_METHOD=PSK

Espec if ic a que la conexión utiliza llaves el método de autentic ac ión de llaves pre-c ompartidas.

SRCGW=192.168.1.254

La dirección IP de la puerta de enlac e fuente. Para LAN A, la puerta de enlac e de LAN A, y para

LAN B, la puerta de enlac e LAN B.

DSTGW=192.168.2.254

La dirección IP de la puerta de enlac e del des tino. Para LAN A, la puerta de enlac e LAN B, para

LAN B, la puerta de enlac e LAN A.

SRCNET=192.168.1.0/24

Espec if ic a la red fuente para la conexión IPsec. En este ejemplo es el rango de red para LAN A.

DSTNET=192.168.2.0/24

Espec if ic a la red de destino para la conexión IPsec. En este ejemplo es el rango de red para LAN

B.

DST=X.X.X.X

Las direcc iones IP acc es ibles externamente de LAN B.

El s iguiente ejemplo muestra el contenido de un archivo de llave pre-c ompartida llamado /etc/

sysconfig/network-scripts/keys-ipsecX (donde X es 0 para la LAN A y 1 para la LAN B)

que ambas redes utilizan para autentic arse mutuamente. Los contenidos de este archivo deberían ser

idéntic os y solamente el usuario root debería tener acceso a leer o escribir en este arc hivo.

711


IKE_P SK =r3 dh 4tl1 n ux

Importante Para c ambiar el archivo keys-ipsecX para que solamente el usuario root pueda

leerlo o modificarlo, ejec ute el comando s iguiente después de crear el archivo:

chmod 600 /etc /sysc onfig/ne twork-sc ripts /ke ys- ipse c 1

Para c ambiar la llave de autentic ac ión en algún momento, modifique el archivo keys-ipsecX en

ambos enrutadores IPsec. Ambas llaves deber ser idénticas para obtener una conectividad apropiada.

El s iguiente ejemplo muestra el contenido del archivo de configuración /etc/racoon/

racoon.conf para la conexión IPsec. Observe que la línea include al final del archivo es generada

automátic amente y solamente aparec e si el tunel IPsec se está ejecutando.

# Raco on IKE daem on conf iguration file.

# See 'ma n rac oon.c onf' for a description of the format and entries.

path include "/etc/racoon";

path pre_shared_key "/etc/racoon/psk.txt";

path certificate "/etc/racoon/certs";

sainfo anonymous

{

pfs_group 2;

life time time 1 hour ;

encryption_algor ithm 3des, blowfish 448, rijndael ;

authe ntica tion_algorithm hmac_sha1, hmac_ m d5 ;

compression_algorithm deflate ;

}

inc lude "/etc/racoon/X.X.X.X.c onf"

A continuac ión se muestra la configurac ión específ ic a para la conexión a la red remota. El archivo es

llamado X.X.X.X.conf (reemplac e X.X .X .X con la dirección IP del enrutador IPsec remoto).

Observe que este archivo es generado automátic amente una vez que el túnel IPsec es activado y no

se debería modificar directamente.

remote X.X.X.X

{

ex ch an ge_ m o de aggress ive, main;

my_ide ntif ier a ddress;

proposal { encryption_a lgorithm 3des ;

hash_algor ithm sha 1;

authentication_method pre_shared_ke y;

dh_group 2 ;

}

}

Antes de iniciar la c onexión IPsec, se debería activar el reenvío IP en el kernel. Para activar el reenvío

IP:

1. Modifique /etc/sysctl.conf y configure net.ipv4.ip_forward a 1.

712


2. Utilice el siguiente c omando para activar el cambio:

[root@myServer ~] # sysctl -p /etc/sysctl.conf

Para iniciar la conexión IPsec, ejec ute el comando s iguiente en cada enrutador:

[root@myServer ~] # /sbin/ifup ipsec 0

Las conexiones son activadas y ambas LAN A y LAN B son capaces de comunic arse entre ellas. Los

enrutadores se crean automátic amente a través del script de inicialización que se llama ejec utando

ifup en la c onexión IPsec. Para mostrar una lista de rutas para la red, ejec ute el c omando s iguiente:

[root@myServer ~] # /sbin/ip route list

Para evaluar la conexión IPsec, ejec ute la utilidad tcpdump en el dispositivo enrutable externamente

(eth0 en este ejemplo) para así ver los paquetes de red que están s iendo transmitidos entre los

hos ts (o redes) y verificar que están encriptados a través de IPsec. Por ejemplo, para verificar la

conectividad IPsec de la LAN A, escriba lo s iguiente:

[root@myServer ~] # tcpdump -n -i eth0 host lana.example.com

El paquete debería incluir una cabecera AH y se deberían mostrar como paquetes ESP. ESP significa

que están encriptados. Por ejemplo (las barras oblíc uas denotan la continuac ión de una línea):

12:24:26.155529 lanb.example.com > lana.example.com: AH(spi=0x021c9834,seq=0x358): \

lanb.example.com > lana.example.com: ESP(spi=0x00c887ad,seq=0x358) (DF) \

(ipip-proto-4)

43.6.8. Iniciando y deteniendo conexiones IPsec

Si la conexión IPsec no fue configurada para activar durante el inicio, usted puede c ontrolarla desde

la línea de comandos.

Para iniciar la conexión, utilice el s iguiente c omando para cada host en una conexión IPsec de host-a-

host o cada enrutador IPsec para una conexión IPsec de red-a-red:

[root@myServer ~] # /sbin/ifup <n ickn am e>

where <nick name> is the nickname configured earlier, such as ipsec0.

Para detener la conexión utilice el s iguiente c omando:

[root@myServer ~] # /sbin/ifdown <nick name >







713

IPTables

43.7. IPTables

Red Hat Enterprise Linux c ontiene herramientas avanzadas para el filtrado de paquetes de red —

el proc eso de controlar los paquetes de red al entrar, mientras se mueven y c uando salen de la red

dentro del kernel. Los kernels anteriores al 2.4 dependían en ipchains para el filtrado de paquetes y

usaban listas de reglas aplic adas a los paquetes en cada paso del proc eso de filtrado. La introducción

de kernel 2.4 trajo cons igo iptables (también llamado netfilter); aunque es similar a ipchains,

expande enormemente el ámbito y el control disponible para el filtrado de paquetes de red.

Este capítulo se centra en las noc ivas bás ic as del filtrado de paquetes, define las diferenc ias entre

ipchains e iptables, explica las diferentes opc iones disponibles con comandos iptables y

mues tra cómo se pueden preservar las reglas de filtrado durante reinicios del s is tema.

Refer to Sección 43.7.7, “Recursos adicionales” for instructions on how to construct iptables rules

and setting up a firewall based on these rules.

Aviso

El mec anismo predeterminado de cortafuegos en la versión 2.4 y posterior del kernel

es iptables, pero éste no se puede usar si ya se está ejec utando ipchains. Si

ipchains está presente durante el arranque, el kernel emitirá un error y no podrá

arranc ar iptables.

Estos errores no afec tan la func ionalidad del c omando ipchains.

43.7.1. Filtrado de paquetes

El kernel de Linux utiliza Netfilter para filtrar paquetes, permitiendo aceptar algunos de ellos en

el s istema mientras que interc epta y detiene otros. Esta utilidad es interna en el kernel de Linux e

incorpora las siguientes tres tablas o listas de reglas:

• filter — La tabla por defecto para el manejo de paquetes de red.

• nat — Usada para alterar paquetes que crean una nueva c onexión y utilizada para la Traducción

de direcciones de red (Network Address Translation, NAT).

• mangle — Usada por tipos específ ic os de alterac ión de paquetes.

Cada una de estas tablas tiene un grupo de cadenas inc orporadas que c orresponden a las acc iones

llevadas a cabo en el paquete por netfilter.

Las cadenas internas para la tabla filtro son las siguientes :

• INPUT — Aplica a los paquetes rec ibidos a través de una interfaz de red.

• OUTPUT — Esta cadena sirve para paquetes enviados por medio de la misma interfaz de red que

recibió los paquetes.

• FORWARD — Esta cadena sirve para paquetes rec ibidos en una interfaz de red y enviados en otra.

Las cadenas internas para la tabla nat son las siguientes :

• PREROUTING — Altera los paquetes de red cuando estos llegan.

714

IPTables

• POSTROUTING — Esta cadena altera paquetes antes de que sean enviados por medio de una

interfaz de red.

• POSTROUTING — Altera los paquetes de red cuando estos son enviados.

PREROUTING — Esta cadena altera paquetes rec ibidos por medio de una interfaz de red cuando

llegan.

• OUTPUT — Esta cadena altera paquetes generados loc almente antes de que sean dirigidos por

medio de una interfaz de red.

• POSTROUTING — Esta cadena altera paquetes antes de que sean enviados por medio de una

interfaz de red.

• Las cadenas internas para la tabla mangle son las siguientes :

• PREROUTING — Esta cadena altera paquetes rec ibidos por medio de una interfaz de red antes de

que sean dir igidos.

• POSTROUTING — Altera los paquetes de red cuando estos son enviados.

Cada paquete de red recibido o enviado desde un s istema Linux está sujeto a al menos una tabla. Sin

embargo, un paquete puede estar sometido a múltiples reglas dentro de cada tabla antes de emerger

al final de la cadena. La estructura y propós ito de estas reglas puede variar, pero normalmente

busc an identif icar un paquete que viene de o se dirige hacia una direccción IP en particular, o un

conjunto de direcc iones, c uando utiliza un determinado protocolo y servicio de red.

Nota

Por defecto. las reglas del cortafuegos son guardadas en los archivos /etc/

sysconfig/iptables o /etc/sysconfig/ip6tables .

El servicio iptables es iniciado antes que el resto de servic ios relac ionados con

DNS cuando un s istema Linux es iniciado. Esto significa que las reglas del

cortafuegos solo pueden ser referenc iadas a través de las direcc iones IP (por

ejemplo 192.168.0.1). Los nombres de dominios (por ejemplo, host.example.c om) en

dic has reglas produc en errores.

Regardless of their des tination, when pac kets match a particular rule in one of the tables, a target

or action is applied to them. If the rule spec if ies an ACCEPT target for a matc hing packet, the packet

skips the rest of the rule chec ks and is allowed to continue to its des tination. If a rule spec if ies a DROP

target, that pac ket is refused access to the system and nothing is sent back to the host that sent the

packet. If a rule spec if ies a QUEUE target, the packet is passed to user-spac e. If a rule spec if ies the

optional REJECT target, the packet is dropped, but an error packet is sent to the packet's originator.

Cada cadena tiene una política por defecto de ACCEPT, DROP, REJECT, o QUEUE. Si ninguna de estas

reglas en la cadena se aplican al paquete, entonc es el paquete es tratado de ac uerdo a la política por

defecto.

El c omando iptables configura estas tablas, así como también configura nuevas tablas si es

nec esario.

715

Diferenc ias entre IPTables y IPChains

43.7.2. Diferencias entre IPTables y IPChains

Tanto ipchains como iptables usan cadenas de reglas que operan dentro del kernel de Linux

para decidir qué hac er con los paquetes que cumplen determinadas reglas. Sin embargo, iptables

proporc iona un método de filtrado de paquetes que puede ser extendido más fácilmente, brindando

al administrador un nivel de control mucho más refinado sin tener que aumentar la complejidad del

sistema entero.

Tenga en cuenta las siguientes diferenc ias entre iptables y ipchains:

Using iptables, each filtered pack et is processed using rules from only one chain rather than

multiple chains.

Por ejemplo, un paquete FORWARD que llega a un sis tema usando ipchains tendrá que pasar

por las cadenas INPUT, FORWARD, y OUTPUT para llegar a su destino. Sin embargo,

iptables sólo envía paquetes a la cadena INPUT si su des tino es el s istema local y tan sólo los

envía a la cadena OUTPUT si el s is tema local es quien genera los paquetes. Por esta razón, es

importante que coloque la regla des ignada para capturar un paquete particular dentro de la regla

que en verdad maneja el paquete.

The DENY target has been changed to DROP.

En ipchains, los paquetes que coinc idan con una regla en una cadena podrían ser dirigidos al

objetivo DENY. Este objetivo debe ser cambiado a DROP bajo iptables.

Order matters when placing options in a rule.

En ipchains, el orden de las opciones de la regla no importa.

El c omando iptables usa una sintaxis más estricta. En comandos iptables, el protocolo

(ICMP, TCP o UDP) debe ser espec if ic ado antes del puerto fuente o destino.

Network interfaces must be associated with the correct chains in firewall rules.

Por ejemplo, las interfaces de entrada (opción -i) sólo pueden ser usadas en cadenas INPUT

o FORWARD. Asimismo, interfac es de salida (opción -o) sólo pueden ser usadas en cadenas

FORWARD o OUTPUT.

En otras palabras, las cadenas INPUT y las interfac es de entrada trabajan juntas; las cadenas

OUTPUT y las interfac es de salida trabajan juntas. Las cadenas FORWARD trabajan tanto con

las interfaces de entrada como con las interfaces de salida.

Las cadenas OUTPUT ya no se utilizan en interfac es de entrada; as imismo los paquetes que van

a las interfac es de salida no ven las cadenas INPUT.

This is not a comprehens ive list of the changes. Refer to Sección 43.7.7, “Recursos adicionales” for

more specific information.

43.7.3. Opciones de comandos para IPTables

Las reglas para el filtrado de paquetes se crean con el comando iptables. Las siguientes

característic as del paquete son con frecuenc ia utilizadas como criterio:

• Tipo de paquete — Dicta qué tipo de paquetes filtra el comando.

• Fuente/Destino del paquete — Espec if ic a cuáles paquetes filtra el c omando basándose en el origen

o destino del paquete.

716

Diferenc ias entre IPTables y IPChains

• Objetivo — Indica qué acción es tomada en paquetes que cumplen los criterios menc ionados

anteriormente.

Refer to Sección 43.7.3.4, “Opciones de coincidencia para IPTables” and Sección 43.7.3.5, “Opciones

del objetivo” for more information about specific options that address these aspects of a packet.

Las opc iones usadas con las reglas iptables dadas deben es tar agrupadas lógic amente,

basándose en el propós ito y en las condic iones de la regla general, para que la regla sea válida. El

resto de esta sección explica las opc iones más usadas para el comando iptables.

43.7.3.1. Estructura de las opciones del comando para IPTables

Muchos comandos iptables tienen la s iguiente estruc tura:

iptables [-t <ta b le-n a m e>] <command> <ch a in -n am e> \

<p a ra m ete r-1 > <o p tio n -1 > \

<parameter-n> <option-n>

<table-name> — Spec if ies which table the rule applies to. If omitted, the filter table is used.

<command> — Spec if ies the action to perform, such as appending or deleting a rule.

<chain-name> — Spec if ies the chain to edit, create, or delete.

<parameter>-<option> pairs — Parameters and assoc iated options that specify how to proc ess a

pac ket that matc hes the rule.

El largo y complejidad de un comando iptables puede cambiar signif ic ativamente según su

propós ito.

Por ejemplo, un comando para remover una regla de una cadena puede ser muy corto:

iptables -D <chain-name> <line-number>

En contraste, un comando que añade una regla que filtra paquetes desde una subnet partic ular

utilizando una variedad de parámetros y opc iones específ ic os puede ser bastante largo. Al construir

comandos iptables, es importante rec ordar que algunos parámetros y opc iones requieren

parámetros y opc iones adic ionales para construir una regla válida. Esto puede producir una reacc ión

en cadena, si el parámetro adicional requiere más parámetros. Has ta que no se satisfagan todos los

parámetros y opc iones, la regla no es válida.

Escriba iptables -h para ver una lista detallada de la estructura del comando iptables.

43.7.3.2. Opciones de comandos

Las opc iones de comandos le dicen a iptables que realice una acción específ ic a. Solo se permite

una opción de comando por cada c omando iptables. Exc epto el comando de ayuda, todos los

comandos se esc riben en mayúsc ulas.

Los comandos de iptables son los siguientes :

• -A — Añade la regla al final de la c adena espec if ic ada. A diferenc ia de la opción -I descrita

a continuac ión, no requiere un entero como argumento. Siempre añade una regla al final de la

cadena espec if ic ada.

717

Opc iones de comandos para IPTables

• -C — Verifica una regla en particular antes de añadir la en la cadena espec if ic ada por el usuario.

Este comando puede ser de ayuda para construir reglas iptables complejas pidiéndole que

introduzc a parámetros y opc iones adic ionales.

• -D <integer> | <rule> — Deletes a rule in a particular chain by number (such as 5 for the fifth

rule in a chain), or by rule specific ation. The rule specif ic ation must exactly match an existing rule.

• -E — Renombra una cadena definida por el usuario. Una cadena definida por el usuario es

cualquier c adena diferente a las cadenas predeterminadas. (Consulte la opción -N, para obtener

mayor información sobre cómo crear cadenas definidas por el usuario.) Este es un cambio

superficial que no afec ta la es truc tura de la tabla.

Nota

Si us ted intenta renombrar una de las cadenas predeterminadas, el s istema

reportará el error Match not found (No se enc ontró una coincidenc ia). No se

pueden renombrar las cadenas predeterminadas.

• -F — Libera la cadena selecc ionada, borrando c ada una de las reglas de la cadena. Si no se

espec if ic a ninguna cadena, es te comando libera cada regla de cada cadena.

• -h — Proporc iona una lista de estructuras de comandos, así como también un resúmen rápido de

parámetros de comandos y opc iones.

• -I [<integer>] — Inserts the rule in the spec if ied chain at a point spec if ied by a user-defined

integer argument. If no argument is spec if ied, the rule is inserted at the top of the chain.

Atención

Como se menc ionó anteriormente, el orden de reglas en una cadena determina

cuáles reglas se deben aplicar a cuáles paquetes. Esto es importante de recordar

cuando se añaden reglas con la opción -A o -I.

Este factor es importante al añadir reglas utilizando -I con un entero. Si us ted

espec if ic a un número exis tente al añadir una regla a una cadena, iptables

añade una nueva regla antes (o después) de la regla existente.

• -L — Lista todas las reglas de la cadena espec if ic ada tras el c omando. Para ver una lista de todas

las reglas en todas las cadenas en la tabla por defecto filter, no espec if ique ninguna cadena

o tabla. De lo contrario, la sintaxis siguiente deberá utilizarse para listar las reglas en una cadena

específ ic a en una tabla en particular:

iptables -L <ch a in -n a m e> -t <ta b le -n a m e>

Additional options for the -L command option, which provide rule numbers and allow more verbose

rule descriptions, are described in Sección 43.7.3.6, “Opciones de listado”.

• -N — Crea una nueva c adena con un nombre espec if ic ado por el usuario. El nombre de la cadena

debe ser único, de lo contrario un mensaje de error será reportado.

718


• -P — Configura la política por defecto para una cadena en particular, de tal forma que, cuando los

paquetes atraviesen la c adena c ompleta sin cumplir ninguna regla, serán enviados a un objetivo en

particular, como puedan ser ACCEPT o DROP.

• -R — Replac es a rule in the specif ied chain. The rule's number must be spec if ied after the chain's

name. The first rule in a chain corresponds to rule number one.

• -X — Borra una cadena espec if ic ada por el usuario. No se permite borrar ninguna de las cadenas

predefinidas.

• -Z — Pone c eros en los contadores de byte y de paquete en todas las cadenas de una tabla en

particular.

43.7.3.3. Opciones de parámetros en IPTables

Una vez que se espec if iquen ciertos comandos iptables, inc luyendo aquellos para añadir, anexar,

eliminar, insertar o reemplazar reglas dentro de una c adena, se requieren parámetros para construir

una regla de filtrado de paquetes.

• -c — Resetea los contadores de una regla en particular. Este parámetro ac epta las opc iones PKTS

y BYTES para espec if ic ar qué contador hay que resetear.

• -d — Configura el nombre de la máquina des tino, dirección IP o red de un paquete que coinc ide

con la regla. Cuando se coincida una red, se soportan los siguientes formatos de direcc iones IP o

máscaras de red:

• N.N.N.N/M .M.M.M — Donde N.N.N.N es el rango de direcc iones IP y M.M.M.M es la máscara

de la red.

• N.N.N.N/M — Donde N.N.N.N es el rango de direcc iones IP y M es la máscara de bit.

• -f — Aplica esta regla sólo a los paquetes fragmentados.

Usando la opción ! después de este parámetro, únic amente se harán coincidir los paquetes no

fragmentados.

Nota

La distinción entre paquetes fragmentados y sin fragmentar es conveniente, s in

importar que los paquetes fragmentados son parte del es tándar del protocolo IP.

Originally des igned to allow IP packets to travel over netw orks with differing frame

sizes, these days fragmentation is more commonly used to generate DoS attacks

using mal-formed pac kets. It's also worth noting that IPv6 disallows fragmentation

entirely.

• -i — Configura la interfaz de red entrante, tal como eth0 o ppp0. Con iptables, es te parámetro

opcional puede ser usado solamente con las cadenas INPUT y FORWARD cuando es usado con la

tabla filter y la cadena PREROUTING con las tablas nat y mangle.

Este parámetro también soporta las s iguientes opc iones espec iales :

• El c arác ter de exc lamac ión ! — Invierte la directriz, es decir, se excluye de esta regla cualquier

interfaz espec if ic ada.

719


• El c aráter de suma + — Un c arac ter tipo comodín utilizado para coincidir todas las interfac es c on

una cadena de caracteres espec if ic ada. Por ejemplo, el parámetro -i eth+ aplic ará esta regla a

cualquier interfaz Ethernet pero excluirá cualquier otra interfaz, tal como, ppp0.

Si el parámetro -i se utiliza sin espec if ic ar ninguna interfaz, todas las interfac es es tarán afec tadas

por la regla.

• -j — Salta al objetivo espec if ic ado cuando un paquete coincide con una regla particular.

Los objetivos estándar son ACCEPT, DROP, QUEUE y RETURN.

Las opc iones extendidas también están disponibles a través de los módulos c argados por defecto

con el RPM de iptables en Red Hat Enterprise Linux. Entre los objetivos válidos de estos

módulos están LO G, M AR K y REJECT, entre otros. Consulte la página man de iptables para más

información sobre esto y otros objetivos.

Esta opción puede ser usada para dirigir un paquete que coincide con una regla particular a una

cadena definida por el usuario que se encuentra fuera de la cadena actual. De esta forma, otras

reglas pueden ser aplic adas al paquete.

Si no espec if ic a ningún objetivo, el paquete pasa la regla sin llevar a cabo ninguna acción. A pesar

de todo, el contador para esta regla se sigue incrementando en uno.

• -o — Configura la interfaz de red de salida para una regla. Esta opción es válida únic amente con

las cadenas OUTPUT y FORWARD en la tabla de filter y la cadena POSTROUTING en las

tablas nat y mangle. Es tos parámetros ac eptan las mismas opc iones que aquellos de la interfaz

de entrada (-i).

• -p <protocol> — Sets the IP protocol affected by the rule. This can be either icmp, tcp, udp, or

all, or it can be a numeric value, representing one of these or a different protocol. You can also use

any protocols listed in the /etc/protocols f ile.

The "all" protocol means the rule applies to every supported protocol. If no protocol is listed with

this rule, it defaults to "all".

• -s — Configura la fuente para un paquete particular usando la misma sintaxis que el parámetro (-

d).

43.7.3.4. Opciones de coincidencia para IPTables

Different network protocols provide spec ialized matc hing options which can be configured to match a

particular packet using that protocol. However, the protocol must first be specif ied in the iptables

command. For example, -p <protocol-name> enables options for the specif ied protocol. Note that

you can also use the protocol ID, instead of the protocol name. Refer to the following examples, each

of which have the same effect:

iptables -A INPUT -p icmp --icmp-type any -j ACCEPT

iptables -A INPUT -p 5813 --icmp-type any -j ACCEPT

La definición de servic ios se proporc iona en el archivo /etc/services. Para facilitar la lectura, se

rec omienda utilizar el nombre del servicio y no el número de puerto.

720


Importante

Asegure el archivo /etc/services para evitar que sea editado sin autorizac ión.

Si este archivo puede ser editado, crac kers pueden utilizarlo para abrir puertos en

su máquina que us ted ha cerrado. Para asegurar es te archivo, escriba el comando

siguiente como root:

[root@myServer ~]# chown root.root /etc/services [ro ot@m y Serve r ~]# ch mo d

0644 /etc/services [root@m y Serve r ~]# chattr +i /etc/services

Esto previene que el archivo sea renombrado, borrado o que se creen enlaces a

éste.

43.7.3.4.1. Protocolo TCP

Estas opc iones de identif icación están disponibles en el protocolo TCP (opción -p tcp):

• --dport — Es tablec e el puerto de destino para el paquete.

Para configurar esta opción utilice el nombre del servicio (tal como www o smtp), un número de

puerto o un rango de números de puertos.

Para espec if ic ar un rango de números de puertos, separe los dos números con dos puntos (:), tal

como -p tcp --dport 3000:3200. El rango más grande aceptable es 0:65535.

Use un carácter de exc lamac ión (!) después de la opción --dport para que los paquetes que no

utilizan el servicio de red o puerto coinc idan.

Para ver los nombres y aliases de los servic ios de red y números de puertos que utilizan, revise el

archivo /etc/services.

La opción de coinc idenc ia --destination-port es igual a --dport.

• --sport — Configura el puerto fuente del paquete usando las mismas opc iones que --dport. La

opción --source-port es sinónimo con --sport.

• --syn — Se aplica a todos los paquetes TCP des ignados a iniciar la comunic ac ión, comúnmente

llamados paquetes SYN. Cualquier paquete que esté llevando un payload de datos no será toc ado.

Utilice el carácter de exc lamac ión (!) después de --syn para coincidir los paquetes que nos sean

SYN.

• --tcp-flags <tested flag list> <set flag list> — Allows TCP pac kets that have

specific bits (flags) set, to match a rule.

La opción --tcp-flags acepta dos parámetros. El primer parámetro es la másc ara, una lista

de banderas a ser examinadas en el paquete. El segundo parámetro es una lista de banderas

separadas por comas que se deben establecer para que la regla coinc ida.

Las banderas pos ibles son:

• A C K




721


• FIN

• PSH

• RST

• SYN

• U R G

• ALL

• N ON E

Por ejemplo, una regla iptables que c ontenga la s iguiente espec if ic ac ión solo coincidirá con

paquetes TCP que tengan la bandera SYN activa y las banderas ACK y FIN sin activar.

--tcp-flags ACK,FIN,SYN SYN

Usando el c arac ter de exc lamac ión (!) después de --tcp-flags reversa el efecto de la opción de

coinc idenc ia.

• --tcp-option — Intenta selecc ionar con opc iones específ ic as de TCP que pueden estar ac tivas

en un paquete en particular. Esta opción se puede revertir con el punto de exclamac ión (!).

43.7.3.4.2. Protocolo UDP

Estas opc iones de selecc ión están disponibles para el protocolo UDP (-p udp):

• --dport — Espec if ic a el puerto destino del paquete UDP, usando el nombre del servicio, número

de puerto, o rango de números de puertos. La opción de coinc idenc ia --destination-port es

sinónimo con --dport.

• --sport — Configura el puerto fuente del paquete UDP, usando el nombre de puerto, número de

puerto o rango de números de puertos. La opción --source-port es sinónimo con --sport.

Para espec if ic ar un rango de números de puertos para las opc iones --dport y --sport, separe los

dos números con dos puntos ( :). Por ejemplo, -p tcp --dport 3000:3200. El rango más grande

aceptable es 0:65535.

43.7.3.4.3. Protocolo ICMP

Las siguientes opc iones de coinc idenc ia es tán disponibles para el Protocolo de mensajes de Internet

(ICMP) (-p icmp) :

• --icmp-type — Selecc iona el nombre o el número del tipo ICMP que conc uerde con la regla. Se

puede obtener una lista de nombres válidos ICMP escribiendo el c omando iptables -p icmp -

h.

43.7.3.4.4. Módulos con opciones de coincidencias adicionales

Opc iones adic ionales de coinc idenc ia es tán disponibles a través de los módulos cargados por el

comando iptables.

722


To use a match option module, load the module by name using the -m <module-nam e>, where

<module-name > is the name of the module.

Un gran número de módulos están disponibles por defecto. Es posible crear sus módulos para

proporc ionar func ionalidades adic ionales.

Lo s iguiente, es una lista parcial de los módulos usados más comúnmente:

• módulo limit — Permite colocar un límite en cuántos paquetes son coincididos a una regla

particular.

Cuando se usa en conjunto con el objetivo LO G, el módulo limit puede prevenir que una

inundac ión de paquetes c oinc identes sobrec arguen el registro del sistema con mensajes repetitivos

o usen los recursos del s istema.

Refer to Sección 43.7.3.5, “Opciones del objetivo” for more information about the LOG target.

El módulo limit habilita las opc iones s iguientes :

• --limit — Sets the maximum number of matc hes for a particular time period, specif ied as a

<value>/<period> pair. For example, using --limit 5/hour allows five rule matc hes per

hour.

Se pueden espec if ic ar los periodos en segundos, minutos, horas o días.

Si no se utiliza ningún número ni modificador de tiempo, se asume el siguiente valor por defecto:

3/hour.

• --limit-burst — Configura un límite en el número de paquetes capaces de cumplir una regla

en un determinado tiempo.

Esta opción deberá ser usada junto con la opción --limit, y acepta un número entero.

Si no se utiliza ningún valor, se asume el valor por defecto (5).

• módulo state — Habilita la coinc idenc ia de estado.

El módulo state tiene las siguientes opc iones :

• --state — coincide un paquete con los siguientes es tados de conexión:

• ESTABLIS HED — El paquete coinc idente se asoc ia con otros paquetes en una conexión

establec ida. Usted necesita aceptar este estado si desea mantener una conexión entre un

cliente y un servidor.

• INVALID El paquete selecc ionado no puede ser asoc iado a una conexión conoc ida.

• NEW — El paquete c oinc idente o bien está creando una nueva conexión o bien forma parte

de una conexión de dos caminos que antes no había sido vista. Usted nec es ita ac eptar este

estado si desea permitir nuevas c onexiones a un servic io.

• RELATED — El paquete coinc idente está iniciando una nueva conexión relac ionada de alguna

manera a una conexión existente.Un ejemplo es FTP, el cual utiliza una c onexión para control

de tráfico (puerto 21) y una conexión separada para transferenc ia de datos (puerto 20).

723


Estos estados de conexión se pueden utilizar en combinac ión con otros separándolos mediante

comas como en -m state --state INVALID, NEW.

• módulo mac — Habilita la coinc idenc ia de direcc iones MAC de hardw are.

El módulo mac activa las opc iones s iguientes :

• --mac-source — Coincide una dirección MAC a la tarjeta de red que envió el paquete. Para

excluir una dirección MAC de la regla, coloque un símbolo de exc lamac ión (!) después de la

opción --mac-source.

Consulte la página man de iptables para obtener más opc iones disponibles a través de los

módulos.

43.7.3.5. Opciones del objetivo

Una vez que un paquete ha coincidido con una regla, la regla puede dirigir el paquete a un número de

objetivos diferentes que determinan la acción apropiada. Cada c adena tiene un objetivo por defecto,

el cual es usado si ninguna de las reglas en esa cadena coinc iden con un paquete o si ninguna de las

reglas que coinc iden con el paquete espec if ic a un objetivo.

Los siguientes son los objetivos es tándar:

• <user-defined-chain> — A user-defined chain within the table. User-defined chain names must

be unique. This target passes the pac ket to the spec if ied chain.

• ACCEPT — Permite que el paquete se mueva hacia su destino o hacia otra cadena.

• DROP — Deja caer el paquete s in responder al solic itante. El s istema que envia el paquete no es

notificado de esta falla.

• QUEUE — El paquete se pone en una cola para ser manejado por una aplic ac ión en el espacio de

usuario.

• RETURN — Detiene la verificación del paquete contra las reglas de la cadena actual. Si el paquete

con un destino RETURN cumple una regla de una cadena llamada desde otra cadena, el paquete

es devuelto a la primera cadena para retomar la verificación de la regla allí donde se dejó. Si la

regla RETURN se utiliza en una cadena predefinida y el paquete no puede moverse hacia la cadena

anterior, el objetivo por defecto de la cadena actual es utilizado.

In addition, extens ions are available which allow other targets to be spec if ied. These extens ions are

called target modules or match option modules and most only apply to specific tables and situations.

Refer to Sección 43.7.3.4.4, “Módulos con opciones de coincidencias adicionales” for more information

about match option modules.

Existen varios módulos extendidos de objetivos, la mayoría de los cuales tan sólo se aplican a tablas

o situac iones específ ic as. Algunos de los módulos de objetivos más comunes incluidos en Red Hat

Enterprise Linux son:

• LO G — Regis tra todos los paquetes que coinc iden con esta regla. Pues to que los paquetes son

regis trados por el kernel, el archivo /etc/syslog.conf determina dónde estas entradas de

registro serán escritas. Por defec to, son coloc adas en el archivo /var/log/messages.

724


Se pueden usar varias opciones adic ionales tras el objetivo LOG para espec if ic ar la manera en la

que tendrá lugar el registro:

• --log-level — Configura el nivel de prioridad del registro de eventos. Una lista de los niveles

de prioridad se puede encontrar en la página man de syslog.conf.

• --log-ip-options — Registra cualquier opción en la cabecera de un paquete IP.

• --log-prefix — Coloca una cadena de hasta 29 caracteres antes de la línea de registro

cuando es escrita. Esto es muy útil para la escritura de filtros de syslog para usarlos en conjunto

con el registro de paquetes.

Nota

Debido a un problema con esta opción, se debe añadir un espac io al valor log-

prefix.

• --log-tcp-options — Cualquier opción coloc ada en la cabecera de un paquete TCP es

regis trada.

• --log-tcp-sequence Escribe el número de sec uenc ia TCP del paquete en el registro del

s istema.

• REJECT — Envia un paquete de error de vuelta al s is tema remoto y deja caer el paquete.

The REJECT target accepts --reject-with <type> (where <type> is the rejection type)

allowing more detailed information to be returned with the error pac ket. The message port-

unreachable is the default error type given if no other option is used. Refer to the iptables man

page for a full list of <type> options.

Otras extens iones de objetivos, inc luyendo muc has que son útiles para el enmasc aramiento de IP

usando la tabla nat o con alterac ión de paquetes usando la tabla mangle, se puede enc ontrar en la

página man de iptables.

43.7.3.6. Opciones de listado

The default list command, iptables -L [<chain-name>], provides a very basic overview of the

default filter table's current chains. Additional options provide more information:

• -v — Muestra la salida por pantalla con detalles, como el número de paquetes y bytes que cada

cadena ha proc esado, el número de paquetes y bytes que cada regla ha coincidido y qué interfac es

se aplican a una regla en particular.

• -x — Expande los números en sus valores exactos. En un sistema ocupado, el número de

paquetes y bytes vistos por una cadena en concreto o por una regla puede estar abreviado en

Kilobytes, Megabytes o Gigabytes. Esta opción fuerza a que se muestre el número completo.

• -n Muestra las direcc iones IP y los números de puertos en formato numéric o, en lugar de utilizar el

nombre del servidor y la red tal y como se hace por defecto.

• --line-num bers — Proporc iona una lista de cada cadena junto con su orden numérico en la

cadena. Esta opción puede ser útil c uando esté intentando borrar una regla específ ic a en una

cadena o localizar dónde insertar una regla en una cadena.

725

Guardando reglas IPTables

• -t <table-name> — Spec if ies a table name. If omitted, defaults to the filter table.

Los siguientes ejemplos ilustran el uso de varias de esas opc iones. Note la diferenc ia en los byte

mostrados al incluir la opción -x.

[root@myserver ~]# ipta bles -L OUTPUT -v -n -x

Chain OUTPUT (polic y ACCEPT 64005 packets, 6 44 5 79 1 bytes )

pkts bytes target prot opt in out source destination

15 9 3 13 3 81 2 ACCEPT icm p -- * * 0.0.0.0/0 0.0.0.0/0

[root@myserver ~]#iptables -L OUTPUT -v -n

Chain OUTPUT (polic y ACCEPT 64783 packets, 6492K bytes)

pkts bytes target prot opt in out source destination

18 1 9 153K ACCEPT icm p -- * * 0.0.0.0/0 0.0.0.0/0

[root@myserver ~]#

43.7.4. Guardando reglas IPTables

Las reglas creadas con el comando iptables son almac enadas en memoria. Si el s istema es

reiniciado antes de guardar el conjunto de reglas iptables, se perderán todas las reglas. Para que

las reglas de filtrado de red pers istan luego de un reinicio del sistema, éstas necesitan ser guardadas .

Para hac erlo, escriba el s iguiente comando como root:

/sbin/service iptables save

Esto ejec uta el script de inicio iptables, el cual ejecuta el programa /sbin/iptables-save y

escribe la configurac ión actual de iptables a /etc/sysconfig/iptables . El archivo /etc/

sysconfig/iptables exis tente es guardado como /etc/sysconfig/iptables.save.

La próxima vez que se inicie el s is tema, el script de inicio de iptables volverá a aplicar las reglas

guardadas en /etc/sysconfig/iptables usando el comando /sbin/iptables-restore.

While it is always a good idea to test a new iptables rule before committing it to the /etc/

sysconfig/iptables file, it is poss ible to copy iptables rules into this file from another sys tem's

version of this file. This provides a quick way to distribute sets of iptables rules to multiple

mac hines.

Es posible guardar las reglas iptables en un archivo separado para ser distribuido, como copia de

seguridad o bajo algún otro propós ito. Para guardar sus reglas iptables, escriba el s iguiente comando

como root:

[roo t@m y se rve r ~]# iptables- save > <filename>

wh ere <filen a m e> is a user-defined name for your ruleset.

Importante

Si se está dis tr ibuyendo el archivo /etc/sysconfig/iptables a otras máquinas,

escriba /sbin/service iptables restart para que las nuevas reglas surtan

efecto.





726

Guardando reglas IPTables

Nota

Note la diferenc ia entre el comando iptables (/sbin/iptables), el cual es

utilizado para manipular las tablas y las cadenas que constituyen la func ionalidad de

iptables, y el servicio iptables (/sbin/iptables service), utilizado para

activar o desactivar el servicio iptables.

43.7.5. Scripts de control de IPTables

Hay dos métodos bás ic os para controlar iptables en Red Hat Enterprise Linux:

• /sbin/service iptables <option> — Used to manipulate various functions of iptables

using its initscript. The following options are available:

• start — Si se tiene un cortafuegos configurado (es decir, si /etc/sysconfig/iptables

existe), todos los iptables en ejecuc ión son detenidos c ompletamente y luego arranc ados

usando el comando /sbin/iptables-restore. Esta opción solo funcionará si no se carga

el módulo del kernel ipchains. Para revisar si este módulo está c argado, ejec ute como root el

siguiente comando:

[root@MyServer ~]# lsmod | grep ipchain s

Si es te c omando no retorna ninguna salida, significa que el módulo no está cargado. De ser

nec esario, utilice /sbin/rmmod para remover el módulo.

• stop — Si el cortafuegos está en ejec uc ión, se desc artan las reglas del cortafuegos que se

enc uentran en memoria y todos los módulos iptables y ayudantes son desc argados.

Si se c ambia la directiva IPTABLES _S AVE_ON_S TOP dentro del archivo de configurac ión /

etc/sysconfig/iptables-config de su valor por defecto a ye s, se guardan las reglas

ac tuales a /etc/sysconfig/iptables y cualquier regla exis tente se moverá al archivo /etc/

sysconfig/iptables.save.

Refer to Sección 43.7.5.1, “Archivo de configuración de scripts de control de IPTables” for more

information about the iptables-config file.

• restart — Si el cortafuegos está en ejec uc ión, las reglas del mismo que se encuentran en

memoria se descartan y se vuelva a iniciar el cortafuegos si está configurado en /etc/

sysconfig/iptables. La directriz restart sólo funcionará si no está cargado el módulo del

kernel ipchains.

Si la directiva IPTABLES_S AVE_ON_RES TART dentro del archivo de configuración /etc/

sysconfig/iptables-config se c ambia de su valor por defec to a yes, las reglas actuales

son guardadas a /etc/sysconfig/iptables y cualquier regla existente se moverán al

archivo /etc/sysconfig/iptables.save .

Refer to Sección 43.7.5.1, “Archivo de configuración de scripts de control de IPTables” for more

information about the iptables-config file.

• status — Mues tra el estado del cortafuegos y lista todas las reglas activas.

mailto:root@MyServer

727

Scripts de control de IPTables

The default configuration for this option displays IP addresses in each rule. To display domain and

hostname information, edit the /etc/sysconfig/iptables-config file and change the value

of IPTABLES _STATUS_NUMERIC to no. Refer to Sección 43.7.5.1, “Archivo de configuración de

scripts de control de IPTables” for more information about the iptables-config f ile.

• panic — Desc arta todas las reglas del cortafuegos. La política de todas las tablas configuradas

es establec ida a DROP.

Esta opción puede ser útil si se sabe que un servidor está comprometido. En vez de desc onectar

fís icamente el servidor de la red o apagar el s istema, usted puede utilizar esta opción para

detener el tráfico pero dejando la máquina en un estado que puede ser utilizado para anális is.

• save — Saves firewall rules to /etc/sysconfig/iptables using iptables-save. Refer to

Sección 43.7.4, “Guardando reglas IPTables” for more information.

Tip

To use the same initscript commands to control netfilter for IPv6, substitute

ip6tables for iptables in the /sbin/service commands listed in this section.

For more information about IPv6 and netfilter, refer to Sección 43.7.6, “IPTables y

IPv6”.

43.7.5.1. Archivo de configuración de scripts de control de IPTables

El comportamiento de los scripts de inicio de iptables es controlado por el archivo de configurac ión

/etc/sysconfig/iptables-config. A continuac ión se presenta una lista de las directivas

contenidas dentro de este arc hivo:

• IPTABLES _MODULES — Espec if ic a una lista separada por espac ios de módulos iptables

adic ionales a cargar cuando se activa un cortafuegos. Esto puede incluir seguimiento de

conexiones y ayudantes NAT.

• IPTABLES_MODULES_UNLOAD — Desc arga los módulos al iniciar o al detenerse. Esta directiva

acepta los valores s iguientes :

• yes — El valor por defecto. Esta regla debe establecerse para alc anzar un estado c orrec to para

reiniciar o detener un cortafuegos.

• no — Esta opción solamente debería ser configurada si hay problemas al desc argar los módulos

de filtrado de paquetes de red.

• IPTABLES _S AVE_ON_S TOP — Guarda las reglas del cortafuegos actuales a /etc/sysconfig/

iptables cuando se detiene el cortafuegos. Esta directiva acepta los valores s iguientes :

• yes — Guarda las reglas existentes a /etc/sysconfig/iptables c uando se detiene el

cortafuegos, moviendo la versión anterior al archivo /etc/sysconfig/iptables.save.

• no — El valor por defecto. No guarda las reglas exis tentes c uando se detiene el cortafuegos.

• IPTABLES_S AVE_ON_RES TART — Guarda las reglas ac tuales del cortafuegos c uando este se

reinicia. Esta directiva acepta los valores s iguientes :

728

Scripts de control de IPTables

• yes — Guarda las reglas existentes a /etc/sysconfig/iptables cuando se reinicia el

cortafuegos, moviendo la versión anterior al archivo /etc/sysconfig/iptables.save.

• no — El valor por defecto. No guarda las reglas exis tentes c uando se reinicia el c ortafuegos.

• IPTABLES_S AVE_COUNTER — Guarda y restaura todos los paquetes y contadores de bytes en

todas las cadenas y reglas. Esta directiva acepta los valores s iguientes :

• yes — Guarda los valores del contador.

• no — El valor por defecto. No guarda los valores del contador.

• IPTABLES_S TATUS _NUMERIC — Mues tra direcc iones IP en una salida de estado en vez de

dominios y nombres de host. Esta directiva acepta los valores s iguientes :

• yes — El valor por defecto. Solamente devuelve direcc iones IP dentro de una salida de estado.

• no — Devuelve dominios o nombres de host en la salida de estado.

43.7.6. IPTables y IPv6

Si el paquete iptables-ipv6 es ins talado, netfilter en Red Hat Enterprise Linux puede filtrar el

protocolo de Internet IPv6. El comando utilizado para manipular los filtros de red IPv6 es ip6tables.

La mayoría de las directivas para este c omando son idéntica a aquellas usadas por iptables,

excepto que la tabla nat aún no es c ompatible. Esto signif ica que todavía no es posible realizar

tareas de traducción de direcc iones de red IPv6, tales como enmasc arado y reenvío de puertos.

Las reglas guardadas para ip6tables son almac enadas en el archivo /etc/sysconfig/

ip6tables. Las reglas viejas guardadas por los scripts de inicio de ip6tables son guardadas en el

archivo /etc/sysconfig/ip6tables.save.

Las opc iones de configurac ión para los script de inicio de ip6tables es /etc/sysconfig/

ip6tables-config y los nombres para cada directriz varían ligeramente de sus contrapartes en

iptables.

Por ejemplo, la directriz IPTABLES_MODULES en iptables-config es la equivalente a

IP6TABLES_MODULES en el archivo ip6tables-config.


Consulte las fuentes s iguientes para obtener información adicional sobre f iltrado de paquetes c on

iptables.


• man iptables — Contiene una descripc ión de iptables así como también una lista detallada

de objetivos, opc iones y extens iones de coinc idencia.

43.7.7.2. Sitios web útiles

• http://www.netfilter.org/ — El sitio principal del proyecto de netf ilter/iptables. Contiene información

varia sobre iptables, inc luyendo una secc ión FAQ detallando problemas específ ic os y varias

http://www.netfilter.org/

729


guías de ayuda esc ritas por Rusty Russell, el mantenedor del cortafuegos IP de Linux.

Los documentos HOWTO del sitio cubren aspectos tales como conc eptos bás ic os de

redes, filtrado de paquetes del kernel y configurac iones NAT.

• http://www.linuxnewbie.org/nhf/Security/IPtables_Basics.html — una visión bás ic a y

general sobre la forma cómo los paquetes se mueven dentro del kernel de Linux, además

de una introducción sobre cómo se cons truyen c omandos iptables s imples.

http://www.linuxnewbie.org/nhf/Security/IPtables_Basics.html

Technology

43 aseguramiento de su red