43 aseguramiento de su red
TRANSCRIPT
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
Seguridad del BIOS y del gestor de arranque
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
Seguridad del BIOS y del gestor de arranque
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.
Algunos ejemplos inseguros inc luyen:
• 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.
Algunos ejemplos inseguros inc luyen:
• 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.
Algunos ejemplos inseguros inc luyen:
• 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:
Algunos ejemplos inseguros inc luyen:
• 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.
Algunos ejemplos inseguros inc luyen:
• R0X4H
• nauj
• 9-DS
• No escriba su contraseña — Nunca guarde su contraseña en un papel. Es mucho más seguro
memorizarla.
636
Seguridad de contraseñas
• 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.
637
Seguridad de contraseñas
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.
638
Seguridad de contraseñas
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.
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
Controles administrativos
-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
Controles administrativos
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
Controles administrativos
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
Controles administrativos
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
Controles administrativos
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
Controles administrativos
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
Controles administrativos
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
Asegurando los servic ios con TCP Wrappers y xinetd
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
Asegurando los servic ios con TCP Wrappers y xinetd
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
Asegurando los servic ios con TCP Wrappers y xinetd
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 :
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
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.
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
Rec ursos adic ionales
• 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.
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.
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
Archivos de configurac ión de Wrappers TCP
• <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
Archivos de configurac ión de Wrappers TCP
• 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
Archivos de configurac ión de Wrappers TCP
• 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
Archivos de configurac ión de Wrappers TCP
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
Archivos de configurac ión de Wrappers TCP
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
Archivos de configurac ión de Wrappers TCP
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
Archivos de configurac ión de Wrappers TCP
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
Archivos de configurac ión de xinetd
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
Archivos de configurac ión de xinetd
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
socket_type = stream
wait = n o
use r = root
serve r = /usr/kerberos/sbin/telnetd
log_on_failure += USERID
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
Archivos de configurac ión de xinetd
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
Archivos de configurac ión de xinetd
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
{
socket_type = stream
wait = n o
serve r = /usr/kerberos/sbin/telnetd
log_on_success += DUR ATI ON USERID
log_on_failure += 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
Archivos de configurac ión de xinetd
• 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.
43.5.5. Recursos adicionales
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.
43.5.5.1. Documentación instalada
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.
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.
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.
Haga clic en Adelante para continuar.
700
Configurac ión IPsec de host-a-host
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”.
Haga clic en Adelante para continuar.
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.
701
Configurac ión IPsec de host-a-host
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
Configurac ión IPsec de host-a-host
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
Configurac ión IPsec de host-a-host
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
Configurac ión IPsec de host-a-host
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
Configuración de IPsec de red-a-red
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
Configuración de IPsec de red-a-red
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.
Haga clic en Adelante para continuar.
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.
Haga clic en Adelante para continuar.
708
Configuración de IPsec de red-a-red
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.
Haga clic en Adelante para continuar.
709
Configuración de IPsec de red-a-red
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
Configuración de IPsec de red-a-red
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
Configuración de IPsec de red-a-red
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
Configuración de IPsec de red-a-red
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
Opc iones de comandos para IPTables
• -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
Opc iones de comandos para IPTables
• 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
Opc iones de comandos para IPTables
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
Opc iones de comandos para IPTables
• 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
Opc iones de comandos para IPTables
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
Opc iones de comandos para IPTables
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
Opc iones de comandos para IPTables
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.
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.
43.7.7. Recursos adicionales
Consulte las fuentes s iguientes para obtener información adicional sobre f iltrado de paquetes c on
iptables.
43.7.7.1. Documentación instalada
• 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
729
Rec ursos adic ionales
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.