Tuto Linux Capitulo 8/9 (Servidores de Seguridad en LINUX)

Módulo VIII
(Servidores de seguridad en Linux)

Introducción

En este módulo se estudiará como utilizar Linux para brindar seguridad a una red local dentro de una empresa, oficina o para uso hogareño.
Primero lo primero: seguridad "física"
Cuando se quiere tener un equipo seguro es importante considerar todos los aspectos que están involucrados. Uno de ellos y sin duda, uno de los más importantes es la seguridad que se brinda en el entorno donde está ubicado el equipo.
El punto más débil que tienen la mayoría de los equipos es su consola. Siempre se asume que la persona que esté ubicada en frente de la consola, es la persona que administra el equipo o tiene pleno conocimiento del funcionamiento del mismo. Desde la consola se pueden realizar tareas como:
Apagar el equipo y dejar sin servicio a los usuarios
Reiniciar el equipo en un modo en particular (runlevel)
Insertar un diskette dentro del equipo y arrancar el mismo leyendo del diskette
Acceder a la configuración de hardware del equipo (BIOS)
Todos estos puntos tienen que controlarse y tratar de eliminar todos los posibles puntos de entrada. Llegado el caso de que un intruso logre estar personalmente en frente de la consola.
Estos puntos de entrada se pueden cerrar tomando las siguientes precauciones:
Colocar el equipo en una sala cerrada bajo llave
Eliminar cualquier periférico que no se utilice con frecuencia (como diskettera, CDROM, etc.)
Setear el arranque en la BIOS para permitirlo solamente desde el disco rígido primario
Proteger el BIOS del equipo con clave (tomar en cuenta que algunas BIOS viejas tenían password universal)
Eliminar puertos seriales y/o paralelos que no se utilicen
Desconectar teclado, mouse y video si estos no son utilizados
Todos estos puntos son muy importantes, ya que un equipo Linux puede ser reinicializado simplemente apretando Ctrl-Alt-Del y luego inicializado en modo mantenimiento (donde el sistema no preguntará la clave del súper usuario). Mas adelante veremos como anular esta combinación de teclas (o configurarla para cualquier otro uso).
Otro tipo de ataque puede realizarse a través de la diskettera e incluso a través de los puertos serie y paralelo.
Como siempre existen muchas formas de quebrar la seguridad de un sistema, nunca se es lo suficiente precavido, pero es importante complicar al máximo la entrada de un posible intruso.

En los próximos apartados contemplaremos la seguridad lógica del sistema, o sea a nivel software, pero debe insistirse una vez más que si un potencial intruso tiene acceso al hardware no hay ningún tipo de seguridad lógica inviolable.
LILO: Primer punto de entrada
En el caso de que alguien llegue a acceder a la consola en un servidor (o para el caso en cualquier otra máquina) es muy probable que el primer punto de entrada al sistema que intente utilizar sea reiniciar el sistema, ingresando luego en modo monousuario desde el LILO con la siguiente opción:
LILO: linux 1<Enter>
La protección que puede darse al LILO se contempla en las siguientes secciones.
Eliminar el prompt "LILO:" y/o cambiar el tiempo de espera
Veamos el siguiente archivo lilo.conf como ejemplo:
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt # muestra LILO: al bootear
timeout=50 # espera 50 décimas de segundo
default=linux
image=/boot/vmlinuz-2.2.14
label=linux
root=/dev/hdc13
initrd=/boot/initrd-2.2.14.img
read-only
La instrucción "prompt" es la que hace aparecer la palabra "LILO:" al bootear el sistema, si eliminamos esta opción permitiremos todavía seguir ingresando parámetros (tendremos 5 segundos en este ejemplo).
Adicionalmente podríamos dejar la línea del tiempo de espera en 0 décimas de segundo, con lo cual LILO comenzará a bootear el sistema inmediatamente (la línea debería quedar "timeout=0"). Cabe destacar que este seteo puede bypassearse durante el booteo si se mantiene presionada la tecla SHIFT.
Poner password al LILO
Esta opción, si se la utiliza en modo conjunto con la opción "restricted", complementa muy adecuadamente a las anteriores, sirve para evitar que pueda tomarse una acción diferente a la acción por defecto del LILO. Por ejemplo, si la acción por defecto es iniciar el sistema en modo normal ("linux"), esta acción sigue ejecutándose igual al ponerle password y acceso restringido al LILO, pero para entrar en modo monousuario ("linux 1") deberemos ingresar el password.
En caso de no utilizar la opción "restricted", LILO nos pedirá siempre el password, incluso para bootear la opción por defecto.
La forma de ponerle password al lilo es nuevamente modificando el archivo lilo.conf, si quisiéramos agregarle password al archivo del ejemplo anterior quedaría de la siguiente forma:
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt # muestra LILO: al bootear
timeout=50 # espera 50 décimas de segundo
default=linux
image=/boot/vmlinuz-2.2.14
label=linux
root=/dev/hdc13
initrd=/boot/initrd-2.2.14.img
read-only
restricted # pedirá el password si
# se desea utilizar opciones
password=HpKtW12 # el password en texto plano
# (OJO!)
Como se ve, la ultima línea tiene el password en formato de texto plano. El primer paso será hacer que el archivo lilo.conf tenga permiso de solo lectura solamente para el usuario root (como dato anecdótico, acabo de copiar el ejemplo de arriba desde mi cuenta de usuario, de modo que los permisos por defecto no son buenos).
Como último punto a tocar en el archivo lilo.conf, podemos setear el modo inmutable, con lo cual evitaremos cualquier cambio al mismo. Para setear este modo haremos:
chattr +i /etc/lilo.conf
En caso que debamos en algún momento modificar el archivo lilo.conf (por ejemplo por haber compilado un nuevo kernel), deberemos quitar el modo inmutable:
chattr -i /etc/lilo.conf
Recuerde que siempre que modifique el lilo.conf, deberá grabar los cambios al sector de booteo (chequee MUY bien el archivo antes):
lilo -vLa base de la seguridad en Extended 2 Filesystem
El sistema de archivos Linux Nativo, llamado Extended 2 Filesystem en su presente versión, brinda mecanismos de seguridad basados en permisos seteables mediante flags para usuarios y grupos. Los permisos básicos permiten setear lectura, escritura y ejecución para el owner del archivo, para el grupo, y para el resto de los usuarios.
Adicionalmente tenemos los permisos especiales SUID, SGID y Sticky Bit.
Todos estos permisos ya se vieron, pero ahora contemplaremos algunos detalles desde el punto de vista de seguridad.
En teoría los únicos directorios donde los usuarios pueden tener permiso de escritura deberían ser /home y /tmp. Es muy conveniente que estas zonas donde se deja que escriban otras personas estén en una partición diferente al resto del sistema, ya que llenar el disco es uno de los ataques de denegación de servicio (Denial of Service = DoS).
Hay otros directorios donde si bien no se brinda a los usuarios permiso directo de escritura, pueden ser objetivos de un ataque DoS, en particular los que se ubican bajo /var, donde se generan logs. Un atacante podría utilizar un software que genere errores por ejemplo en nuestro servidor Apache, con lo cual llenaría el espacio disponible en /var. Si /var estuviera en la misma partición que /, tendríamos un ataque DoS.
Como comentario, usualmente se ejecuta un script llamado logrotate mediante una entrada en crontab, que se ocupa de que los logs más viejos se vayan eliminando, para evitar que /var se llene por un uso normal.
Otro caso donde debe tenerse especial cuidado con un posible ataque DoS es cuando se configure un servidor ftp anónimo con posibilidad de que los usuarios hagan upload. Esta configuración es bastante común, creándose al efecto un directorio /incoming. Para evitar un DoS hay que utilizar una partición separada para este directorio.
Debe tenerse muchísimo cuidado con los ejecutables que tengan seteados los bits SUID o SGID, ya que si el owner es root, cualquier usuario podría (potencialmente) modificar algo en el sistema con uno de estos ejecutables.
Para encontrar fácilmente los archivos con alguno de estos bits seteados podemos utilizar el comando find:
find / -perm +4000 # muestra ejecutables con bit SUID
find / -perm +2000 # muestra ejecutables con bit SGID
Algunos sistemas operativos (Sun, WinNT, etc) permiten setear los permisos a un archivo dado con mucho más detalle que extended 2, mediante lo que se llaman Listas de Control de Acceso (Access Control Lists = ACL). Actualmente se encuentran en desarrollo algunos proyectos que permiten implementar ACL sobre sistema Linux Nativo, si bien ninguno de estos proyectos se encuentra aún lo suficientemente maduro como para utilizarse con confianza en un entorno empresarial.
Hace no mucho tiempo circularon rumores sobre que Extended 3 Filesystem, la versión futura de Linux Nativo, implementaría ACL. Esto aparentemente no es totalmente cierto. Lo que se implementara serán "ganchos" (hooks) para enlazar el filesystem con algún mecanismo externo de ACL.
Para mas información sobre ACL en Linux recurrir a Internet
Borrado seguro de información
Este punto debe tenerse en cuenta cuando se maneje información confidencial que deba ser destruida sin posibilidad de recuperación.
El borrado estándar de información en un sistema extended 2 (como en casi cualquier otro) no destruye físicamente la información, que puede ser recuperada con un poco de esfuerzo desde la superficie magnética del disco. De hecho podemos encontrar publicidad de empresas que se dedican a recuperación de información perdida accidentalmente por un precio módico (o no tan módico).
Hoy en día existen herramientas para casi cualquier sistema operativo que garantizan la destrucción completa de información, sobreescribiendo la superficie magnética con patrones aleatorios de unos y ceros.
Passwords y archivos importantes del sistema
Desde sus inicios la utilización de passwords en sistemas Linux ha progresado en pos de una mayor seguridad.
Antiguamente (aún hoy pueden encontrarse entornos donde se utiliza este sistema) los passwords se encriptaban mediante un algoritmo llamado crypt, heredado de UNIX, y se almacenaban en el archivo /etc/passwd junto con la información de las cuentas de los usuarios.
Debido a requerimientos del sistema este archivo debe permanecer con permiso de lectura para todos los usuarios (r-- para other). De no ser así muchas funcionalidades del entorno Linux no funcionarían.
Si los passwords encriptados fueran accesibles para todo el mundo, cualquier atacante podría robar el archivo y correr algún soft de búsqueda de passwords encriptados mediante crypt, y en un tiempo variable obtener los passwords de los usuarios del sistema.
Hoy se está utilizando un sistema llamado "shadow passwords" que evita que los passwords encriptados estén al alcance de cualquiera. Básicamente consiste en reemplazar el campo del password encriptados por algún carácter (en Red Hat una 'x') que indica que los verdaderos passwords encriptados se encuentran en otro archivo, típicamente /etc/shadow. La diferencia radica en que este último archivo solo puede ser leído por root.
En adición a esto, algunas distribuciones implementan un algoritmo de encriptación bastante mas complejo que el viejo crypt, llamado MD5. Red Hat Linux incorpora ambos mecanismos de protección al menos desde su versión 6.0.
Como dato informativo, los passwords en ningún momento pueden encontrarse en el sistema como texto plano, y NO son desencriptables, ya que la clave utilizada para la encriptación es el mismo password. Esto es válido tanto para passwords encriptados con crypt como para passwords MD5.
Si alguien logra hacerse con el archivo /etc/shadow, no puede desencriptar los passwords. El proceso a seguir consiste en probar combinaciones de caracteres (típicamente se utiliza un diccionario de palabras) encriptadas contra ellas mismas, y compararlas con los passwords encriptados del archivo. De haber coincidencia, se encontró un password.
Nunca se insistirá suficiente sobre la necesidad de seleccionar un password adecuando. Como reglas básicas podría decirse lo siguiente:
NO utilizar nombres propios (y MENOS el nombre del usuario)
NO utilizar el ID de usuario como password (es lo primero a probar durante un ataque)
NO utilizar nombres de cosas comunes que puedan encontrarse en un diccionario (perro, casa, Coca-Cola, etc.)
mezclar mayúsculas, minúsculas y números en el password
armar el password de una forma que uno pueda recordarlo fácilmente (un ejemplo que leí en un libro decía tomar las iniciales de las palabras de una frase que uno pueda recordar fácilmente)
Frase: "Yo vivo en Carlos Pellegrini 3183"
Password: YveCP3183
JAMAS escribir el password en papel
Una medida extrema consistiría en setear los archivos /etc/passwd y /etc/shadow como inmutables una vez cargadas todas las cuentas. En caso de hacer esto debe recordarse quitar el flag inmutable cuando se deseen hacer modificaciones.
Es bastante raro utilizar passwords para los grupos, pero valen las misma consideraciones, solo que los archivos involucrados son /etc/group y /etc/gshadow.
Algunos otros archivos importantes
/etc/login.defs
Contiene algunos valores por defecto a setear cuando se crean usuarios con useradd, y otros relativos a la expira de passwords. Suele venir bien comentado y con valores que no requieren cambios, pero es bueno pegarle una mirada al menos para estar al tanto de estos valores.
/etc/shells
Es la lista de shells disponibles. Cualquier usuario que tenga seteada cualquiera de las shells de esta lista en su línea del /etc/passwd podrá loguearse interactivamente. Inversamente cualquier shell que no se encuentre listada en este archivo no permitirá el login interactivo.
/etc/securetty
Un archivo muy interesante. Es la lista de terminales desde las cuales puede loguearse el usuario root. Es una buena medida que este archivo solo contenga 'tty1' con lo cual nos aseguramos que nadie pueda loguearse como root salvo en la primer consola local. En particular debe evitarse (salvo que sea imprescindible) que se encuentre listada alguna terminal serie o remota.
/etc/inittab
Este archivo ya es conocido por nosotros. Aquí podría modificarse una línea que atrapa la secuencia de teclas Ctrl-Alt-Supr que en Red Hat ocasiona un reboot del sistema. Puede hacerse que esta secuencia no actúe, o ejecute algún otro comando. La sección a modificar es la siguiente:
# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
/etc/issue.net
Mensaje de bienvenida para el telnet remoto, usualmente en Red Hat tenemos:
[Nekromancer@linux11 Nekromancer]$ telnet linux10
Trying 10.0.0.10...
Connected to linux10.mixnet.
Escape character is '^]'.

Red Hat Linux release 6.0 (Hedwig)
Kernel 2.2.5-15 on an i586
login:
Lo cual brinda mucha información, sistema operativo, versión, kernel, etc.
Puede modificarse para evitar esto, pero debe modificarse rc.local para que no se genere nuevamente tras un reboot. Podríamos dejarlo, por ejemplo, de la siguiente forma:
[Nekromancer@linux11 Nekromancer]$ telnet linux11
Trying 10.0.0.11...
Connected to linux11.mixnet.
Escape character is '^]'.
Welcome to Intex System
OS 6.6.6alpha / RS6000

login:
Con lo cual evitamos brindar información sobre nuestro sistema.
Si uno es programador (y paranoico) puede modificar el código del programa "login" para que no muestre el prompt, o cualquier modificación que se considere necesaria.
Recordar muchos passwords
Si Ud. es administrador de varias redes (es root en todas ellas) deberá recordar varios passwords, y tal vez se sienta tentado de anotarlos en una agenda.
Mucho mejor sería guardar la lista completa de todos los passwords en una base de datos encriptada en su PC portátil, de esta forma solo necesitará recordar 1 password.
root es Dios
Y cualquier persona que gane acceso como root a un sistema será Dios también.
Los poderes de root como administrador de un sistema Linux son absolutos, pudiendo tener acceso a TODA la información del sistema, y pudiendo modificar CUALQUIER configuración del mismo.
En algunas oportunidades puede llegar a ser deseable que no exista un usuario con tanto poder. Si este es el caso puede optarse por una aplicación llamada 'sudo' (no viene con Red Hat, pero puede obtenerse del site ftp de Red Hat, en el subdirectorio /pub/contrib). Esta herramienta permite dar poderes de acceso adicionales a determinados usuarios, lo cual nos permitiría en principio distribuir la administración de una red grande. Podríamos asignar un administrador para la parte de mail, otro para Apache, etc. Y una vez hecho esto podríamos inactivar la cuenta root.
IMPORTANTE: no desactivar la cuenta root hasta estar completamente seguro que se ha configurado sólo para realizar todo tipo de tareas administrativas.
Como comentario, la mayor parte de las distribuciones no permiten que root se valide con un login remoto (telnet). En caso de necesitar validarse como root mediante telnet, debe validarse primero como un usuario normal y luego ejecutar 'su' para obtener privilegios de root.
Wrappers: Seguridad en redes a nivel inetd
TCP Wrappers es un mecanismo de seguridad para aquellos servicios que sean iniciados desde el superserver inetd.
Su utilización es sumamente sencilla, necesitando tan solo dos archivos de configuración:
/etc/hosts.allow
/etc/hosts.deny
Cualquier regla que figure en hosts.allow permitirá un acceso. En caso de no haber una regla que lo permita en hosts.allow, se chequea el archivo hosts.deny para ver si alguna regla lo esta denegando. En caso de no existir una regla para el servicio en ninguno de los dos archivos el servicio es autorizado por defecto. Es importante destacar que la búsqueda termina ni bien se encuentra una regla que se aplique.
La sintaxis básica de una regla es la siguiente:
{demonio}: {cliente} [EXCEPT cliente]
Por ejemplo, para habilitar el acceso por telnet desde mylinux.xtech.com.ar:
in.telnetd: mylinux.xtech.com.ar
Para especificar el acceso desde todo xtech, excepto desde la máquina control1:
in.telnetd: .xtech.com.ar EXCEPT control1.xtech.com.ar
Puede especificarse más de un cliente separados por comas, utilizar nombres de dominio, combinaciones IP/netmask, etc.
Las reglas soportan algunos comodines muy prácticos, entre ellos los dos siguientes:
ALL - corresponde a cualquier demonio, maquina o dominio
LOCAL - corresponde a las maquinas de nuestra red local
De modo que para denegar todo acceso, simplemente pondríamos en /etc/hosts.deny:
ALL: ALL
Este sistema es simplemente un filtro de paquetes. Si se bloquea un servicio, primero se establece la conexión y luego se indica acceso denegado, con lo cual el atacante SABE que el servicio esta presente, pero inhabilitado por wrappers.
Cuando se utiliza firewalling, en cambio, ni siquiera puede establecerse la conexión. Esta en cada administrador decidir cual es el nivel de protección necesario para su caso particular.
Como ejemplo de lo antedicho, veamos el intento de acceso vía ftp a una máquina que tiene ftp inhabilitado por wrappers:
[Nekromancer@linux11 Nekromancer]$ ftp linux10
Connected to linux10.mixnet.
421 Service not available, remote server has closed connection
ftp> bye
[Nekromancer@linux11 Nekromancer]$
Como se vé brinda indicación acerca de que el servicio ftp esta activo, pero bloqueado desde esta ubicación.
Algo similar podemos apreciar en un intento de telnet:
[Nekromancer@linux11 Nekromancer]$ telnet linux10
Trying 10.0.0.10...
Connected to linux10.mixnet.
Escape character is '^]'.
Connection closed by foreign host.
[Nekromancer@linux11 Nekromancer]$
Si utilizáramos firewalling directamente no se podría haber establecido la conexión con la maquina linux10.
Para mas información sobre TCP Wrappers mirar las man pages de hosts.allow, hosts.deny y hosts_access.
ipchains: Filtrado de paquetes (firewalling)
Este es un mecanismo de firewalling incorporado en los kernels 2.2.x, que si bien es sumamente sofisticado y completo (aunque difícil de utilizar) será probablemente reemplazado en los kernels 2.4.x por algo aun mas sofisticado y completo.
Se basa en el mantenimiento de 3 juegos de reglas de firewalling, uno para las conexiones entrantes (input), otro para las conexiones salientes (output) y el tercero para el reenvío de paquetes de red (forward).
Las reglas pueden encadenarse (de ahí el nombre ipchains) para obtener reglas compuestas.
La man page de ipchains tiene fama de ser una de las más difíciles de comprender de las que vienen con el paquete Linux. Afortunadamente hoy no es difícil encontrar información en Internet repleta de ejemplos prácticos de uso.
La sintaxis básica de ipchains es la siguiente:
ipchains -F cadena [opciones]
# vaciar una cadena de reglas
ipchains -A cadena regla [opciones]
# agregar una regla a la cadena
ipchains -D cadena número_de_regla [opciones]
# borrar una regla
Las opciones típicas son las que se utilizan con "ipchains -A", correspondiente al agregado de una regla en una cadena. La sintaxis seria:
ipchains -A cadena -p protocolo -j tipo -s origen -i interface -d destino puerto
cadena puede ser input, output o forward.
protocolo puede ser tcp, udp, icmp o all.
tipo puede ser ACCEPT, DENY, REJECT, MASQ, REDIRECT o RETURN.
origen define el origen de los paquetes, puede ser un host o una red definida por IP base/netmask.
interface es la interface a la cual se aplica la regla, típicamente eth0.
destino sigue la misma sintaxis que origen.
puerto puede ser un puerto aislado o un rango separado por dos puntos (1:1023).
Cabe aquí una aclaración, cuando se detalla origen o destino, la netmask no se escribe en el formato ya conocido (10.10.2.0/255.0.0.0) sino como un número que indica la cantidad de bits que utiliza la netmask, llamado bitmask, por ejemplo:
255.255.255.0 = 24 (24 bits de la mascara seteados a '1')
255.255.0.0 = 16 (16 bits de la mascara seteados a '1')
255.0.0.0 = 8 (8 bits de la mascara seteados a '1')
Asimismo puede utilizarse 0.0.0.0/0 como comodín (equivalente a cualquier red).
Al comenzar a probar o utilizar ipchains es altamente conveniente buscar algún front-end para ipchains, que muestre las reglas en una forma entendible para un humano. Existen varios paquetes, por ejemplo kfirewall para KDE.
Usualmente (cuando se domina el tema) se arma un script o scripts que definen las reglas, y se configura el sistema para ejecutar estos scripts inmediatamente después del pasaje a runlevel 3 (cuando se levantan las interfaces de red).
Un ejemplo muy básico de script seria el siguiente:
#!/bin/bash
# Script de seteo básico de reglas de
# firewalling utilizando ipchains
#
# Definición de variables
#
ETH0IP=10.10.2.5 # IP de la placa de red
ETH0NET=10.10.2.0 # IP genérico de la red
ETH0MASK=24 # mascara de la subred
MYBOSS=10.10.2.53 # una maquina "confiable"
FRIEND=10.10.2.74 # otra maquina "confiable"
#
# Limpiar cualquier regla existente
#
ipchains -F input
ipchains -F output
ipchains -F forward
#
# Definir una regla
#
ipchains -A input -p tcp -j ACCEPT -s $MYBOSS -i eth0 -d 0.0.0.0/0 10000
#
# la línea anterior permite a mi jefe ingresar al webmin (puerto 10000)
# de las maquinas, las opciones en detalle son las siguientes:
# -A input agregar una regla a la cadena de entrada
# -p tcp se aplica a las conexiones tcp
# -j ACCEPT el tipo de regla
# -s $MYBOSS el origen (source) de la conexion
# -i eth0 la interface a la cual se aplica la regla
# -d 0.0.0.0/0 el destino de la conexión (red/netmask)
# 10000 el puerto afectado en los destinos (10000 = Webmin)
#
# Definir otra regla
#
ipchains -A input -p tcp -j ACCEPT -s $FRIEND -i eth0 -d 0.0.0.0/0 22
#
# esta regla permite las conexiones de la maquina FRIEND con otras
# maquinas utilizando un reemplazo seguro al telnet llamado SSH
# (Secure Shell). Veamos la línea en detalle:
# -A input agregar una regla a la cadena de entrada
# -p tcp se aplica a las conexiones tcp
# -j ACCEPT el tipo de regla
# -s $FRIEND el origen (source) de la conexión
# -i eth0 la interface a la cual se aplica la regla
# -d 0.0.0.0/0 el destino de la conexión (red/netmask)
# 22 el puerto afectado en los destinos (22 = SSH)
#
# Ahora denegamos otros accesos a los puertos 1 a 1023 por tcp
#
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1:1023
#
# -A input agregar una regla a la cadena de entrada
# -p tcp se aplica a las conexiones tcp
# -j DENY el tipo de regla
# -s 0.0.0.0/0 el origen (source) de la conexión
# -i eth0 la interface a la cual se aplica la regla
# -d 0.0.0.0/0 el destino de la conexión (red/netmask)
# 1:1023 rango de puertos afectados
#
# Y para completar denegamos acceso por udp
#
ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1:1023
#
# -A input agregar una regla a la cadena de entrada
# -p udp se aplica a las conexiones tcp
# -j DENY el tipo de regla
# -s 0.0.0.0/0 el origen (source) de la conexión
# -i eth0 la interface a la cual se aplica la regla
# -d 0.0.0.0/0 el destino de la conexión (red/netmask)
# 1:1023 rango de puertos afectados
Como se ve no es algo terriblemente fácil, pero tampoco es imposible.
Muchas de las opciones aquí mencionadas, así como las que mencionaremos, dependen de la configuración elegida al compilar el kernel. Se recomiendo leer los helps de las opciones utilizadas en la parte "Networking" de la compilación.
Ahora veremos algún caso ejemplo de firewalling con ipchains para diferentes servicios.
Enmascaramiento de IP
Esta funcionalidad suele utilizarse para permitir el acceso a Internet desde las máquinas de una LAN, pasando por un gateway. Configurando enmascaramiento en el gateway, el acceso desde las otras máquinas es completamente transparente y no necesita de proxies.
La idea detrás del enmascaramiento (IP masquerading) es que cualquier paquete proveniente de una máquina de la LAN que quiera salir a Internet, es reconstruido en el gateway para salir con la dirección IP del gateway. Cuando llega una respuesta el gateway la reconstruye y la envía a la maquina de origen.
Esto nos permite que nuestra LAN utilice direcciones IP privadas (por ej. 10.x.x.x) que están prohibidas en Internet, sin que puedan ser vistas "desde afuera". Un potencial atacante solo podría atacar nuestro gateway (que es donde deberemos esforzarnos con la seguridad).
Sintaxis utilizada:
ipchains -A forward -p all -j MASQ -s red_origen -d 0.0.0.0/0
telnet
La configuración de firewalling para telnet, si queremos habilitarlo desde la red local, sería la siguiente:
ipchains -A input -p all -j ACCEPT -s red_local -d 0.0.0.0/0 23
ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 23
La primer línea lo permite dentro de la red local, y la segunda bloquea cualquier otro acceso.
NIS / NIS+ / YP
Estos son servicios que permiten autenticar los usuarios contra una base de datos (/etc/passwd) remoto, alojada en un servidor. Obviamente es la solución a utilizar en una LAN de mediana a grande. NIS quiere decir Network Information Server, y es comúnmente llamado Yellow Pages (Páginas Amarillas), de ahí la sigla YP. NIS+ es una versión mejorada del NIS original.
Dado que estos servicios trabajan sobre el puerto 111 utilizando udp como protocolo, las reglas de firewalling con ipchains quedarían de la siguiente forma:
ipchains -A input -p udp -j ACCEPT -s red_local -d 0.0.0.0/0 111
ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 111
Nótese que siempre es conveniente poner una regla denegando cualquier otro acceso.
Una alternativa a NIS es un paquete llamado Kerberos, que trabaja de una forma similar a la utilizada por WinNT para autenticar usuarios. No es objetivo de este curso ver el paquete Kerberos, pero se menciona pues tiene una gran funcionalidad, y supera a NIS cuando se trata de administrar sites realmente grandes.
DHCP
DHCP significa Dynamic Host Configuration Protocol, y se utiliza para asignar direcciones IP en forma dinámica a los clientes de una red.
Dado que trabaja con protocolo udp en el port 67, la configuración con ipchains quedaría de la siguiente manera:
ipchains -A input -p udp -j ACCEPT -s red_local -d 0.0.0.0/0 67
ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 67
DNS
Domain Name Service, se utiliza para asignar los nombres a los hosts en forma dinámica, permitiendo la administración centralizada.
DNS corre en Linux como un paquete llamado Bind, y suele utilizar tanto el protocolo tcp como el udp. Por lo tanto podríamos configurar nuestra firewall así:
ipchains -A input -p all -j ACCEPT -s red_local -d 0.0.0.0/0 53
ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 53
O para mayor seguridad así:
ipchains -A input -p tcp -j ACCEPT -s red_local -d 0.0.0.0/0 53
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 53
ipchains -A input -p udp -j ACCEPT -s red_local -d 0.0.0.0/0 53
ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 53
Con lo cual excluimos el protocolo icmp, que no es utilizado por Bind.
SMTP
El firewalling de SMTP (Simple Mail Transfer Protocol) es sencillo, solo necesitamos saber que trabaja con protocolo tcp en el port 25.
ipchains -A input -p tcp -j ACCEPT -s red_local -d 0.0.0.0/0 25
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 25
Por si no lo recuerda, SMTP es utilizado por Sendmail.
Recuerde también que tiene alternativas mucho mas amigables que Sendmail a la hora de elegir un MTA (Mail Transport Agent), por ejemplo Qmail.
POP
POP significa Post Office Protocol, y se utiliza para recibir mails en su cliente. Actualmente se utiliza la versión llamada POP3, si bien existe alguna chance de encontrar un sistema viejo que utilice POP2.
POP utiliza el protocolo tcp y el port 110 (algunas versiones obsoletas utilizan el 109), por lo cual nuestra regla de firewall quedaría:
ipchains -A input -p tcp -j ACCEPT -s red_local -d 0.0.0.0/0 110
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 110
IMAP
IMAP es una versión avanzada y mejorada de POP.
Al margen de detalles técnicos, utiliza protocolo tcp en el puerto 153.
ipchains -A input -p tcp -j ACCEPT -s red_local -d 0.0.0.0/0 153
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 153
tftp
Trivial FTP es un protocolo altamente inseguro que permite transferencias ftp sin ningún tipo de autenticación de usuario.
Normalmente sólo se utiliza para el booteo de determinadas terminales bobas sin disco rígido, o durante una instalación en un entorno controlado.
No debe utilizarse en una red abierta.
NFS
Network File System es una aplicación que suele tener la configuración de seguridad dentro del seteo del NFS (/etc/exports) en forma de una lista de clientes desde los cuales se permitirá la conexión.
Es complicado de proteger con firewall, ya que utiliza adicionalmente los servicios RPC y mountd. En total se utilizan los siguientes protocolos y puertos:
NFS udp 2049
RPC udp/tcp 111
mountd udp 635
rsync
Este es un servicio muy utilizado para la creación y mantenimiento de mirrors.
Trabaja con protocolo tcp en el puerto 873.
ipchains -A input -p tcp -j ACCEPT -s red_local -d 0.0.0.0/0 873
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 873
lpd
Line Printer Daemon es el demonio que se encarga de la impresión tanto local como en red. Cuando se utiliza en red hace uso del protocolo tcp en el puerto 515.
ipchains -A input -p tcp -j ACCEPT -s red_local -d 0.0.0.0/0 515
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 515
SMB
Service Message Block es el protocolo utilizado por Samba para trabajar en redes mixtas Linux/Win.
Hace uso de los protocolos udp y tcp, en los puertos 137, 138 y 139, correspondientes a NetBIOS en el mundo Win.
ipchains -A input -p tcp -j ACCEPT -s red_local -d 0.0.0.0/0 137:139
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 137:139
ipchains -A input -p udp -j ACCEPT -s red_local -d 0.0.0.0/0 137:139
ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 137:139
A veces se utiliza una aplicación llamada SWAT para configurar Samba. Dicha aplicación no es muy segura (no encripta la información que viaja por la red). Hace uso del protocolo tcp en el puerto 901.
ipchains -A input -p tcp -j ACCEPT -s red_local -d 0.0.0.0/0 901
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 901
FTP
Este servicio, ya conocido, hace uso del protocolo tcp en el puerto 21.
ipchains -A input -p tcp -j ACCEPT -s red_local -d 0.0.0.0/0 21
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 21
NNTP
Este protocolo es utilizado por los servidores de News. Utiliza protocolo tcp en el puerto 119.
ipchains -A input -p tcp -j ACCEPT -s red_local -d 0.0.0.0/0 119
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 119
Con las últimas distribuciones de Red Hat viene el servidor INN, que no es precisamente lo último, sino mas bien uno de los primeros que existió.
SQUID
Squid es un servidor proxy presente en la distribución, permitiendo actuar como proxy para conexiones FTP y WWW.
La mayor parte de las configuraciones de seguridad de Squid deben hacerse dentro de la configuración del mismo paquete.
Desde el punto de vista de firewalling, Squid utiliza varios protocolos, usualmente en el puerto 3128.
ipchains -A input -p all -j ACCEPT -s red_local -d 0.0.0.0/0 3128
ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 3128
SNMP
Simple Network Management Protocol es utilizado hoy día para la administración de redes al nivel IP. Hay hardware que hace uso de este protocolo (routers Cisco) para su configuración.
Sin entrar en detalles, usa protocolo udp, y puertos 161 y 162.
ipchains -A input -p udp -j ACCEPT -s red_local -d 0.0.0.0/0 161:162
ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 161:162
NTP
Network Time Protocol. Utilizado para sincronizar la hora con algún servidor que se toma como referencia (usualmente algún Time Server de Internet, definidos exclusivamente para este fin y con relojes extremadamente precisos).
Utiliza protocolos udp y tcp en el puerto 123.
ipchains -A input -p tcp -j ACCEPT -s red_local -d 0.0.0.0/0 123
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 123
ipchains -A input -p udp -j ACCEPT -s red_local -d 0.0.0.0/0 123
ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 123
Finger
Permite obtener información sobre hosts remotos. Adicionalmente ha sido utilizado como entrada de algunos ataques DoS.
Nota: si puede evitarlo, no lo use.
Si no puede, usa protocolo tcp en el puerto 79.
ipchains -A input -p tcp -j ACCEPT -s red_local -d 0.0.0.0/0 79
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 79
Apache
La mayor parte de la configuración de seguridad se realiza dentro de la configuración del mismo paquete.
Adicionalmente puede utilizarse HTTPS, que encripta las conexiones.
Usualmente http trabaja con diversos protocolos en el puerto 80.
Si se utiliza https mediante, por ejemplo, el modulo SSL, se utilizan varios protocolos en el puerto 443.
Recuerde que en éste y en muchos otros casos los puertos por defecto pueden cambiarse, para no utilizar valores conocidos.
ipchains -A input -p all -j ACCEPT -s red_local -d 0.0.0.0/0 80
ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 80
ipchains -A input -p all -j ACCEPT -s red_local -d 0.0.0.0/0 443
ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 443
X Window
Aunque pueda sonar raro que hablemos de X Window en la sección de seguridad en redes, debemos recordar que el intercambio de datos entre el servidor X y el cliente ocurre a través de una red, si bien usualmente es nuestra red local de la estación de trabajo (127.0.0.1).
Al margen de la configuración de seguridad del paquete X en si, mencionaremos que para sus conexiones "vía red" suele usar los puertos arriba del 6000, según necesidad, con protocolo tcp. De ser necesario crear reglas de firewalling, podríamos definir la siguiente:
ipchains -A input -p tcp -j ACCEPT -s red_local -d 0.0.0.0/0 6000:6100
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 6000:6100
Sin embargo se recomienda leer atentamente la documentación de X, así como la manpage del comando xhost.
Limitando y monitoreando a los usuarios
Las ultimas distribuciones de Red Hat Linux utilizan una tecnología de autenticación basada en módulos configurables llamada PAM (Pluggable Authentication Modules).
Una de las ventajas del uso de PAM, es que se puede limitar la cantidad de procesos que un usuario puede tener corriendo simultáneamente. Si tomamos en cuenta que actividades "riesgosas" como escaneos y sobre todo compilación de programas suelen lanzar una gran cantidad de procesos hijos, es una buena forma de estar seguros que nadie intentara algo como esto.
La configuración se realiza sobre el archivo /etc/security/limits.conf, y puede ingresarse una configuración diferente para cada usuario. El archivo esta bien comentado y tiene un detalle de la sintaxis, que es como sigue:
* hard core 0
luis soft nproc 100
luis hard nproc 150
La primer línea inhabilita los core dumps para todos los usuarios.
Las dos líneas siguientes generan 2 limites (soft y hard) para la cantidad de procesos que puede correr simultáneamente el usuario luis.
El limite soft es un límite de aviso, puede ser excedido. En cambio el límite hard es un límite absoluto que no se excederá.
Para monitorear la actividad de los usuarios, además de los logs del sistema, tenemos en el home directory de cada usuario un archivo oculto .bash_history con los comandos tipeados en consola por el usuario.
Basado en un hecho real: teman lo peor si encuentran que el .bash_history de un usuario es un link a /dev/null.
Adicionalmente existen diversas herramientas en el mercado tanto para limitar como para monitorear la actividad de usuarios.
Documentación de referencia
Existen varios sitios que contienen información sobre seguridad en Linux, pero hay un portal que integra mucha de esta información: http://www.linuxsecurity.com
Una de las lecturas obligadas para el administrador interesado en seguridad es la Guía de Seguridad para el Administrador Linux (Linux Administrator Security Guide) que puede encontrarse en http://www.securityportal.com/lasg
Con esto finalizamos este breve (si, es breve) pantallazo sobre lo que puede modificarse para asegurar nuestro entorno Linux. La seguridad no tiene "recetas", hace falta analizar mucho cada situación, leer la documentación, hacer pruebas en entornos controlados, e implementar. Siempre hay tiempo de cambiar las cosas, y de esto se aprende. No tema demasiado. No son muchos los que pueden lograr acceso como root a un entorno medianamente bien configurado.
Como última recomendación, mantenga siempre actualizado su sistema. Muchas veces las nuevas versiones de software surgen porque corrigen problemas de seguridad en las anteriores.

Instalando un Servidor NIS
Para instalar un servidor NIS, entra como root o haz un su hacia root en el sistema usando como servidor NIS de ejemplo y haz lo siguiente:
1. Asegúrate de que el Sofware de NIS está instalado en tu sistema Linux. Necesitarás como mínimo los programas /bin/domainname/usr/sbin/ypserv, y /usr/lib/yp/ypinit. Si estos programas no se encuentran en tu sistema, carga los paquetes yserv e yp-tools desde tu CD de Red Hat o consíguelos desde un directorio de RPM e instálalos.
2. Después asegúrate de que el archivo /etc/passwd contiene una entrada para tu cuenta personal, que también debería encontrarse en el archivo de contraseñas en el sistema que configurarás como cliente NIS.
3. Asigna el nombre de dominio para tu nuevo dominio NIS. Esto no debería ser el mismo dominio que su dominio TCP/IP, con tal de evitar confundir al DNS, y comprometer potencialmente la seguridad de tu dominio. Para asignar el dominio NIS (en este caso el dominio fis.com), ejecuta el siguiente comando.
4. Arranca el proceso del servidor NIS con el siguiente comando:
/usr/sbin/ypserv.
5. Inicializa las bases de datos de NIS con un aomando como el que sigue:
/usr/lib/yp/ypinit -m.
Verás de salida el listado de los archivos que se hayan generado y hayan sido añadidos a la base de datos de NIS.
Esto es todo lo que hay que hacer. Tu nuevo servidor NIS está arriba y corriendo.
Configurando un minimo cliente NIS
Uno de mis dichos Zen favoriso es “Si un servicdor está corriendo y no hay clientes que los usen, ¿Está funcionando de verdad? Esta sección explica como montar un mínimo cliente NIS (del servidor inicializado en le sección previa de este cuadro) tras hacer alguna configuración inicial para ser capaz de verificar que el servidor esté haciendo “lo correcto”.
Con tal de hace alguna preconfiguración y verificar que el servidor está funcionando de verdad, entra como o haga su hacia root y edita el archivo /etc/nsswitch.conf en el sistema que estás usando como cliente NIS. Encuentra la línea que le dice al sistema como encontrar las entradas de contraseñas y modificala tal que tenga una pinta como.
Passwd: nis (NOTFOUND=return) files
Esto le dice a tu sistema que busque la información en NIS, y que falle si no es capaz de encontrarla.
Ahora, guarda una copia del archivo de contraseñas existente tras la entrada de halt. Añade lo siguiente como la última línea del nuevo y abreviado archivo de contraseñas.
+::::::
Después de hacer esto, debería parecerse al de la figura. Esto le dice a NIS que anexe los contenido del mapa de contraseñas.
Nótese que las entradas par las cuentas individuales han sido eliminadas del archivo abreviado de contraseñas. Esto nos posibilita hacer un simple test de para determinar si el NIS está funcionando; si eres capaz de entrar usuando una cuenta no presente en tu sistema cliente pero que está presente en tu archivo de contraseñas del servidor NIS, entonces NIS está funcionando correctamente.
root:0:0:root:/root/bin/bash bin:x:1:1:bin:/bin: daemon:x:2:2:daemon:/sbin: adm:x:3:4:adm:/var/adm: 1p:x4:7:1p:/var/spool/lpd sync:x:5:0:sync:/sbin:/bin/sync ahutdown:x:6:0:shutdown:/sbin:/sbin.shutdown halt:x:7:0:halt:/abin/halt +::::::










Para montar un mínimo cliente NIS, entra como o haga su hacia root en el sistema que estás usando como cliente NIS y haz lo siguiente:
Asegúrate de que el software cliente de NIS está instalado en tu sistema Linux. Como mínimo necesitas los programas /bin/domainname y bin/yp-bind. Otra vez, si estos programas no se encuentran en tu sistema, carga el paquete yp-tool de tu cd de Red Hat, ú obténgalos de un sitio de archivo de RPM e instálalos. Querrás utilizar muchas otras utilidades NIS en un entorno de desarrollo, pero estos dos programas son suficientes para nuestro simple test.
Asegúrate de que exista el directorio /var/yp y créalo si no.
Asigna el nombre de dominio NIS al que pertenece este nuevo cliente. Este debería ser el mismo al que hemos asignado en el cuadro anterior, así que ejecuta un comando como:
/bin/domainname foo.com
Comienza el proceso del cliente NIS como un comando como el siguiente.
Para verificar que el cliente NISestá funcionando correctamente, conéctate vía telnet desde el sistema cliente hacia el mismo e intenta entrar como tu usuario. Recuerda que tu entrada del archivo de contraseñas está presente en el archivo de contraseñas del servidor NIS pero no en el cliente.
Construcción automática de un DHCP
Introducción
El objetivo es presentar:
Un servidor DHCP (listo para detectar nuevos invitados en la red tales como gente que conecta su portátil y prueba jugar a juegos piratas)
Una pérdida de tiempo mínima.
Construcción de un DHCP en blanco
Nuestro primer paso es crear un fichero de configuración en blanco que sea capaz de aceptar a todos los clientes en la red.
Usaré aquí la configuración de red de la Slash Party #2 para la que probé a configuar un servidor Linux.
Opcion domain-name “slach2-100.party; Opcion domain-name 192.168.12.1; Opcion interface-mtu 1500; Subnet 192.168.12.0 netmask 255.255.255.0 # gateway por defecto opcion routers 192.168.12.1; opcion brcadcast-address 192.168.12.255; range 192.168.12.0 192.168.12.200; </fichero>

Una vez el servidor DHCP está funionando (después de usar dhcp start o un comando similar, según la distribución de Linux), se pueden iniciar estaciones cliente en la red.
Deben estar configuradas para obtener automáticamente una dirección IP.
Tan proto como los clientes pidan una dirección al servidor DHCP, se añadirá un bloque como este al fichero dhcpd.leases:
<fichero dhcpd.leases> lease 192.168.12.58 starts 2 1999/08/24 06:28:48; ends 3 1999/08/24 06:28:48; hardware etherne 00:10:5a:2e:56:a7; uid 01:00:10:5a;2e:56:a7 client-hostname “KLUSTER”; </bloque> lease 192.168.12.53 starts 2 1999/08/24 05:42:22; ends 3 1999/08/24 05:42:22; hardware etherne 00:80:ad:97:e1:76; uid 01:00:80:ad;97:e1:76 client-hostname “KLUSTER”; lease 192.168.12.54 starts 2 1999/08/24 03:47:26; ends 3 1999/08/24 03:47:26; hardware etherne 00:80:ad:97:e1:7d; uid 01:00:80:ad;97:e1:7d client-hostname “SDS”;



























lease 192.168.12.67 starts 2 1999/08/24 02:52:19; ends 3 1999/08/24 02:52:19; hardware etherne 00:50:04:45:e1:65; uid 01:00:50:04;45:e1:65 client-hostname “HOMER”; lease 192.168.12.64 starts 2 1999/08/24 01:26:05; ends 3 1999/08/24 01:26:05; hardware etherne 00:80:ad:97:e1:1c; uid 01: 00:80:ad:97:e1:1c; client-hostname “chAwArmA”;


Así pues, una vez que todos los clientes han obtenido una dirección IP del servidor, el fichero dhcpd.leases tendrá el siguiente aspecto:

lease 192.168.12.59 starts 2 1999/08/24 01:14:06; ends 3 1999/08/24 01:14:06; hardware etherne 00:00:21:2c:30:e7; uid 01: 00: 00:00:21:2c:30:e7; client-hostname “WOOKIE”; </fichero>


Seguridad en la configuración DHCP

A continuación, es necesario convertir nuestro DHCP “archivo” en uno estático y más seguro. Esto lo haremos usando el fichero dhcp.lease que acabamos de crear y convirtiéndolo en lo que he llamado un dhcp estático.

¿Cuál es la diferencia entre unb DHCP estático y uno abierto? En lo que nos concierne, un DHCO abierto permite a cualquier oerdenador conectado a la red obtener una dirección IP y el resto de parámetros de la red. Esto es un gran agujero en la seguridad, ya que cualquier pirata no autorizado puede conectarse fisicamente a la red y obtener parámetros de red correctos : ( Para contrarrestar tales ataques, usaremos el DHCP estático. Cada dirección IP sólo se da a clientes que tengan el Mac correspondiente al adaptador ethernet asociado. De esta manera es fácil destacar una instrucción.









<fichero dhcpd.conf> default-lease-time 86400; max-lease-time 604800; get-lease-hostname true; option subnet-mask 255.255.255.0; option domain-mask “slach2-100.party”; option domain-name-servers 192.168.12.1; option 1pr-servers 192.168.12.1; option interface-mtu 1500; subnet 192.168.12.0 netmask 255.255.255.0 # gateway por defecto option routers 192.1668.12.1; option broadcaast-address 192.168.12.255; # Those not in the disc # will get ip between .10 et .50 range 192.168.12.10 192.168.12.50 host hardware ethernet 00:10:5a:2e:56:7a; fixed-address “Kluster.slach2-100.party”; host hardeware ethernet 00:80:ad:97:el:76; fixed-address “ceddz.slach2-100.party”; host hardeware ethernet 00:80:ad:97:el:7d; fixed-address “sds.slch2-100.party”; host hardeware ethernet 00:40:95:49:0b:a5; fixed-address “saigneurslach2-100.party”; host hardeware ethernet 00:50:04:45:el:65; fixed-address “homer.slch2-100.party”; <file>





Atención: Sí no tienes un servidor DNS, el fichero dhcp.conf debe usar direcciones IP y no nombres de máquinas.







<extracto de dhcpd.conf sin dns> host hardeware ethernet 00:40:95:49:ob:a5; fixed-address “192.168.12.57”; host hardeware ethernet 00:50:04:45:el:65; fixed-address “192.168.12.67”; </extracto>


He escrito un pequeño script de perl que convierte el fichero dhcpd.leases en un fichero de configuración de dhcp estático.

Anexo
Zonas Desmilitarizadas (DeMilitarized Zones = DMZ)

Esta es una configuración particularmente útil de una red, que se utiliza para aumentar la seguridad en aquellos casos donde debamos brindar servicios tanto a nuestra LAN interna, como a Internet. Un ejemplo típico sería tener un servidor Apache con contenidos privados de Intranet, y una página de Internet de la empresa.
Armar esta configuración implica tener una máquina Linux que actúe como gateway, pero con 3 interfaces de red en lugar de 2, como usa un gateway estándar.

Primero un esquema de cómo quedaría la red:

INTERNET
|
|
GATEWAY----SERVIDORES
|
|
LAN

La idea es no correr ningún servicio en la máquina gateway, con lo cual evitamos tener puertos abiertos a posibles ataques. Tómese en cuenta que cualquier ataque originado en Internet sólo puede acceder directamente a la máquina gateway, y si corremos cero servicios es casi imposible ingresar.
En el gateway configuraremos ipchains para proteger a la LAN de cualquier dirección que no sea de la misma LAN, incluyendo cualquier servidor de la rama de la derecha.
Para poder configurar esto en ipchains es para lo que necesitamos tener 3 interfaces de red en el gateway.
En el gateway también configuraremos la seguridad de los servidores, permitiendo solamente el acceso a los servicios que se deseen, tanto para Internet como para la LAN. De esta forma si alguien intenta entrar en los servidores se verá forzado a hacerlo mediante algún xploit de los servicios que son brindados a Internet, mientras que otros servicios pueden permanecer privados, sólo para la LAN.
Y en el caso que alguien realmente logre entrar a los servidores, igualmente no podrá navegar la LAN, ya que la protegimos de los servidores mediante ipchains en la máquina gateway ;-)))
En el HOWTO de IPCHAINS hay información sobre DMZ.

General

Para usar IP-Masqueranding, necesitás al menos una máquina Linux con un Kernel 2.2.x. Esta máquina es la establecerá la conexión a internet. Que usemos Linux como sistema para compartir la conexión no significa que todos los ordenadores de tu red tengan que correr Linux. De hecho, Linux funciona bien con Windows, Mac, y otras variantes de Unix.
La máquina Linux conecta una parte a internet y la otra a tu red privada, por lo cual, al menos, tiene que tener dos interfaces con sus respectivas IP’s. Una de las direcciones IP es pública, lo que significa que es enrutable (puede viajar a travéz de internet) y normalmente asignada por tu proveedor de internet en el momento que se establece la conexión con el móden (o lo que sea que utilices). La otra dirección IP es privada (no rutable) y la puedes asignar de uno de estos rangos:

10.0.0.0 - 10.255.255.255
172.15.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255 (usaremos este rango en esta parte)
Este artículo tampoco explica como configurar tu red privada. Doy por hecho que ya tienes tu red en funcionamiento.

Fundamentos del IP-Masquerading

Básicamente, IP-Masqueranding traduce direcciones IP internas en direcciones IP externas. Este proceso se llama Traducciones de Direcciones de Red (NAT) y Linux hace esto mediante los llamados números de puerto. Desde el exterior, todas las conexiones parecen haberse originado desde tu máquina Linux.

Existen ciertas aplicaciones que generan paquetes IP de este tipo especial, en estos caso IP-Masqueranding podría no funcionar qunque la mayoría de las veces funciona. Hay módulos especícos que, insertados en Kernel, permiten a estas aplicaciones funcionar con IP-Masqueranding, este es el caso de ICQ, ftp y Quake. En general, Los que sólo usen http (navegadores Web), telnet, ssh o smtp (email) no tendrán ningún problema.Configurando el Kernel.

Configurando el Kernel

La gente que use algunas de la s principales distribuciones de Linux (Redhat, Mandrake, Debian Suse .....) pueden saltarse este capítulo, ya que su Kernel viene preparado para usar IP-Masqueranding.Normalmente suelo hacer backup de /usr/src/linux/.conf despuésde haber cumplido y probado un Kernel. La próxima vez que necesite compilar un Kernel simplemente cargo la configuración y ya tengo la configuración de mi Kernel anterior. Luego es relativamente sencillo configurar pequeños cambios, como los necesarios para IP-Masquerade.
Para usar IP-Masquerade responde Sí a los siguiente cuando configures el Kernel. Estos son solo los componentes que necesitas para IP-Masquerade, seelecciona cualquier otra opción que necesites para tu configuración específica.
Preguntar por código/drivers en desarrollo o/e incompleto
CONFIG EXPERIMENTAL
(Esto te permitirá seleccionaar código experimetal de IP-Masquerade compilado en el Kernel)
Habilitar soporte de módulos cargables
CONFIG_MODULES
Soporte de Red
CONFIG_NET
Firewalls de Red
CONFIG_ FIREWALL
Red de TCP/IP
CONFIG_INET
IP: firewalling/gatewaying
CONFIG_IP_FORWARD
IP: firewalling
CONFIG_IP_ FIREWALL
IP: masquerading
CONFIG_IP_MASQUERADE
IP:ipportfw masq support
CONFIG_IP_MASQUERADE_IPPORTFW
IP: ipautofw masquerade support
CONFIG_IP_MASQUERADE_IPAUTOFW
IP: ICMP masquerading
CONFIG_IP_MASQUERADE_ICMP
IP: desfragmentar siempre CONFIG_IP_ALWAYS_DEFRAG
Soporte del driver de red Dummy
CONFIG_DUMMY
IP: soporte Ipfwmark masq-forwarding
CONFIG_IP_MASQUERADE_MFW

Configurar IP-Masquerading

Vamos a escribir un pequeño script para autonatizar la configuración de IP-Masquerading. Debes poner el siguiente script en /etc/rc.d/init.d/ y llamarlo ipmasq.
Cambia los permisos con chmos 755 ipmasq para hacerlo ejecutable. El script de abajo asume que has usado la dirección IP estática 192.168.0.1 rn el interface que conecta a tu red interna (ifconfig eth0 192.168.0.1 netmask 255.255.255.0). Si has usado una dirección diferente modifica el script.

Ahora es el momento de cambiar tu configuración de forma que tu script /etc/rc.d/init.d/ipmasq se ejecute automáticamente cada vez que arranques la máquina Linux con IP-Masquerading. La mejor forma de hacer esto es editar el fichero /etc/rc.d/init.d/network (este fichero debería existir) y ejecutar /etc/rc.d/init.d/ipmasq AL FINAL de la sección start en el fichero init.d/network. Busca una expresión case y luego busca “start”.

#!/bin/sh
echo “configurando IP masqueerading...”
# la gente que todavía utilice windows para navegar tiene que
# convertir esto a un fichero de texto UNIX antes de utilizarlo.
#
# Soporte de maquerading para FTP
/sbin/modprobe ip_masq_ftp
#
# ------------------
# Nota: los modulos que siguen estan comentados de forma que no se cargaran.
# Quita el signo de comentario si qieres usar la aplicación correspondiente
# desde tu red interna.
#
# Soporte de masquerading para RealAudio sobre UPC.
# /sbin/modprobe ip_masq_raudio
#
# Soporte de masquerading para transferencia de ficheros IRC DCC
# /sbin/modprobe ip_masq_irc
#
# Soporte de masquerade para Quake y QuakeWorld
# Quake I / QuakeWorld (ports 26000 and 27000)
# /sbin/modprobe ip_masq_quake
#
# Quake I/II/III / QuakeWord (ports 26000, 27000, 27910, 27960)
#/sbin/modprobe ip_masq_ quake ports 26000, 27000, 27910, 27960
#
# Soporte de masquerading para software de video conferencia CuSeeme
# /sbin/modprobe ip_masq_ cuseeme
#
# Soporte de masquerading para software de video conferencia VDO-live
#/sbin/modprobe ip_masq_ vdo-live
#-----------------
# Importante: Habilita IP forwarding. Esta deshabilitado por defecto
# en los Kernels 2.2.x
echo “I “ > /proc/sys/net/ipv4/ip_forward
#
# NOTA: Esto es un ejemplo para la dirección de red interna
# 192.168.0.x La mascara de subred es 255.255.255.0 o “24” bit
# Modifica esto si utilizas una direccion interna diferente.
#
/sbin/ipchains -P forward DENY
/sbin/ipchains -A forward -s 192.168.0.0/24 -j MASQ
#
# ---fin del fichero

Antes de probarlo asegúrate de configurar todos los ordenadores en red privada de forma que su puerta de enlace (gateway) apunte a la dirección 192.1668.0.1 (la máquina Linux con IP- Masquerading). Luego ejecuta el sript como root en la máquina
Linux com IP-Masquerading. Después haz un ping desde una de las máquinas de tu red interna a una máquina de internet (p.e. ping 195.53.25.18)
Si esto funciona entonces IP-Masquerading está funcionando. Prueba también ping www.linuxfocus.org. Esto debería dar el mismo resultado que el ping anterior. Si no funciona comprueba el fichero /etc/resolv.conf en tus clientes. Debe existir en todos los ordenadores de tu red interna y tiene que contener los servidores DNS de tu proveedor de internet. Una vez que el ping funcione todo lo demás también funcionará. (p.e. navegación web).








Indice

Módulo VIII 1
(Servidores de seguridad en Linux) 1
Introducción 1
Primero lo primero: seguridad "física" 1
LILO: Primer punto de entrada 2
Eliminar el prompt "LILO:" y/o cambiar el tiempo de espera 2
Poner password al LILO 3
Borrado seguro de información 4
Passwords y archivos importantes del sistema 5
Algunos otros archivos importantes 6
Recordar muchos passwords 7
root es Dios 7
Wrappers: Seguridad en redes a nivel inetd 8
ipchains: Filtrado de paquetes (firewalling) 9
Enmascaramiento de IP 12
telnet 12
NIS / NIS+ / YP 12
DHCP 13
DNS 13
SMTP 13
POP 13
IMAP 14
tftp 14
NFS 14
rsync 14
lpd 14
SMB 14
FTP 15
NNTP 15
SQUID 15
SNMP 15
NTP 16
Finger 16
Apache 16
X Window 16
Limitando y monitoreando a los usuarios 17
Documentación de referencia 17
Instalando un Servidor NIS 18
Configurando un minimo cliente NIS 18
Construcción automática de un DHCP 20
Introducción 20
Construcción de un DHCP en blanco 20
Seguridad en la configuración DHCP 22
Anexo 23
Zonas Desmilitarizadas (DeMilitarized Zones = DMZ) 23
General 24
Fundamentos del IP-Masquerading 25
Configurando el Kernel 25
Configurar IP-Masquerading 26

Saludos

Sir Tingal0