Manual de Gestion de Servidores

Gestión de
Servidores
2
CARERRAS PROFESIONALES CIBERTEC

GESTION DE SERVIDORES 3
Índice Pag.
5
SEMANA 1 : RAID en Linux
21
SEMANA 2 : LVM en Linux
35
SEMANA 3 : TCP/IP Avanzado
51
SEMANA 4 : Seguridad en un servidor de correo
63
SEMANA 5 : Firewall en Linux
SEMANA 6 : Stateful Packet Inspection Firewall I 89
SEMANA 9 : Stateful Packet Inspection Firewall II 101
SEMANA 10 : Stateful Packet Inspection Firewall III 109
SEMANA 11 : Proxy Application Firewall I 123
SEMANA 12 : Proxy Application Firewall II 139
SEMANA 13 : Intrusión Detection Systems 147
SEMANA 14 Virtual Private Networks 161
CIBERTEC CARRERAS PROFESIONALES

4

SEMANA
1
RAID en Linux
TEMA
Configuración del software RAID en LInux
OBJETIVOS ESPECÍFICOS
• Comprender que es un RAID

• Conocer los tipos de RAID
• Instalación de herramientas par RAID MDADM
• Implementar el RAID por software en Linux
CONTENIDOS
• RAID por software en Linux

• Tipos de RAID soportados por LInux
• Configuración e implementación del RAID

6
1. ¿Qué es RAID?
En 1987, la Universidad de Berkeley (California), publicó un artículo

describiendo varios tipos de arrays de discos, acuñando en el proceso el
término RAID (acrónimo de Redundant Array of Inexpensive Disks).
Básicamente, la idea era combinar múltiples discos [duros] independientes y
pequeños en un array (o matriz) de disco capaz de alcanzar un rendimiento
superior al de un sólo disco grande y caro, en otros términos, se pretendía
hacer trabajar varios discos modestos como un disco profesional de alto
rendimiento. Adicionalmente, el array de discos aparece ante el sistema
como un disco lógico único.
El tiempo transcurrido entre errores (MTBF) para el array de discos es, en el
modelo teórico de la Universidad de Berkeley, igual al MTBF de un disco
individual dividido por el número de discos presentes en el array. Esto se
consigue alcanzando una cierta tolerancia a errores que pasa por guardar la
información redundante de varios modos.
En aquel documento original, también nacieron cinco tipos de arquitecturas
RAID: desde RAID-1 hasta RAID-5 fueron definidas entonces, cada una de
ellas proporcionando diferentes niveles de tolerancia a errores de disco y
rendimientos. Después de aquello, también se puso de moda el término
RAID-0 para designar los arrays de discos no redundantes.
Hoy en dia, algunos de los niveles RAID, originalmente, definidos
(concretamente, los niveles 2 y 3) son solo utilizados en sistemas muy
especializados (El RAID por software de Linux no los soporta). También, ha
ido apareciendo un nuevo nivel denominado "lineal", y se ha ido haciendo
frecuente esto de ver el nivel 0 combinado con el nivel 1, etc.

2. Niveles RAID
A continuación se indica una breve descripción de los niveles RAID que
soporta la capa de RAID por software de Linux. Gran parte de esto que
vamos a ver son sólo los fundamentos teóricos de los sistemas RAID.
El soporte RAID de Linux incorpora los siguientes niveles:
2.1. RAID 0: Disk Striping "La más alta transferencia, pero sin tolerancia
a fallos".
Conocido también, como "separación ó fraccionamiento/ Striping". Los
datos se desglosan en pequeños segmentos y se distribuyen entre varias
unidades. Este nivel de "array" o matriz no ofrece tolerancia al fallo. Al no
existir redundancia, RAID 0 no ofrece ninguna protección de los datos. El
fallo de cualquier disco de la matriz tendría como resultado la pérdida de los
datos y sería necesario restaurarlos desde una copia de seguridad. Por lo
tanto, RAID 0 no se ajusta, realmente, al acrónimo RAID. Consiste en una
serie de unidades de disco conectadas en paralelo que permiten una
transferencia simultánea de datos a todos ellos, con lo que se obtiene una
gran velocidad en las operaciones de lectura y escritura. La velocidad de
transferencia de datos aumenta en relación al número de discos que forman
el conjunto. Esto representa una gran ventaja en operaciones secuenciales
con ficheros de gran tamaño. Por lo tanto, este array es aconsejable en
aplicaciones de tratamiento de imágenes, audio, video o CAD/CAM, es
decir, es una buena solución para cualquier aplicación que necesite un
almacenamiento a gran velocidad, pero que no requiera tolerancia a fallos.
Se necesita un mínimo de dos unidades de disco para implementar

una solución RAID 0.

8
2.2. RAID 1: Mirroring "Redundancia. Más rápido que un disco y más

seguro"
Llamado, también "Mirroring" o "Duplicación" (Creación de discos en espejo).

Se basa en la utilización de discos adicionales sobre los que se realiza una
copia en todo momento de los datos que se están modificando. RAID 1 ofrece
una excelente disponibilidad de los datos mediante la redundancia total de los
mismos. Para ello, se duplican todos los datos de una unidad o matriz en otra.
De esta manera se asegura la integridad de los datos y la tolerancia al fallo,
pues en caso de avería, la controladora sigue trabajando con los discos no
dañados sin detener el sistema. Los datos se pueden leer desde la unidad o
matriz duplicada sin que se produzcan interrupciones. RAID 1 es una
alternativa costosa para los grandes sistemas, ya que las unidades se deben
añadir en pares para aumentar la capacidad de almacenamiento. Sin
embargo, RAID 1 es una buena solución para las aplicaciones que requieren
redundancia cuando hay sólo dos unidades disponibles. Los servidores de
archivos pequeños son un buen ejemplo.
Se necesita un mínimo de dos unidades para implementar una solución

RAID 1.
2.3. RAID 4: "Acceso Independiente con un disco dedicado a paridad."
Basa su tolerancia al fallo en la utilización de un disco dedicado a guardar la

información de paridad calculada a partir de los datos guardados en los
otros discos. En caso de avería de cualquiera de las unidades de disco, la
información se puede reconstruir en tiempo real mediante la realización de
una operación lógica de O exclusivo. Debido a su organización interna, este
RAID es especialmente indicado para el almacenamiento de ficheros de
gran tamaño, lo cual lo hace ideal para aplicaciones gráficas donde se
requiera, además, fiabilidad de los datos.
Se necesita un mínimo de tres unidades para implementar una

solución RAID 4.

La ventaja con el RAID 3 está en que se puede acceder a los discos de

forma individual.
2.4. RAID 5: "Acceso independiente con paridad distribuida."
Este array ofrece tolerancia al fallo, pero además, optimiza la capacidad del
sistema permitiendo una utilización de hasta el 80% de la capacidad del
conjunto de discos. Esto lo consigue mediante el cálculo de información de
paridad y su almacenamiento alternativo por bloques en todos los discos del
conjunto. La información del usuario se graba por bloques y de forma
alternativa en todos ellos. De esta manera, si cualquiera de las unidades de
disco falla, se puede recuperar la información en tiempo real, sobre la
marcha, mediante una simple operación de lógica de O exclusivo, sin que el
servidor deje de funcionar.
Así pues, para evitar el problema de cuello de botella que plantea el RAID 4
con el disco de comprobación, el RAID 5 no asigna un disco específico a
esta misión sino que asigna un bloque alternativo de cada disco a esta
misión de escritura. Al distribuir la función de comprobación entre todos los
discos, se disminuye el cuello de botella y con una cantidad suficiente de
discos puede llegar a eliminarse completamente, proporcionando una
velocidad equivalente a un RAID 0.
RAID 5 es el nivel de RAID más eficaz y el de uso preferente para las

aplicaciones de servidor básicas para la empresa. Comparado con otros
niveles RAID con tolerancia a fallos, RAID 5 ofrece la mejor relación
rendimiento-coste en un entorno con varias unidades. Gracias a la
combinación del fraccionamiento de datos y la paridad como método para
recuperar los datos en caso de fallo, constituye una solución ideal para los
entornos de servidores en los que gran parte del E/S es aleatoria, la

10
protección y disponibilidad de los datos es fundamental y el coste es un

factor importante. Este nivel de array es, especialmente, indicado para
trabajar con sistemas operativos multiusuarios.
Se necesita un mínimo de tres unidades para implementar una

solución RAID 5.
Los niveles 4 y 5 de RAID pueden utilizarse si se disponen de tres o más

unidades de disco en la configuración, aunque su resultado óptimo de
capacidad se obtiene con siete o más unidades. RAID 5 es la solución más
económica por megabyte, que ofrece la mejor relación de precio,
rendimiento y disponibilidad para la mayoría de los servidores.
3. Configuracion de RAID por software en Linux
En Linux raidtools ha sido el paquete de gestión de RAID por software

estandard en Linux desde la inclusión del driver RAID por software. Con los
años, raidtools ha demostrado un uso pesado, principalmente porque depende
de un fichero de configuración (/etc/raidtab) que es difícil de mantener, y
parcialmente por sus limitadas características. En agosto de 2001, Neil Brown,
un ingeniero de software en la Unviersity of New South Wales y un
desarrollador del kernel, lanzó una alternativa. Su paquete mdadm (multiple
devices admin) proporciona una forma simple y robusta de gestión de arrays
software. mdadm va por la versión 1.0.1 y ha demostrado ser muy estable
durante su primer año de desarrollo. En la lista de correo Linux-raid ha recibido
una cálida acogida y con probabilidad consiga una mayor difusión en el futuro.
3.1. Instalación
Descargue la versión más reciente del tarball mdadm, ejecute make install para
compilarlo e instalar mdadm con su documentación. Además del binario, se
instalan algunas páginas de manual y ficheros de ejemplo.

De forma alternativa usted puede descargar e instalar el fichero del paquete

que se encuentra bajo el directorio RPM en la misma URL
(http://www.cse.unsw.edu.au/~neilb/source/mdadm/).
mdadm tiene cinco modos de funcionamiento. Los primeros dos modos, Create
y Assemble, se utilizan para configurar y activar arrays. Manage se utiliza para
manipular dispositivos en un array activo. Follow o Monitor permite a los
administradores configurar la notificación de eventos y acciones para los
arrays. El modo Build se utiliza cuando se trabaja con arrays heredados que
utilizan una versión antigua del driver md.
3.2. Generacion de particiones y formación del arreglo RAID 1 (Raid

Espejo)
I. Esquema:
Se requiere que en un disco este asignado a los datos y que tenga

un espejo en otro disco.
II. Discos:
Nota: De los discos a incorporarse lo particionaremos en una sola

partición y del tipo RAID, luego el arreglo se formateara del tipo ext3.
Disco Particion Tamaño Tipo

#2 /dev/hdb1 200 Mb RAID
#3 /dev/hdd1 200 Mb RAID
III. Particionando discos:
Utilizaremos el comando “fdisk” para Particionar los discos:

12
: n Añadir una nueva partición
: p seleccionar partición
Numero de Particion (1-4): 1
Aceptar el PRIMER CILINDRO: <ENTER>
ULTIMO CILINDRO: <ENTER>
: t (Cambiando el tipo de Filesystem al tipo RAID)

Tipo: fd (Linux Raid autodetect)
:wq salir de fdisk.
Realizar el mismo proceso para /dev/hdd:
# fdisk /dev/hdd
IV. Generando el Arreglo RAID 1:

Nombre del Num. De Dispositivo
Usando el comando “mdadm”: dispositivo SCSI que conforma el Raid
Particiones que Nivel del Raid

conforman el arreglo
mdadm: size set to 208512

mdadm: array /dev/md0 started
Visualizando estado:

V. Integrando el Arreglo RAID 1 al sistema de archivos:
• Formateando Raid del tipo Ext3
• Creando punto de montaje: #mkdir /info
• Realizando el montaje: mount /dev/md0 /info
• Visualizando los punto de montaje: # df

14
• Crear algunos archivos y directorio en “/info”
VI. Activacion Permanente:
Luego de comprobar que en el directorio “/info” esta almacenando

información. Ahora, debemos de personalizar los archivos de
configuración para su activación automática.
• Archivo de configuración de “mdadm”:

El archivo de configuración de “mdadm.conf” posee una estructura,
“mdadm” puede tomar información del RAID formado, manualmente,
y obtener la información que se ingresaría en el archivo de
configuración “mdadm.conf”
Visualizando la información:
Enviando la información al archivo “mdadm.conf”:
Personalizando “mdadm.conf”: #vi /etc/mdadm.conf

DEVICE, indica todas
las particiones que serán
parte del arreglo
ARRAY, Indica el tipo

de arreglo formado
(level) un identificador
generado (UUID) y los
dispositivod que lo
conforman (devices).
* Es una línea
continua
Personalizando “fstab” para el punto de montaje:
#vi /etc/fstab
Agregar la siguiente línea:

/dev/md0 Nombre del dispositivo
/info Punto de montaje
Ext3 Tipo de filesystem
Defaults opciones de activación por defecto: Lectura, Escritura.
1 3 Activar:1 Orden del Scandisk:3 (tercero)
• Guarde los cambios.

• Reinicie Linux
• Comprobar que el RAID esta operativo: # cat /proc/mdstat
• Visualice que el punto de montaje “/dev/md0” esta activado: # df
• Compruebe la información del directorio “/ info” y genere nuevos
archivos y directorios.
VII. Monitoreo.
Personalizando para recibir mensajes:
Creando cuenta de usuario:
Usuario Password
Monitor Monitor
• # adduser monitor
• # passwd monitor
Prueba de envio de correo:

• # /bin/mail -s “prueba” monitor < /dev/null
Visualizando el correo recepcionado: # cat /var/spool/mail/monitor

16
Ejecutando “mdadm” para que cense cada 10 segundos e envie la alerta

a la cuenta monitor:
Genera Proceso Cuenta a enviar mensaje
VIII. Simulacion de Caida:
Ejecutando “mdadm” para simular la caída del disco hdb1:
Comprobando el estado fallido del raid: # cat /proc/mdstat
Comprobando el envio de alerta: # cat /var/spool/mail/monitor

• Compruebe que la data del directorio “/ info” se mantiene:

• Genere nuevos archivos en “/ info”
IX. Restaurando Disco:
Ejecutando “mdadm” para restaurar el disco hdb1:
Visualizando el estado operativo: # cat /proc/mdstat
La data del directorio “ /info ” se mantiene (referencial):

18

Autoevaluación
1. Indique los tipos de RAID que existen y que son soportados por el
software de Linux
2. ¿Indique las diferencias en raidtools y mdadm?
3. ¿Cómo crea un RAID 0 en Linux?
4. ¿Cómo crea un RAID 5 en Linux?

20

SEMANA
2
Logical Volumen Manager
en Linux
TEMA
Manejo e implementación del Logical Volumen Manager (LVM) sobre Linux
• Entender el servicio de LVM

• Preparacion de discos para el manejo de LVM
• Physical Volumen
• Volumen Groups
• Logical Voluemn
CONTENIDOS
• ¿Qué es LVM?
• Configuracion de LVM
• Creacion de Physical Volumen
• Creacion de Volumen Group
• Creacion de Physical Volumen

22
1. LVM (Logical Volumen Manager)
LVM es el administrador de volúmenes lógicos para el kernel Linux. LVM

gestiona los discos duros y sistemas similares, como dispositivos de
almacenamiento masivo. Entre las características principales del Linux
Logical Volume Manager encontramos el redimensionado de grupos
lógicos, redimensionado de volúmenes lógicos, capacidad de realización de
snapshots en modo lectura, adición de nuevos discos a los volúmenes, etc.
Se podría decir que LVM es un mecanismo para “virtualizar” discos.
LVM es mucho más flexible, permitiendo añadir espacio adicional a

volúmenes ya creados de manera transparente y simple.
Pasamos a ver los conceptos para entender la base del sistema.
volume group (VG): Sería el equivalente a un disco duro, es el punto de

abstracción más alto en LVM. Puede contener volúmenes físicos y lógicos.
physical volume (PV): Puede ser un disco duro, aunque también algo que
se le parezca como un RAID por software.
logical volume (LV): Equivale a una partición, contiene su propio sistema

de archivos.
physical extent (PE): La extensión física está compuesta por trozos de

datos de los volúmenes físicos.
logical extent (LE): La extensión lógica está compuesta por trozos de datos de
los volúmenes lógicos.

Para que todo funcione, es necesario instalar el paquete lvm10 o lvm2,

recomiendo la versión 2 aunque la mayoría de distribuciones todavía
mantengan la versión 1. Hay que asegurarse de que haya un script en el
arranque para poner en marcha LVM.
Lo primero de todo es hacer las particiones, puede hacerse con cfdisk. Si se

usa una versión anterior a la 2 de LVM, es obligatorio definir el tipo como Linux
LVM.
Cada una de la particiones usadas debe ser etiquetada con Linux LVM etiqueta
8e

24
Antes de poder comenzar a trabajar con los discos en LVM (creando grupos,
volumenes, particionando, etc) hemos de “prepararlos” para poder utilizar este
sistema. Para ello, utilizaremos fdisk, especificando a cada uno de los discos
que queremos utilizar con LVM que utilicen el tipo de partición 8e “Linux LVM”.
Supongamos que tenemos un disco duro nuevo, /dev/sda, vamos a prepararlo

para utilizar LVM, ejecutamos fdisk sobre el disco para ello:
fdisk /dev/hdb
Una vez dentro, presionamos “n” para crear una nueva partición:
n Añade una nueva partición
Presionamos “p” para crear una nueva partición primaria
p Partición primaria (1-4)
Presionamos 1 para crearla como la primera partición del disco,

posteriormente, presionamos ENTER hasta aceptar todos los valores por
defecto de primer y último cilindro.
Una vez finalizado y de nuevo en el menú de fdisk, presionamos “t” para

cambiar el identificador de sistema de una partición:
t Cambia el identificador de sistema de una partición
La cambiaremos al tipo “LVM partition type (0×8e)”, para ello, introducimos

8e. Podemos en este punto presionar “p” para imprimir la tabla de particiones y
ver que todo es correcto:
p Imprime la tabla de particiones
Finalmente, guardamos los cambios con “w”
Al hacer un fdisk -l del nuevo disco, veremos que, efectivamente, ya utiliza

LVM, ejemplo (ficticio):
# fdisk -l /dev/sda
Disk /dev/sda: 200.0 GB, 201000193024 bytes

200 heads, 63 sectors/track, 30515 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Start End Blocks Id System
/dev/sda1 1 30515 205111706 8e Linux LVM

2. Configuracion de LVM
2.1. Creacion de physical Volumen

Para la creación de physical volumens, se usa el comando pvcreate
El comando pvdisplay nos muestra todos los physical volumen del

Sistema.
Alternativamente, se puede usar el siguiente comando

26
2.2. Creacion de Volumen Group

A este nivel, ya se puede crear un volumen group, el cual es un contener
de todos lo physical volumen que se incluyan en su creación.
A continuación, se crea el volumen group cibertec con un solo physical

volumen /dev/sdb1
Para incluir 2 physical volumen a la vez, se ejecuta el comando
Para listar todos lo volumen groups que existen en el sistema se ejecuta

vgdisplay

En la pantalla anterior, se puede observar por ejemplo que existen 2

volumen groups, ciberlinux y cibertec, de los cuales se indica que
ciberlinux, esta formado con 2 physical volumen y cibertec esta formado
con 1 physical volumen (Propiedad metadata area).
Para agregar un nuevo physical volumen a un volumen group,

previamente, creado se usa el comando:

28
2.3. Creacion de Logical Volumen

A este nivel, se puede cortar el volumen group en piezas más pequeñas
llamadas Logical Volumen, los cuales son tratados como particiones
dentro del sistema operativo Linux.
Para crear un Logical Volumen llamado prueba01 de 100MB en el

volumen group cibertec, se ejecuta el siguiente comando:
Listando el logical volumen
Revisando el espacio libre que queda en el volumen group cibertec

Para crear un Logical Volumen llamado prueba02 de 300MB en el

volumen group ciberlinux se ejecuta el siguiente comando:
Listando el logical volumen
Revisando el espacio libre que queda en el volumen group ciberlinux

30
2.4. Creacion de un filesystem en un Logical Volumen

Para poder usar los logical volumen que hemos creado, hay que,
previamente, crear los filesystem.
Creado el filesystem en el volumen group prueba01
Creado el filesystem en el volumen group prueba02

2.5. Montando lo nuevos filesystems

Una vez que se tiene los filesystem, estos se pueden archivar en una
carpeta para poder usarlos.
Montado prueba01 en la carpeta /música
Montado prueba02 en la carpeta /videos
Revisando los filesystem
2.6. Agregando los filesystem en el /etc/fstab

Si se desea que estos nuevos filesystem se monten de forma automática
cuando se inicia el sistema operativo, se deben agregar las entradas en
el /etc/fstab

32
2.7. Extendiendo un logical Volumen

La gran ventaja de LVM, es que puede incrementar el tamaño en
cualquier momento cuando se encesite espacio y esto se puede hacer
en caliente.
Para aumentar el tamaño del logical volumen prueba01 hasta 500MB
Se ve que originalmente tiene 100MB
Extendiendo el tamaño a 500MB
Sin embargo, el filesystem no ha crecido
Para que el filesystem crezca, se debe ejecutar el comando: resize2fs

2.8. Eliminando un logical volumen

Para eliminar un logical volumen, se utiliza el comando lvremove
2.9. Eliminando un volumen group

Para eliminar un volumen group, se utiliza el comando vgremove
2.10. Eliminando un physical volumen

Para eliminar un physical volumen, se utiliza el comando pvremove

34
Autoevaluación
1. Indique qué es el Logical Volumen Manager, para qué sirve y qué

ventajas tiene.
2. Explique los conceptos de Physical Volumen, Volumen Group y Logical

Volumen
3. ¿Cómo crearía un Volumen group con los discos /dev/sdb1, /dev/sdc1 y

/dev/sdd1?
4. ¿Cómo añadir el physical Volumen /dev/sde1 y /dev/sdf1 al volumen

group anterior?

SEMANA
3
TCP/IP Avanzado
TEMA
Identificar y analizar los detalles avanzados acerca del protocolo TCP/IP.
• Entender el protocolo TCP/IP

• Identificar los protocolos ARP e ICMP
• Comprender la estructura de las cabeceras IP, TCP y UDP
• Comprender el saludo de tres vías
• Identificar parámetros de seguridad aplicados a la interface de red
CONTENIDOS
• Protocolo TCP/IP
• Address Resolution Protocol (ARP)
• Internet Control Messages Protocol (ICMP)
• Cabecera IP
• Cabecera TCP
• Cabecera UDP
• Saludo de tres vías (Handshake)
• Seguridad TCP/IP

36
PROTOCOLO TCP/IP
Fig. 1. Modelo TCP/IP
• Aplicación – Las aplicaciones TCP/IP, usualmente, incluyen un

programa cliente y servidor.
o Interface de usuario
o Proporciona aplicaciones específicas entre dos hosts.
• Transporte – Mantiene la integridad de los datos y configuración de

confiable en la comunicación punto a punto entre los sistemas. Asegura
la entrega libre de errores de las unidades de datos, en adecuada
secuencia, y sin pérdidas o duplicación.
• Internet – Encamina los paquetes entre diferentes hosts o redes.
• Interfase de red – Define la interconexión física entre los hosts.
Los estándares TCP/IP son publicados en los Request for Comments, que
se clasifican en:
• Requerido (Required)
• Recomendado (Recommended)
• Electivo (Elective)
• Uso limitado (Limited use)
• No recomendado (Not Recommented)
Entidades estandarizadoras:
• Internet Society - http://www.isoc.org/

• Interactive Advertising Bureau (IAB) - http://www.iab.net/
Fig. 2. Pasando los datos a través de la pila de protocolos del Modelo TCP/IP
3. Address Resolution Protocol (ARP)

Para que dos hosts puedan comunicarse, deben conocer sus direcciones
físicas (Media Access Control – MAC). A través de la difusión, ARP permite
a un host descubrir, dinámicamente, la dirección MAC correspondiente a
una dirección IP en particular.
Fig. 3. Cabecera ARP
• HLEN – Longitud dirección hardware

• PLEN – Longitud dirección del protocolo
• OPERACION – Código de operación (ARPreques ó ARPreply)
• SENDER HA – Dirección de origen hardware

38
• SENDER IP – Dirección de origen del protocolo

• TARGET HA – Dirección de destino hardware
A continuación, se muestra la captura de paquetes ARP con el programa

Wireshark (sniffer).
Fig. 4. ARP
2.1. Visualizar la dirección MAC:
En sistemas tipo Unix (Linux, FreeBSD, AIX, etc.) se ejecutará el

comando ifconfig para conocer la información relacionada con las
interfaces de red, donde aparecerá listada la dirección MAC
correspondiente a cada una.
2.2. Cambiar la dirección MAC:
Bajo Linux, la dirección MAC de un interfaz de red (NIC) puede ser

cambiada, ejecutando lo siguiente como usuario root:
ifconfig eth0 down

ifconfig eth0 hw ether 00:01:02:03:04:06
Ifconfig eth0 up
NOTA: El ejemplo está planteado con una interfaz ethernet de ahí que
sea la interfaz eth0.

En Red Hat Linux y distribuciones similares (Fedora Core, CentOS,

etc.) una manera sencilla de hacerlo "permanente", aun después de
reiniciar el sistema, es agregando una variable como esta a tu ifcfg-
eth0 o archivo similar:
MACADDR=12:34:56:78:90: ab
Resta reiniciar el servicio de red: service network restart para que se

apliquen los cambios.
Fig. 5. Comando ARP
Si deseamos un mayor control sobre la MAC podemos usar el

programa GNU Mac Changer, que no solo permite cambiar la MAC,
sino también listar las direcciones asignadas a los fabricantes, asignar
MAC aleatoria, etc.
En MAC-48 y EUI-48 las, direcciones se demuestran, generalmente,

en formato hexadecimal con cada octeto separado por un guión o dos
puntos. Un ejemplo de una dirección MAC-48 sería "00-08-74-4C-7F-
1D"; otro ejemplo, "00:08:74:4C:7F:1D".
RARP (Reverse Address Resolution Protocol) – Asocia una dirección IP a

una dirección MAC, es decir, es el proceso inverso. El cual es utilizado en
estaciones que no tienen disco y no tienen dirección IP cuando son
activadas.

40
4. Internet Control Messages Protocol (ICMP)

ICMP es utilizado cuando un router o host debe informar al host o router
origen acerca de errores en el procedimiento de los paquetes.
No está diseñado para ser absolutamente confiable. El propósito de ICMP

es proveer retroalimentación acerca de problemas en el ambiente de
comunicación.
Fig. 6. Cabecera ICMP
Esta cabecera tiene los siguientes campos:
• Tipo – Campo de 8 bits que identifica el tipo de paquete.
• Código – Campo de 8 bits que especifica el tipo de paquete ICMP.
• Suma de verificación – Campo de 16 bits de código de chequeo de error

referido a la cabecera ICMP.
ICMP es, aparentemente, un protocolo simple; sin embargo, puede ser

utilizado con propósitos destructivos.

Fig. 7. ICMP – Comando ping
Fig. 8. ICMP – Comando tcpdump
5. Cabecera IP
La cabecera IP se muestra en la Fig. 5. Tiene una longitud predeterminada
de 20 bytes. Si existen opciones habilitadas, se agregan hasta 4 bytes
adicionales.
Esta cabecera tiene los siguientes campos:

• Versión – Campo de 4 bits que identifica la versión IP utilizada. Por
defecto, es 4, IPv4.

42
• Longitud de la cabecera – Campo de 4 bits.

• Tipo de servicio – Campo de 8 bits dónde se especifica como los
protocolos de capa superior serán manejados y se asignan diferentes
niveles de importancia como:
o Precedencia
o Retardo minimizado
o Máxima transferencia (throughput)
o Máxima fiabilidad (Reliability)
o Minimizar el costo monetario
o Reservado
• Longitud Total – Campo de 16 bits que indica el tamaño máximo del

paquete en bytes.
• Identificación – Campo de 16 bits que indica el número de identificación
del paquete IP.
• Flags – Campo de 3 bits dónde los 2 bits de menor orden controlan la
fragmentación y el de mayor orden no es utilizado.
o Reservado
o No fragmentado
o Más fragmentos
• Orden de los Fragmentos – Campo de 13 bits que indica la posición del
dato fragmentado respecto al inicio de los datos en el paquete original.
• Tiempo de Vida – Campo de 8 bits que mantiene un contador que
decrece por cada salto y, si llega a cero el paquete, es descartado.
• Protocolo – Campo de 8 bits que identifica el protocolo de la capa de
transporte que sigue a continuación.
Fig. 9. Cabecera IP
• Suma de verificación – Campo de 16 bits de código de chequeo de error

referido a la cabecera IP para aseguramiento de integridad de la
cabecera IP.
• Dirección Origen – Campo de 32 bits que indica la dirección origen.
• Dirección destino – Campo de 32 bits que indica la dirección destino.

• Opciones – Permite a IP soportar varias opciones, tales como Loose

source Routing, Strict Source Routing, Record Route y Timestamp.
6. Cabecera TCP
El protocolo TCP es seleccionado cuando las aplicaciones y servicios
trabajan con sesiones orientadas a la conexión (garantiza la entrega de los
datos).
Los campos TCP son:
• Puerto Origen – Campo de 16 bits que identifica el puerto origen

utilizado en la sesión.
• Puerto destino – Campo de 16 bits que identifica el puerto destino
utilizado en la sesión.
• Número de secuencia – Campo de 32 bits que identifica dónde
corresponden los datos encapsulados dentro de una cadena de datos
que vienen desde el emisor.
• Número de acuse de recibo – Campo de 32 bits que identifica el
siguiente número de secuencia que la fuente espera recibir desde el
destinatario. Con este valor se controla la secuencia y la perdida de
paquetes.
• Longitud de la Cabecera – Campo de 4 bits que indica cuantas palabras
(32 bits) hay en la cabecera TCP.
• Reservado – Campo de 6 bits que siempre está en cero no utilizados por
ahora.
Fig. 10. Cabecera TCP
• Flags – Campo de 6 bits que corresponden a los indicadores de estado

de sesión:
o URG. Urgente

44
o ACK. Acuse de Recibo

o PSH. Push
o RST. Reset
o SYN. Sincronizado
o FIN. Final
• Tamaño de la ventana – Campo de 16 bits utilizado para el control de
flujo. Especifica el número de octetos empezando con el octeto indicado
por el número de reconocimiento que el emisor del segmento acepta a
su par en el otro extremo de la conexión, antes que su par deje de
transmitir y espera por un reconocimiento.
• Suma de verificación – Campo de 16 bits que verifica la integridad d ela
cabecera TCP.
• Puntero urgente – utilizado, únicamente, cuando el flag URG está en
uno.
• Opciones – Diseñado para contar con características extras no cubiertas
en la cabecera estándar.
7. Cabecera UDP
EL protocolo UDP es utilizado por aplicaciones y servicios que trabajan con
sesiones no orientas a la conexión pero cuyo tamaño es menor que el
protocolo TCP.
El protocolo de transporte UDP es utilizado cuando en el campo puerto de

la cabecera IP el valor es 17 (11H). Tiene los mismos campos que en el
caso de TCP, pero sólo tiene los campos puerto origen y destino, longitud
de la cabecera y suma de verificación.
Fig. 11. Cabecera UDP
8. Saludos de tres vías (Handshake)

Es el proceso de establecimiento de una sesión entre dos hosts a nivel de
la capa de trasporte. Se describe en tres pasos:
Paso 1 – Envía un paquete de sincronización (SYN) y un número

de secuencia inicial (ISN).
La máquina cliente (Host A) desea establecer una conexión hacia el
servidor (Host B). La máquina cliente (Host A) envía un paquete hacia la

maquina servidor (Host B) con el bit de sincronización (SYN), establece

el anuncio de una nueva conexión y un número de secuencia inicial
(ISN) que permitirán rastrear los paquetes enviados a cualquier
máquina. (Ver Fig. 12)
Fig. 12.
Paso 2 – Permite que la máquina remota responda con un

reconocimiento (ACK).
La máquina servidor (Host B) responde al pedido enviando un paquete
con el bit de sincronización (SYN) y el bit ACK establecido en el
paquete hacia el llamado de la maquina cliente (Host A). Este paquete
no solo contiene el numero de secuencia de solicitud de respuesta del
cliente; también, el número de secuencia inicial más uno (ISN+1). Esto
indica que el paquete remoto se recibió, correctamente, como parte del
reconocimiento y se aguarda la próxima transmisión. (Ver Fig. 13)
Fig. 13.
Paso 3 – Completa la negociación para enviar un final de

reconocimiento hacia la maquina remota.
En este punto, la máquina cliente (Host A) envía la siguiente parte final
del reconocimiento (ACK) y el número de secuencia para indicar una
recepción satisfactoria y se establece la conexión. (Ver Fig. 14).
Fig. 14.
A continuación, se muestra la captura de paquetes con el programa

Wireshark (sniffer). Se puede observar el saludo de tres vía de una sesión
TCP.

46
Fig. 15. Handshake
9. Seguridad TCP/IP
En Linux, muchas opciones del kernel están relacionadas con la seguridad

de la red, como descartar paquetes que ingresan a través de la interface de
red o ignorar solicitudes ping, etc. Esto se puede establecer en el archivo
/etc/sysctl.conf en vez del archivo /etc/rc.d/rc.local. Las colocaciones de
sysctl se guardan en /etc/sysctl.conf y son cargadas hacia cada inicio del
sistema o reinicio del servicio network antes de cargar el archivo
/etc/rc.d/rc.local.
Para visualizar todo los valores sysctl actualmente disponible, use el

comando (Ver Figura 16):
Sysctl -a

Figura 16. Comando sysctl
Después de cualquier cambio en el archivo /etc/sysctl.conf, los parámetros

del kernel serán modificados en tiempo real al ejecutar el siguiente
comando:
Sysctl –p /etc/sysctl.conf
De inmediato, se explica el procedimiento a seguir para habilitar o

deshabilitar parámetros que son necesarios para proteger su sistema Linux:
Prevenir al sistema que responda solicitudes ping

Prevenir que tu sistema responda a solicitudes ping puede hacer mejorar
en forma considerable la seguridad de tu red, dado que nadie puede
hacer ping a tu servidor y recibas solamente respuesta a tus solicitudes.
La suite del protocolo TCP/IP tiene varias debilidades que permite que
un atacante use técnicas ocultas que le permitan interferir el envío de
los datos que se remiten bajo la forma de paquetes inofensivos.
No responder hacia solicitudes de comandos ping que son enviados por

la mayoría de "crackers" que se encuentra en Internet, ya que de esta
manera no se sabrá si estamos allí.
net.ipv4.icmp_echo_ignore_all=1
NOTA: Existe otra manera de actualizar sin reiniciar el servicio de red

(network) ejecutando el comando sysctl en una consola de la siguiente
manera:
Sysctl –w net.ipv4.icmp_echo_ignore_all=1

48
Rechazar a responder a solicitudes broadcast

Cuándo un paquete es enviado a una dirección IP de transmisión o
difusión de mensajes (broadcast), como por ejemplo la dirección IP
192.168.1.255 de una máquina en la red local, este paquete es
entregado a todas las máquinas de esta red. Entonces, todas las
máquinas de la red responden a este pedido de mensaje ICMP (hecho
de hacer o echo del verbo echar request) y el resultado es que se
producirá una congestión severa de la red o ataques de Denegación de
Servicio.
net.ipv4.icmp_echo_ignore_broadcats=1
Encaminar Protocolos
Encaminar y dirigir los protocolos pueden crear varios problemas.

Encaminar el origen de una IP, en donde un paquete IP contiene
detalles de la ruta hacia su destino, es peligroso porque, según RFC
1122, la máquina destino debe responder por la misma ruta
Si un atacante puede encaminar el origen de un paquete dirigido a tu
red, entonces él sería capaz de interceptar las contestaciones y engañar
a tu servidor pensando que se comunica con un servidor de confianza.
Se recomienda que deshabilites encaminar el origen de los paquetes IP

en todas las interfaces de red habilitadas en tu sistema para proteger a
tu servidor de estos ataques.
Como ejemplo, se tiene una máquina con dos interfaces de red (lo y
eth0) que están activas y se procederá a configurar el sistema para que
no encamine el origen de paquetes IP en todas las interfaces de red.
net.ipv4.conf.all.accept_source_route=0
net.ipv4.conf.lo.accept_source_route=0
net.ipv4.conf.eth0.accept_source_route=0
net.ipv4.conf.default.accept_source_route=0
Habilitar la Protección de Cookie TCP SYN

Un "Ataque SYN" es una negación de servicio (DoS) que consume todos
los recursos en su máquina, forzando a reiniciar tu sistema. Las
negaciones de ataques de servicio son ataques que incapacitan a tu
servidor debido a un alto volumen de negociación consumiendo recursos
del sistema, de tal modo que el servidor no pueda responder a un pedido
legítimo.
net.ipv4.tcp_syncoockies=1
Deshabilitar ICMP redirigidos

Un ICMP redirigido se emplea para avisar al receptor que tiene que
omitir alguna información de su tabla de rutas. Normalmente, se emplea
para informar que una ruta no es óptima y cuál es la nueva ruta a seguir.
Esta opción posibilita a un atacante alterar la tabla de rutas de su
máquina Firewall a sus necesidades.

net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.lo.accept_redirects=0
net.ipv4.conf.eth0.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0
NOTA: Si el kernel es configurado para una máquina regular, se

establece por defecto “yes” para este parámetro en caso de ser
aceptado y “no” debe ser cuando se hace configuración de
enrutamientos. Donde “ 1 ” significa yes, y “ 0 “ significa no.
Habilitar la Protección contra malos mensajes de error

Esta opción pondrá sobre aviso a usted acerca de todos los malos
mensajes de error en su red.
net.ipv4.icmp_ignore_bogus_error_responses=1
Habilitar la protección de spoofing

El spoofing consiste en modificar la dirección origen de un paquete de
forma que la máquina que recibe el paquete crea que proviene de una
máquina de confianza.
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.lo.rp_filter=1
net.ipv4.conf.eth0.rp_filter=1
net.ipv4.conf.default.rp_filter=1
NOTA: Este parámetro previene de ataques spoofing contra sus redes

internas, pero contra sus direcciones externas se pueden presentar
todavía ataques spoofing.

50
Autoevaluación
1. ¿Qué puerto es usado en las consultas DNS?
(a) 110
(b) 143
(c) 53
(d) 21
(e) 58
2. ¿Cuáles de las siguientes oraciones son verdaderas? (Seleccione 2

opciones)
Para establecer una sesión a nivel de UDP, se efectúa el proceso de

handshaking.
ICMP informa de errores en el procedieminto de los paquetes al host

origen.
HTTP es un protocolo de la capa 7 del modelo OSI.
Mediante ARP se obtiene la máscara de red de la dirección IP.
Las opciones de seguridad TCP/IP se pueden defnir en el archivo

/etc/sysctl.conf.
3. ¿Por qué es importante mantener una sesión orientada a la conexión?
4. Describa el saludo de tres vías.

SEMANA
4
Seguridad en un servidor
de Correos
TEMA
Describir el uso del servicio Mailscanner
• Comprender el uso del servicio Mailscanner

• Configurar e implmentar los servicios de Antivirus y Antispam con el mailscanner
CONTENIDOS
• Mailscanner
• Antivirus Clamav
• Antispam SpamAssassin

52
1. Seguridad en un servidor de correo con MailScanner
MailScanner, un robusto servicio que se encarga de examinar el correo

electrónico e identificar y etiquetar correo masivo no solicitado (Spam), así
como también los fraudes electrónicos (Phishing). Combinado con ClamAV, un
poderoso y versátil anti-virus libre para Linux, resultan una de las soluciones
más robustas para la protección contra correo masivo no solicitado, fraudes
electrónicos, virus, gusanos y troyanos desde el servidor de correo electrónico.
MailScanner tiene las siguientes características:
• Distribuido bajo los términos de la Licencia Publica General GNU

versión 2.
• Revisa el correo electrónico en busca de virus utilizando
cualquier combinación de entre más de una docena de distintos
programas anti-virus.
• Automáticamente actualiza todo los anti-virus instalados cada
hora.
• Identifica alrededor del 95% del correo masivo no solicitado
(Spam) utilizando diferentes técnicas, incluyendo altamente
avanzadas técnicas de heurística (capacidad de un sistema para
realizar de forma inmediata innovaciones positivas para sus
fines).
• El correo identificado como peligroso puede ser etiquetado,
rechazado, descartado, archivado o reenviado hacia otras
direcciones para su inspección por los administradores.
• Puede eliminar el contenido gráfico de correo masivo no
solicitado (Spam) de tipo pornográfico protegiendo a los usuarios
de contenido obsceno.
• Verifica el coreo electrónico en busca de conocidas
vulnerabilidades para las más populares aplicaciones de correo
electrónico y corrige automáticamente los mensajes durante el
proceso cuando sea posible poniendo en cuarentena las
secciones peligrosas de contenidas en los mensajes.
• Es altamente escalable. Un servidor puede procesar más de
millón y medio de mensajes de correo por día.
• Es robusto. Se protege a si mismo contra ataques de
Denegación de Servicio (DoS) y fuga de recursos del sistema
operativo.
• Es altamente configurable, proporciona a los Proveedores de
Servicios de Internet (ISP o Internet Service Provider y
Proveedores de Servicios de Aplicaciones (ASP o Application
Service Provider) la posibilidad de utilizar miles de diferentes
reglas y configuraciones para cualquier combinación de usuarios
y dominios.
• Es fácil de instalar y configurar puesto que sus opciones
predefinidas permiten trabajar al servicio de correo sin

complicaciones.
Página Oficial: http://www.mailscanner.info/.
Acerca de ClamAV.
ClamAV tiene las siguientes características:
• Distribuido bajo los términos de la Licencia Pública General GNU

versión 2.
• Cumple con las especificaciones de familia de estándares POSIX
(Portable Operating System Interface for UNIX o interfaz portable
de sistema operativo para Unix).
• Exploración rápida.
• Detecta más de 44 mil virus, gusanos y troyanos, incluyendo
virus para MS Office.
• Capacidad para examinar contenido de ficheros ZIP, RAR, Tar,
Gzip, Bzip2, MS OLE2, MS Cabinet, MS CHM y MS SZDD.
• Soporte para explorar ficheros comprimidos con UPX, FSG y
Petite.
• Avanzada herramienta de actualización con soporte para firmas
digitales y consultas basadas sobre DNS.
Pagina Oficial: http://www.clamav.net/
Acerca de SpamAssassin.
SpamAssassin es un sustento lógico que utiliza un sistema de puntuación,

basado sobre algoritmos de tipo genético, para identificar mensajes que
pudieran ser sospechosos de ser correo masivo no solicitado, añadiendo
cabeceras a los mensajes de modo que puedan ser filtrados por el cliente de
correo electrónico o MUA (Mail User Agent).
Pagina Oficial: http://spamassassin.apache.org/
Procedimientos.
Sustento lógico necesario.
• mailscanner >= 4.50 • clamav >= 0.88 • spamAssassin >= 3.0.4
• perl-Convert-BinHex • perl-MailTools • perl-MIME-tools
• perl-IO-stringy • perl-TimeDate • perl-Net-CIDR
• perl-Compress-Zlib • perl-Convert-ASN1 • perl-Archive-Zip
• tnef
Para instalar MailScanner descargando la más reciente versión desde

http://www.mailscanner.info/ en donde encontrará un paquete *.tar.gz en cuyo
interior hay paquetes SRPM que podrá compilar e instalar en el orden indicado
siguiendo las instrucciones del fichero README. De igual modo, podrá
proceder con clamav desde http://clamav.net/
54
Configuración de MailScanner.
Utilice el editor de texto de su predilección y disponga a modificar

/etc/MailScanner/MailScanner.conf con la finalidad de configurar los
siguientes parámetros:
Lenguaje de los mensajes de sistema.
Puede configurar MailScanner para que devuelva los mensajes de sistema en

español. Localice lo siguiente:
%report-dir% = /etc/MailScanner/reports/en
Cambie por:
%report-dir% = /etc/MailScanner/reports/es
Identificación de la organización.
Solo es de carácter informativo y sirve para identificar si un mensaje infectado

pertenece a un servidor u otro. Localice lo siguiente:
%org-name% = yoursite
Cambie por:
%org-name% = empresa
El parámetro %org-long-name% es utilizado para definir que mostrar en la

firma localizada al final de los reportes enviados por MailScanner. Puede incluir
cuanto texto sea necesario, e incluso definir varias líneas utilizando secuencias
\n.
%org-long-name% = Empresa Imaginaria S.A. de C.V.
El parámetro %web-site% se utiliza para definir el URL de la empresa, mismo

que también se incluye en la firma al final de los reportes que envía
MailScannmer. Se recomienda se utilice una URL hacia un documento que
explique el porque se han rechazado/filtrado mensajes o bien información de
contacto.
%web-site% = http://www.empresa-imaginaria.com.mx/info-
correo.html
Adjuntos en formato de texto enriquecido.
Algunas versiones de Microsoft Outlook generan adjuntos en formato de Texto

Enriquecido (Rich Text Format) que no pueden ser examinados. El valor
predefinido es no ya que de otro modo habría un alto riesgo de permitir la
entrada de virus a través de este tipo de mensajes. Sin embargo, muchos
usuarios de Outlook pueden protestar al respecto por carecer de un enfoque
apropiado acerca de la seguridad. ¿Realmente vale la pena el riesgo? Si los

usuarios están de acuerdo en que recibir un mensaje con colores y letras
bonitos es más importante que la seguridad, puede cambiarse el valor a yes.
Deliver Unparsable TNEF = no
Adicionalmente, puede, aunque no se recomienda, cambiar el valor de deny

por allowen la línea de configuración correspondiente para adjuntos con
extensión *.dat en el fichero /etc/MailScanner/filename.rules.conf. En este
fichero se define lo que se quiera denegar si los mensajes incluyen ciertos tipos
de ficheros adjuntos que se consideran de alto riesgo. El formato de este
fichero consiste en definir una regla (que puede ser allow, deny o
deny+delete), una expresión regular a filtrar, texto a incluir en la bitácora del
sistema y el texto a utilizar en el reporte para el usuario, todo separado por
tabuladores y en una sola línea por cada regla.
deny winmail\.dat$ Windows security

vulnerability No Outlook Rich Text Format messages due
to security hole, use HTML instead
Lo anterior rechaza los mensajes que incluyan adjuntos *.dat, es decir

mensajes de Outlook en Formato de Texto Enriquecido (Outlook Rich Text
Format), devolviendo un mensaje de error en inglés que diría: «No Outlook
Rich Text Format messages due to security hole, use HTML instead». Se
puede poner el mensaje al español:
deny winmail\.dat$ Windows security

vulnerability No aceptamos mensajes en Formato de Texto
Enriquecido de Outlook, por favor utilice HTML.
Lo anterior rechaza los mensajes que incluyan adjuntos *.dat, es decir

mensajes de Outlook en Formato de Texto Enriquecido (Outlook Rich Text
Format), devolviendo un mensaje de error en inglés que diría: «No aceptamos
mensajes en Formato de Texto Enriquecido de Outlook, por favor utilice
HTML.».
Definir anti-virus a utilizar.
MailScanner puede detectar, automáticamente, los anti-virus a utilizar dejando

el valor auto en el parámetro Virus Scanners, de modo que detectará
cualquiera de los siguientes:
• Sophos. • Mcafee. • Command.

• Bitdefender. • DRweb. • Kaspersky.
• eTrust. • Inoculate. • Inoculan.
• Nod32. • F-Secure. • F-Prot.
• Panda. • Rav. • Antivir.
• ClamAV. • Trend. • Norman.
• Css. • AVG. • Vexira.

56
Para agilizar el inicio de MailScanner, se pueden definir los anti-virus

necesarios. ClamAV es el anti-virus recomendado por tratarse de un sustento
lógico libre.
Localice lo siguiente en el fichero /etc/MailScanner/MailScanner.conf:
Virus Scanners = none
Cambie por:
Virus Scanners = clamav
Puede utilizar más de un anti-virus si así lo considera conveniente. Solo

necesitará instalar las versiones apropiadas para el sistema operativo que
utilice y añadirlos en MailScanner como lista horizontal separada por espacios.
Ejemplo:
Virus Scanners = clamav mcafee sophos trend
¿Poner en cuarentena los mensajes infectados o no?
Si decide no poner en cuarentena los elementos adjuntos infectados en los

mensajes de correo electrónico y prefiere eliminar estos adjuntos,
inmediatamente, después de ser procesados, localice lo siguiente:
Quarantine Infections = yes
Cambie por:
Quarantine Infections = no
Permitir mensajes con etiqueta Iframe, Form y Script.
Las etiquetas iframe se utilizan para cargar una página empotrada dentro de
un marco. Lamentablemente, esto representa un riesgo muy alto e innecesario
debido a que un mensaje de correo electrónico podría no contener material
dañino, pero tal vez el la página que cargue el marco que si lo contenga.
Actualmente, se considera el enviar correo electrónico utilizando etiquetas
iframe como poco ético por todos los riesgos que conlleva.
Las opciones permitidas son:
• yes: Permite la etiqueta en el mensaje.

• no: elimina los mensajes que contengan la etiqueta.
• disarm: Permite las etiquetas pero impide que éstas funcionen.
El valor predeterminado es disarm.
Allow IFrame Tags = disarm

Lo mismo aplica para las etiquetas form, que pueden permitir la recolección de
datos desde el mensaje de correo electrónico con ayuda de la ingenuidad del
usuario, o bien la ejecución de código peligroso a través de guiones escritos en
JavaScript a través de la etiqueta script.
Allow Form Tags = disarm

Allow Script Tags = disarm
Control de Spam.
De modo predefinido está activo el soporte de exploración de correo en

búsqueda de correo masivo no solicitado (Spam).
Spam Checks = yes
Quienes se dedican al envío de correo masivo no solicitado han aprendido que

pueden hacer que su mensaje pase los filtros enviando un mensaje con
muchos destinatarios, uno de los cuales podría tener configurado tener todo en
lista blanca en las opciones de SpamAssassin en el directorio de inicio del
usuario. De este modo, si un mensaje llega con más de un número
determinado de destinatarios (20 de modo predefinido), éste se será tratado
como cualquier otro mensaje sin aún si el destinatario ha decidido poner todo
en lista blanca o si el remitente está en la lista blanca en el fichero
/etc/MailScanner/rules/spam.whitelist.rules.
Ignore Spam Whitelist If Recipients Exceed = 20
A través de DNSBL o listas negras.
MailScanner permite también realizar filtrado de correo contra listas negras

como SpamCop y Spamhaus. Si ya utiliza los DNSBL o listas negras desde
Sendmail, no active esta funcionalidad en MailScanner para no duplicar
las consultas hacia los DNSBL.
Modifique el fichero /etc/MailScanner/spam.lists.conf y defina o confirme las

listas negras a utilizar
ORDB-RBL relays.ordb.org.
#
# spamhaus.org sbl.spamhaus.org.
# spamhaus-XBL xbl.spamhaus.org.
# combinación de las dos anteriores:
SBL+XBL sbl-xbl.spamhaus.org.
#
spamcop.net bl.spamcop.net.
NJABL dnsbl.njabl.org.
SORBS dnsbl.sorbs.net.
Localice en el fichero /etc/MailScanner/MailScanner.conf lo siguiente:
Spam List = ORDB-RBL SBL+XBL # MAPS-RBL+ costs money (except

.ac.uk)

58
Cambie por:
Spam List = ORDB-RBL SBL+XBL spamcop.net NJABL SORBS
A través de SpamAssassin.
MailScanner puede echar mano de SpamAssassin para una más eficiente

detección de correo masivo no solicitado. Puede activarse o desactivarse esta
funcionalidad a través del parámetro Use SpamAssassin asignando yes o no.
Use SpamAssassin = yes
SpamAssassin utiliza un sistema de calificación para etiquetar o no como

correo masivo no solicitado. Se asigna un valor numérico a partir de 1 (valor
recomendado es 6), con o sin decimales, para el parámetro Required
SpamAssassin Score. Cada vez que se identifica en un mensaje contiene
alguna característica que pudiera clasificarlo como correo masivo no solicitado,
se asignan fracciones de punto que se van sumando. Cuando un mensaje
rebasa el valor asignado para Required SpamAssassin Score éste es
etiquetado de inmediato como correo masivo no solicitado.
Required SpamAssassin Score = 6
Puede especificarse también a través del parámetro High SpamAssassin

Score que los mensajes que rebasen la puntuación establecido como valor de
este se eliminen, directamente, en lugar de solo etiquetarlos como correo
masivo no solicitado. El valor prefinido (y recomendado) es 10.
High SpamAssassin Score = 10
El parámetro Spam Actions define que política a aplicar para el correo

electrónico que se clasifica como Spam, calificado a partir del valor definido en
Required SpamAssassin Score, pero inferior al valor definido a High
SpamAssassin Score. El parámetro High Scoring Spam Actions se utiliza
para definir la política a aplicar para el correo electrónico que se clasifica como
Spam, calificado a partir del valor definido en High SpamAssassin Score.
Pueden utilizarse combinaciones de los siguientes valores:
deliver Entrega del mensaje de modo normal.

delete Eliminar el Mensaje.
bounce Envía un masaje de rechazo al
remitente. Este valor solo puede
utilizarse con el parámetro Spam
Actions, no puede utilizarse con el
parámetro High Scoring Spam
Actions.
store Almacenar el mensaje en el directorio
de cuarentena.
forward Reenviar copia del mensaje a

usuario@dominio.com usuario@dominio.com
striphtml Convierte el contenido HTML a texto
simple. Se requiere especificar el valor
deliver para que tenga efecto.
attachment Convierte el mensaje a adjunto, de
modo que el usuario tendrá que realizar
un paso adicional para mirar el
contenido.
notify Se envía una breve notificación al
usuario que le indica que no le fue
entregado un mensaje por haber sido
clasificado como correo masivo no
solicitado, permitiendo solicitar
recuperar el mensaje si acaso éste
fuese un mensaje esperado.
header "nombre: valor" Añade la cabecera con cualquier

nombre (sin espacios) con el valor
especificado.
Suponiendo se aplicarán las siguientes políticas:
• Si el mensaje es calificado al menos el valor definido en Required

SpamAssassin Score, pero inferior al valor definido en High
SpamAssassin Score, se entregará al usuario como mensaje
adjunto y añadirá la cabecera "X-Spam-Status: Yes".
• Si el mensaje es calificado al menos con el valor definido en High
SpamAssassin Score, se eliminará automáticamente.
Los valores para Required SpamAssassin Score y High SpamAssassin

Score coresponderían del siguiente modo:
Spam Actions = deliver attachment header "X-Spam-Status:

Yes"
High Scoring Spam Actions = delete
Listas Blancas.
Pueden especificarse listas blancas de direcciones o nombres de dominio que

no se desee etiqueten como correo masivo no solicitado (Spam) en el fichero
/etc/MailScanner/rules/spam.whitelist.rules del siguiente modo, donde yes
signficará que el correo proveniente de dichas direcciones nunca se etiquetará
como correo masivo no solicitado (Spam):
# This is where you can build a Spam WhiteList

# Addresses matching in here, with the value
# "yes" will never be marked as spam.

60
#From: 152.78. yes

#From: 130.246. yes
FromOrTo: default no
From: 200.76.185.250 yes
From: 192.168.0. yes
En el ejemplo anterior, todo el correo proveniente de 200.76.185.250 y

cualquier dirección IP de la red 192.168.0.0/24 quedará exento de etiquetarse
como correo masivo no solicitado (Spam).
Configuración de servicios.
Necesitará inicializar los servicios clamd y freshclam. El segundo,

particularmente, se encarga de contactar los servidores que hospedan las
bases de datos actualizadas con las más recientes firmas de los más recientes
virus, gusanos, troyanos y otros tipos de sustento lógico maligno.
chkconfig clamd on
chkconfig freshclam on
service clamd start
service freshclam start
De ser necesario, puede actualizar, manualmente, y de manera inmediata la

base de datos de firmas ejecutando de forma simple, freshclam desde
cualquier terminal como root.
Se debe desactivar y detener el servicio de sendmail, el cual será controlado en

adelante por el servicio MailScanner:
chkconfig sendmail off

chkconfig MailScanner on
service sendmail stop
service MailScanner start
Comprobaciones.
Utilice cualquier cliente de correo electrónico y envíe el archivo entregado por

el profesor, como adjunto hacia una cuenta de correo loca el fichero test2.zip.
El procedimiento deberá entregar el mensaje al destinatario con el título
alterado indicando que el mensaje contenía un virus y en el interior un texto
que indica que el adjunto fue removido y eliminado.
Si quiere hacer una prueba rápida, utilice mutt para enviar un mensaje de
prueba ejecutando lo siguiente, suponiendo que hay un usuario denominado
como «fulano» en el sistema:
echo "Prueba Anti-virus" | mutt -a test2.zip -s "Prueba

Anti-virus" fulano
Lo anterior deberá devolver al destinatario el siguiente mensaje de correo

electrónico:
Asunto: {Virus?} Prueba Anti-virus

De: "Fulano" <fulano@localhost.localdomain >

Fecha: Mie, 18 de Agosto de 2004, 10:31 pm
Para: "Fulano" <fulano@localhost.localdomain >
Atención: Este mensaje contenía uno o más anexos
que han sido eliminados
Atención: (test2.zip, clamtest).
Atención: Por favor, lea el(los) anexo(s) "empresa-
Attachment-Warning.txt"
para más información.
Prueba Anti-virus
El administrador del servidor de correo recibirá en cambio lo siguiente:
Asunto: Virus Detected

De: "MailScanner" <postmaster@localhost.localdomain>
Fecha: Mie, 18 de Agosto de 2004, 10:31 pm
Para: postmaster@localhost.localdomain
The following e-mails were found to have:Virus Detected

Sender: root@localhost.localdomain
IP Address: 127.0.0.1
Recipient: fulano@localhost.localdomain
Subject: Prueba Anti-virus
MessageID: i7J3VTXF004487
Informe: ClamAV: clamtest contains ClamAV-Test-Signature
Informe: ClamAV: test2.zip contains ClamAV-Test-Signature
ClamAV: clamtest contains ClamAV-Test-Signature --
MailScanner
Email Virus Scanner
www.mailscanner.info
Si todos los procedimientos de comprobación por algún motivo no funcionan,

por favor verifique la sintaxis en todas las líneas modificadas en el fichero
/etc/MailScanner/MailScanner.conf, como seguramente podrá leer se indica
en la bitácora localizada en el fichero /var/log/maillog.y que también puede
mostrar información de utilidad.
tail -f /var/log/maillog

62
Autoevaluación
1. ¿Qué puerto es usado por el servidor de correo?
(f) 110
(g) 143
(h) 53
(i) 25
(j) 58
2. ¿Cuáles de las siguientes oraciones son verdaderas? (Seleccione 2

opciones)
MailScanner tiene la característica de revisar el correo electrónico en

busca de virus utilizando cualquier combinación de entre más de una
docena de distintos programas anti-virus.
SpamAssassin informa de errores en el procedieminto de los

paquetes al host origen.
SMTP es un protocolo de la capa 7 del modelo OSI.
ClamAV es el anti-virus recomendado para la seguridad del servidor

de correos.
Las opciones de seguridad MailScanner se pueden defnir en el

archivo /etc/sysctl.conf.
3. ¿Por qué es importante implementar un sistema de seguridad al servidor

de correo?

SEMANA
5
Firewalls en Linux
TEMA
Describir el funcionamiento del Firewall.
• Comprender el funcionamiento del Firewall

• Identificar las arquitecturas del Firewall
• Comprender el diseño del Firewall
CONTENIDOS
• Firewall
• Políticas de diseño de Firewall

64
1. FIREWALL
Los cortafuegos (o el firewall en inglés), es un elemento de

hardware o software utilizado en las redes para prevenir algunos tipos
de comunicaciones prohibidas por las políticas de red, las cuales se
fundamentan en las necesidades del usuario.
La configuración correcta de unos cortafuegos se basa en

conocimientos considerables de los protocolos de red y de la seguridad
de la computadora. Errores pequeños pueden dejar a un cortafuego sin
valor como herramienta de seguridad.
Puede consistir en distintos dispositivos, tendientes a los siguientes

objetivos:
• Todo el tráfico desde dentro hacia fuera, y viceversa, debe

pasar a través de él.
• Sólo el tráfico autorizado, definido por la política local de
seguridad, es permitido.
Fig. 1.
Firewall
Como puede observarse, el Muro Cortafuegos, sólo sirven de

defensa perimetral de las redes, no defienden de ataques o errores
provenientes del interior, como tampoco puede ofrecer protección
una vez que el intruso lo traspasa.
Algunos Firewalls aprovechan esta capacidad de que toda la

información entrante y saliente debe pasar a través de ellos para
proveer servicios de seguridad adicionales como la encriptación del
tráfico de la red. Se entiende que si dos Firewalls están

conectados, ambos deben "hablar" el mismo método de

encriptación-desencriptación para entablar la comunicación.
Arquitecturas de Firewall
• Filtrado de Paquetes
• Proxy-Gateways de aplicaciones
• Dual-Homed Host
• Screened Host
• Inspección de paquetes
1.1. Filtrado de paquetes
Se utilizan routers con filtros y reglas basadas en políticas de

control de acceso. El router es el encargado de filtrar los
paquetes basados en cualquiera de los siguientes criterios:
(1) Protocolos utilizados.

(2) Dirección IP de origen y de destino.
(3) Puerto TCP-UDP de origen y de destino.
Estos criterios permiten gran flexibilidad en el tratamiento del

tráfico. Restringiendo las comunicaciones entre dos
computadoras (mediante las direcciones IP) se permite
determinar entre cuáles máquinas la comunicación está
permitida.
El filtrado de paquetes mediante puertos y protocolos permite

establecer qué servicios estarán disponibles al usuario y por
cuales puertos. Se puede permitir navegar hacia un servidor
Web (puerto 80 abierto), pero no acceder a la transferencia
de archivos vía FTP (puerto 21 cerrado).
Debido a su funcionamiento y estructura basada en el

filtrado de direcciones y puertos, este tipo de firewalls trabajan
en los niveles de transporte y de red del modelo OSI, y
están conectados a ambos perímetros (interior y exterior) de
la red.
Tienen la ventaja de ser económicos, tienen un alto nivel de

desempeño y son transparentes para los usuarios conectados a
la red; sin embargo, presenta debilidades como:
(1) No protege las capas superiores a nivel OSI.

(2) Las necesidades aplicativas son difíciles de traducir como filtros
de protocolos y puertos.
(3) No son capaces de esconder la topología de redes privadas,
por lo que exponen la red al mundo exterior.
(4) Sus capacidades de auditoría suelen ser limitadas, al igual que
su capacidad de registro de actividades.
(5) No soportan políticas de seguridad complejas, como

66
autentificación de usuarios y control de accesos con horarios

prefijados.
1.2. Proxy-Gateways de aplicaciones
Para evitar las debilidades asociadas al filtrado de paquetes,

los desarrolladores crearon software de aplicación
encargados de filtrar las conexiones. Estas aplicaciones son
conocidas como Servidores Proxy y la máquina donde se
ejecuta recibe el nombre de Gateway de aplicación o Host
Bastion.
El Proxy, instalado sobre el Host Bastión, actúa de

intermediario entre el cliente y el servidor real de la
aplicación, siendo transparente a ambas partes.
Cuando un usuario desea un servicio, lo hace a través del

Proxy. Este, realiza el pedido al servidor real devuelve los
resultados al cliente. Su función fue la de analizar el tráfico de
red en busca de contenido que viole la seguridad de la misma.
Gráficamente:
Fig. 2. Host Bastion
1.3. Screened Host
En este caso se combina un Router (Filtrado de Paquetes) con

un Host Bastión (Proxy) y el principal nivel de seguridad
proviene del filtrado de paquetes. En el bastión, el único sistema
accesible desde el exterior, se ejecuta el Proxy de aplicaciones
y en el router se filtran los paquetes considerados peligrosos y
sólo se permiten un número reducido de servicios.

Fig. 3. Screened Host
1.4. Dual-Homed Host
Son dispositivos que están conectados a ambos perímetros

(interior y exterior) y no dejan pasar paquetes IP (como
sucede en el caso del Filtrado de Paquetes), por lo que se
dice que actúan con el "IP- Forwarding desactivado".
Un usuario interior que desee hacer uso de un servicio exterior,

deberá conectarse primero al firewall, donde el Proxy atenderá
su petición, y en función de la configuración impuesta en dicho
firewall, se conectará al servicio exterior solicitado y hará de
puente entre este y el usuario interior.
Es decir, que se utilizan dos conexiones: uno, desde la

máquina interior hasta el Firewall; y el otro, desde este hasta
la máquina que albergue el servicio exterior.

68
Fig. 4. Dual-homes Host
1.5. Screened Subset
En este diseño se intenta aislar la máquina más atacada y

vulnerable del firewall, el Host Bastión. Para ello, se
establece una zona desmilitarizada (DMZ) de forma tal que
si un intruso accede a esta máquina no consiga el acceso
total a la subred protegida.
En este esquema se utilizan dos routers: uno exterior y otro

interior. El router exterior tiene la misión de bloquear el
tráfico no deseado en ambos sentidos: hacia la red interna y
hacia la red externa. El router interior hace lo mismo con la
red interna y la DMZ (zona entre el router externo y el interno).
Es posible definir varios niveles de DMZ agregando más

routers, pero destacando que las reglas aplicadas a cada uno
deben ser distintas, ya que, en caso contrario, los niveles se
simplificarían a uno solo.

Fig. 5. Screneed-subnet
Como puede apreciarse, la zona desmilitarizada aísla,

físicamente, los servicios internos, separándolos de los
servicios públicos. Además, no existe una conexión directa
entre la red interna y la externa.
Los sistemas Dual-Homed Host y Screnned pueden ser

complicados de configurar y comprobar, lo que puede dar
lugar, paradójicamente, a importantes agujeros de seguridad en
toda la red. En cambio, si se encuentran bien configurados y
administrados, pueden brindar un alto grado de protección y ciertas
ventajas:
(1) Ocultamiento de la información: los sistemas externos no deben

conocer el nombre de los sistemas internos. El Gateway de
aplicaciones es el único autorizado a conectarse con el
exterior y el encargado de bloquear la información no solicitada
o sospechosa.
(2) Registro de actividades y autenticación robusta: El Gateway
requiere de autenticación cuando se realiza un pedido de
datos externos. El registro de actividades se realiza en base a
estas solicitudes.
(3) Reglas de filtrado menos complejas: Las reglas del filtrado
de los paquetes por parte del router serán menos compleja
dado a que él sólo debe atender las solicitudes del Gateway.
Asimismo, tienen la desventaja de ser intrusivos y no

transparentes para el usuario ya que, generalmente, este debe
instalar algún tipo de aplicación especializada para lograr la
comunicación. Se suma a esto, un proceso lento, porque deben
revisar todo el tráfico de la red.
1.6. Inspección de paquetes
Este tipo de firewalls se basa en el principio de que cada

paquete que circula por la red es inspeccionado, así como
también su procedencia y destino. Se aplican desde la capa
de red hasta la de aplicaciones. Generalmente, son instalados
70
cuando se requiere seguridad sensible al contexto y en

aplicaciones muy complejas.
2. Políticas de diseño del firewall.
Las políticas de accesos en un firewall se deben diseñar poniendo

principal atención en sus limitaciones y capacidades, pero también
pensando en las amenazas y vulnerabilidades presentes en una red
externa insegura.
Conocer los puntos a proteger es el primer paso a la hora de establecer

normas de seguridad. También, es importante definir los usuarios contra
los que se debe proteger cada recurso, ya que las medidas diferirán,
notablemente, en función de esos usuarios.
Generalmente, se plantean algunas preguntas fundamentales que

debe responder cualquier política de seguridad:
• ¿Qué se debe proteger?
Se deberían proteger todos los elementos de la red interna (hardware,

software, datos, etc.).
• ¿De quién protegerse?
De cualquier intento de acceso no autorizado desde el exterior y contra

ciertos ataques desde el interior que puedan preverse y prevenir.
Sin embargo, podemos definir niveles de confianza, permitiendo,

selectivamente, el acceso de determinados usuarios externos a
determinados servicios o denegando cualquier tipo de acceso a otros.
• ¿Cómo protegerse?
Esta es la pregunta más difícil y está orientada a establecer el nivel de

monitorización, control y respuesta deseado en la organización. Puede
optarse por alguno de los siguientes paradigmas o estrategias:
a. Paradigmas de seguridad
• Se permite cualquier servicio excepto aquellos,

expresamente, prohibidos.
• Se prohíbe cualquier servicio excepto aquellos,

expresamente, permitidos. La más recomendada y utilizada,
aunque algunas veces suele acarrear problemas, por
usuarios descontentos que no pueden acceder a tal o cual

servicio.
b. Estrategias de seguridad
• Paranoica: se controla todo, no se permite nada.

• Prudente: se controla y se conoce todo lo que sucede.
• Permisiva: se controla, pero se permite demasiado.
• Promiscua: no se controla (o se hace poco) y se permite
todo.
• ¿Cuánto costará?
Estimando en función de lo que se desea proteger, se debe decidir

cuanto es conveniente invertir.
3. Restricciones en el firewall
La parte más importante de las tareas que realizan los firewalls, la de

permitir o denegar determinados servicios, se hacen en función de los
distintos usuarios y su ubicación:
(1) Usuarios internos con permiso de salida para servicios restringidos:

permite especificar una serie de redes y direcciones a los que
denomina Trusted (validados). Estos usuarios, cuando provengan del
interior, van a poder acceder a determinados servicios externos que
se han definido.
(2) Usuarios externos con permiso de entrada desde el exterior: este es

el caso más sensible a la hora de vigilarse. Suele tratarse de usuarios
externos que por algún motivo deben acceder para consultar
servicios de la red interna.
También, es habitual utilizar estos accesos por parte de terceros para

prestar servicios al perímetro interior de la red. Sería conveniente que
estas cuentas sean activadas y desactivadas bajo demanda y
únicamente el tiempo que sean necesarias.
4. Beneficios de un firewall
Los firewalls manejan el acceso entre dos redes y, si no existieran, todas

las computadoras de la red estarían expuestas a ataques desde el
exterior. Esto significa que la seguridad de toda la red estaría
dependiendo de qué tan fácil fuera violar la seguridad local de cada
máquina interna.
El firewall es el punto ideal para monitorear la seguridad de la red y

generar alarmas de intentos de ataque. El administrador será el
responsable de la revisión de estos monitoreos.

72
Otra causa que ha hecho que el uso de firewalls se halla convertido en

uso casi imperativo es el hecho que en los últimos años en Internet han
entrado en crisis el número disponible de direcciones IP. Esto ha hecho
que las intranets adopten direcciones sin clase, las cuales salen a Internet
por medio de un "traductor de direcciones", el cual puede alojarse en el
firewall.
Los firewalls también son importantes desde el punto de vista de llevar las
estadísticas del ancho de banda "consumido" por el tráfico de la red y qué
procesos han influido más en ese tráfico. De esta manera, el administrador
de la red puede restringir el uso de estos procesos y economizar o
aprovechar mejor el ancho de banda disponible.
Los firewalls, también, tienen otros usos. Por ejemplo, se pueden usar
para dividir partes de un sitio que tienen distintas necesidades de
seguridad o para albergar los servicios WWW y FTP brindados.
5. Limitaciones de un firewall
La limitación más grande que tiene un firewall, sencillamente, es el hueco

que no se tapa y que, coincidentemente o no, es descubierto por un
intruso.
Los firewalls no son sistemas inteligentes. Ellos actúan de acuerdo a
parámetros introducidos por su diseñador; por ende, si un paquete de
información no se encuentra dentro de estos parámetros, como una
amenaza de peligro, simplemente, lo deja pasar. Más peligroso aún es
que ese intruso deje Back Doors abriendo un hueco diferente y borre las
pruebas o indicios del ataque original.
Otra limitación es que el firewall "No es contra humanos", es decir que si
un intruso logra entrar a la organización y descubrir contraseñas o los
huecos del firewall y difunde esta información, el Firewall no se dará
cuenta.
El Firewall tampoco provee de herramientas contra la filtración de

software o archivos infectados con virus, aunque es posible dotar a la
máquina, donde se aloja el Firewall, de antivirus apropiados.
El único firewall seguro (100%) es aquel que se mantiene

apagado.

Autoevaluación
1. ¿Cuál no es un criterio para el filtrado de paquetes?
a) Protocolos utilizados
b) Dirección IP origen
c) Dirección IP destino
d) Dirección MAC
e) Puerto TCP destino
2. ¿Cuáles son las restricciones en el firewall?
3. Liste cada una de las arquitecturas de firewall.

74

SEMANA
6
Stateful packet inspection
firewall I
TEMA
Describir el uso de Netfilter.
• Comprender el funcionamiento del filtrado de paquetes entrantes y salientes.

• Comprender el uso de la politica predeterminada DROP.
CONTENIDOS
• Filtrado de paquetes entrantes/salientes

• Filtrado de paquetes salientes/entrantes

76
1. Netfilter
Netfilter (http://www.netfilter.or) es la última generación de las utilidades
para filtrados de paquetes (Packet Filtering), incluidos en el Kernel de Linux.
La primera generación fue un port de IPFW (BSD), por Alan Cox, cerca de
1994. Con la aparición de la versión 2.0 de Linux, se creo la utilidad
ipfwadm para regular el filtrado usando una herramienta desde el espacio
de usuario.
En 1998, junto con la aparición del Kernel 2.2, se introdujo la segunda

generación, IPChains, una combinación de módulos y programas de usuario
para el control de flujo de paquetes.
Cerca del 99, al aparecer la versión 2.4, gran parte de la API de IPChains
fue reescrita dando origen a la cuarta generación, Iptables.
El principal responsable es Paul "Rusty" Russell, quien desarrollo Netfilter

cuando trabajaba en Watchguard (http://www.watchguard.com).
Es además una infraestructura completa insertada dentro del kernel,

incluida desde algunas versiones 2.3 y agregado oficialmente en la serie
2.4. Está compuesta por una serie de módulos y un software para controlar
las reglas. De esta manera, permite que un modulo de kernel, más una
utilidad presente dentro del espacio de usuario, controlen el flujo de
paquetes que van desde y hacia las interfaces de red.
Netfilter es aplicable para cualquier sistema de Filtrado de Paquetes (o
Packet Filter). Y es usado, principalmente, por tres razones:
• Control de Tráfico (o Flujo de Red)

• Seguridad (de Servicios de Red)
• Observación (del Tráfico actual)
1.1. Funcionamiento
En IPTables, existen 4 tipos de tablas (ver Fig. 1): raw, filter, nat y
mangle (manipulación). Cada una de estas tablas posee cadenas
internas. Por ejemplo, filter posee INPUT, OUTPUT y FORWARD.
IPTables cambia el contexto en el cual el paquete es interpretado. En

el caso de la tabla filter, las cadenas INPUT y OUTPUT se refieren al
equipo local, haciendo que el camino de cada uno de los paquetes
parezca más limpio al momento de manipularlos.
Existe, también, la tabla de tipo "transversal", que es el etiquetado y

manipulado de paquetes (entendido, comúnmente, como paquetes que
viajan de una interfaz a otra). Generalmente, es asumido por la cadena
FORWARD (filter). Esta cadena está de forma intermedia entre una
cadena de pre-ruta (PREROUTING) y una de post-ruta
(POSTROUTING), quienes realizan funciones de NAT y
enmascaramiento de IP (IP Masquerading), pertenecientes a la tabla
nat.

Fig. 1. Viaje del paquete1
1
Fuente: http://iptables-tutorial.frozentux.net/iptables-tutorial.html

78
La tabla mangle permite la reescritura completa de paquetes (o tramas

completas) combinando la funcionalidad dentro de las cadenas dentro
de filter (INPUT, OUTPUT y FORWARD) y nat (PREROUTING y
POSTROUTING).
La tabla raw es usada, únicamente, para marcar los paquetes puesto

que ellos no puedan ser manipulados por un sistema de rastreo.
1.1.1. Cadenas
Las cadenas son las indicaciones del paso de los paquetes dentro de
la utilización interna de Netfilter.
Antes de ingresar los paquetes al sistema de Netfilter, es realizada una

suma de comprobacion (Checksum). Si es correcta, los paquetes
transitan hacia la regla PREROUTING, quien se encarga, primero, de
determinar si los paquetes son considerados locales o deben ser
reenviados a otra interfaz.
Si son considerados locales, estos son enviados a la cadena INPUT.
Si no son considerados locales, estos son enviados a la regla

FORWARD.
NOTA: los paquetes que no son considerados "locales" son aquellos

que, por lo general, pertenecen a otra subred.
Antes de que los paquetes abandonen el sistema (de Netfilter), son

recibidos por la cadena POSTROUTING antes de ser enviados a la
interfaz destino.
La cadena OUTPUT solo es utilizada cuando los paquetes hayan sido

originados localmente. Además, los paquetes que pasen por la cadena
OUTPUT, necesariamente, pasan por POSTROUTING.
1.1.2. Tablas
Una tabla es una indicación al sistema de filtros, que debe

manejar una cierta cantidad de reglas internas y "cadenas".
Existen tres tablas, por defecto, llamadas filter, mangle y nat.
• Filter
La tabla filter es usada para filtrado general de paquetes.
Está compuesto por las cadenas INPUT (entrada),
OUTPUT (salida) y FORWARD (reenvió o traspaso). Esta
cadena hace posible permitir cierto tipo de conexión a
cierto tipo de interfaces desde ciertos hosts.

Una de las ventajas principales es que esta extensión es

rápida y eficiente.
• Nat
La tabla nat es usada para paquetes que se deben
reenviar (entre interfaces), además de modificar o
"traducir" su comportamiento. NAT significa Network
Address Translation (Traducción de Direcciones de Red) y
es usado, principalmente, en IP Masquerading y Port
Forwarding. Está compuesta por las cadenas
PREROUTING (pre-ruta), POSTROUTING (post-ruta) y
OUTPUT (salida).
Algunos de los usos típicos para la tabla Nat son NAT de

Origen (Source NAT), Nat de Destino (Destination NAT),
Enmascaramiento (IP Masquerading) y Proxys
Transparentes (una forma especial de Destination NAT).
• Mangle
La tabla mangle permite alterar paquetes y tramas. Es,
generalmente, usada para enrutamiento avanzado (por
ejemplo, TOS) y consiste en las reglas PREROUTING y
OUTPUT.
A través de esta tabla, es posible alterar el paquete (y los

pertenecientes a la misma conexión) o algunos de los
datos pertenecientes a él.
• Raw
Esta última tabla está destinada para realizar excepciones
al seguimiento de los paquetes a medida que entran y
salen, es decir, mediante una regla configurada en esta
tabla se puede realizar la transferencia de un paquete sin
que se verifique la entrada o salida de dicho paquete,
finalmente, trabaja con las cadenas PREROUTING y
OUTPUT.
1.1.3. Extensiones
Dentro de Netfilter, existen distintas extensiones, que son

utilizadas en solo dos instancias: Coincidencias (matches) y
Acciones (targets). Algunas de estas extensiones son
particulares para cada una de las tablas.
• Coincidencias (Matches)
Una coincidencia (match) ocurre cuando un paquete

corresponde al indicado dentro de alguna de las cadenas.
Puede ser a través del protocolo (TCP), algún puerto en
particular (22), un usuario propietario del paquete

80
(OWNER), el estado de la transacción (INVALID), por

ejemplo. O la combinación de todos ellos, en particular.
• Acciones (Targets)
Se indican como el destino final del proceso de un

paquete, o de una transacción. Indica, realmente, "qué
hacer " una vez que se ha cumplido la coincidencia.
Algunas de las acciones pueden ser desechar el paquete

por completo (DROP), retransmitirlo (MIRROR), o bien,
indicar a través de ksyslogd (la utilidad de kernel para
logging) que una coincidencia fue exitosa (LOG).
De por sí, corresponde solo una acción por coincidencia,

aunque con un poco de práctica, es posible agregar más
de una.
1.1.4. Entendiendo las Reglas del Juego
Como se indicó, anteriormente, para el uso de Netfilter, es

necesario utilizar, además de los módulos del kernel, la utilidad
IPTables.
A través del comando iptables, es posible

insertar/eliminar/modificar reglas dentro de Netfilter. Algunas de
las características de esta herramienta son:
• Permite el uso de distintas tablas de IP. Mientras tanto,

sólo existen 4 (raw, filter, nat y mangle), pero permite el
manejo de futuras tablas.
• Permite el uso de plug-ins para nuevos coincidencias y

acciones. Así, no es necesario modificar los módulos o
IPtables para agregar una extensión adicional.
• Nativamente, puede manejar IPv4 e IPv6 usando la misma

librería y el mismo código.
1.2. IPTables
Iptables -t [tabla] -[operación] [cadena] [descripción de la coincidencia] -j

[acción]
Un comando básico de IPTables está compuesto de 5 partes, que son:
• La tabla a usar (raw, filter, nat o mangle)

• La cadena a usar, que puede ser una de las cadenas por defecto
(INPUT, por ejemplo) o bien cadenas creadas por el usuario

• La operación (insertar/modificar/eliminar/etc.)
• Una descripción de los paquetes que deben coincidir con esta regla
(la "coincidencia")
• Un destino (target) para esta regla particular
NOTA1: Cuando no se indica la tabla a usar, por defecto se usa la

tabla "filter".
NOTA 2: en algunas publicaciones, pueden encontrar ejemplos del tipo

# iptables -t tabla -j [accion] -[operacion] [etc/etc…] lo que indica que el
orden no altera el producto
1.2.1. Operaciones básicas
Algunas de las operaciones básicas sobre las cadenas (existen

más) son:
• A (add): agrega una regla al final de la cadena.

• I (insert): agrega una regla al principio de la cadena.
• R (replace): reemplaza una regla por otra.
• D (delete): elimina una regla.
• F (flush): elimina todas las reglas de la cadena. Es
equivalente a borrar las reglas una por una.
• L (list): muestra las reglas dentro de la cadena.
1.2.2. Coincidencias básicas
Para indicar a Netfilter qué hacer con los paquetes de una

transacción, se debe crear una coincidencia, lo más precisa
posible. La idea es que la coincidencia sea inequívoca, tanto
como para quien creó la regla (usuario) como para el kernel.
Algunas coincidencias básicas son
• -p [protocolo]: indica qué protocolo debe realizarse la

comprobacion. Algunos de los valores son tcp, udp, icmp o
all. Tambien, puede ser un número, o alguno de los
indicados en /etc/protocols.
• -s [ip/mascara]: indica la dirección IP del origen de la
transacción. Puede indicarse, también de la forma
IP/máscara para decirle a Netfilter que es un grupo de hosts.
• -d [ip/mascara]: indica la dirección IP destino de la
transacción.
• -i [interfaz]: indica la interfaz de entrada desde donde se
recibió la transacción o los paquetes. (Nota: solo usado por
las cadenas INPUT, FORWARD y PREROUTING)
• -o [interfaz] : indica la interfaz de salida de la transacción
(Nota: sólo usada por OUTPUT, FORWARD y
POSTROUTING)

82
• --sport: Indica el puerto de origen de la transacción.

• --dport: Indica el puerto de destino de la transacción.
Nota: --sport y --dport son usados cuando se indica que el

protocolo es tcp o udp solamente)
1.2.3. Acciones básicas
Algunas acciones son comunes de todas las cadenas. Otras

son específicas.
Algunas acciones básicas son:
• ACCEPT: acepta el paquete/transacción.

• DROP: rechaza el paquete/transacción
• REJECT: rechaza el paquete/transacción. A diferencia de
DROP, notifica al emisor que el paquete/transacción fue
descartado.
• LOG: indicará que el resultado obtenido al aplicar una
determinada regla deberá ser guardado en un reporte.
1.2.4. Ejemplos
Ahora, algunos ejemplos simples. Estos ejemplos usan la tabla

"filter", ya que es la más fácil de utilizar. Son algo básicos, pero
servirán de apoyo para el próximo punto.
• Permitir el trafico ICMP de entrada

Iptables -A INPUT -p icmp -j ACCEPT
• Permitir que la interfaz eth0 pueda enviar paquetes ICMP

Iptables -A OUTPUT -p icmp -o eth0 -j ACCEPT
• Denegar (DROP) la conexión al puerto 25, protocolo tcp, de

la interfaz eth1
Iptables -A INPUT -i eth1 -p tcp --dport 25 -j DROP
• Rechazar (REJECT) la conexión al puerto 65000, protocolo

udp, de la interfaz eth0, desde los computadores de la LAN
(red local) del tipo 192.168.1.X/255.255.255.0
Iptables -A INPUT -i eth0 -p udp --dport 65000 -s
192.168.1.0/255.255.255.0 -j REJECT
• Denegar el tráfico desde la eth0 a la eth1 (FORWARD)

Iptables -A FORWARD -i eth0 -o eth1 -j DROP
• Denegar el tráfico desde la eth0 a la eth1 del protocolo tcp

Iptables -A FORWARD -i eth0 -o eth1 -p tcp -j DROP
• Le estás diciendo que si esa mac tiene un ip DIFERENTE (!)

al 192.168.1.22, descarte los paquetes.

Iptables -t nat -A PREROUTING -m mac --mac-source

00:16:76:8f:DE:F2 -i eth1 –s ! 192.168.1.22 -j DROP
2. Filtrado de paquetes entrantes/salientes

Como se muestra en la Fig. 2, el equipo con dirección IP 10.0.0.1 puede
hacer ping al equipo con dirección IP 10.0.0.2. En este caso, se usan los
mensajes de control Echo Request (Tipo 8) y Echo Reply (Tipo 0) del
protocolo ICMP.
Fig. 2. Comando ping
2.1. Política predeterminada ACEPTAR TODO
Para filtrar la respuesta al comando ping podemos realizar lo siguiente:
• Filtrar el paquete entrante: echo-request

En el equipo 10.0.0.2, ejecutamos:
Centos: ~# iptables -A INPUT -p icmp --icmp-type 8 -s 10.0.0.1 -j DROP

84
Fig. 3. Filtrando echo-request
Centos: ~# iptables -L
Chain INPUT (policy ACCEPT)
Target prot opt source destination
DROP icmp -- 10.0.0.1 anywhere icmp echo-
request
Chain FORWARD (policy ACCEPT)

Chain OUTPUT (policy ACCEPT)

Debian: ~#
• Filtrar el paquete saliente: echo-reply

Centos: ~# iptables -A OUTPUT -p icmp --icmp-type 0 -d 10.0.0.1 -j

DROP
Fig. 3. Filtrando echo-reply



DROP icmp -- anywhere 10.0.0.1 icmp echo-
reply
Centos: ~#
2.2. Politica predeterminada DENEGAR TODO
Para permitir que la respuesta al comando ping ingrese al equipo,

podemos realizar lo siguiente:
Centos: ~# iptables -P INPUT DROP
Centos: ~# iptables -P OUTPUT DROP
Centos: ~# iptables -A INPUT -i lo -j ACCEPT
Centos: ~# iptables -A OUTPUT -o lo -j ACCEPT
Centos: ~# iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT
Centos: ~# iptables -A OUTPUT -p icmp --icmp-type 0 -j ACCEPT
3. Filtrado de paquetes salientes/entrantes

Como se muestra en la Fig. 4, el equipo con dirección IP 10.0.0.2 puede
hacer ping al equipo con dirección IP 10.0.0.1
Fig. 4. Comando ping
3.1. Política predeterminada ACEPTAR TODO
En el caso de que se desee bloquear el comando ping desde la máquina

firewall, podemos hacer lo siguiente:
• Filtre el paquete saliente: echo-request

Centos: ~# iptables -A OUTPUT -p icmp --icmp-type 8 -d 10.0.0.1

-j DROP


86

DROP icmp -- anywhere 10.0.0.1 icmp echo-
request
Centos: ~#
Centos: ~# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
Ping: sendmsg: Operation not permitted
--- 10.0.0.1 Ping statistics ---

4 packets transmitted, 0 received, 100% packet loss, time
3000ms
Centos: ~#
• Filtre el paquete entrante: echo-reply

Centos: ~# iptables -A INPUT -p icmp --icmp-type 0 -s 10.0.0.1

-j DROP
DROP icmp -- 10.0.0.1 anywhere icmp echo-
reply


Centos: ~#
Centos: ~# ping 10.0.0.1

8 packets transmitted, 0 received, 100% packet loss, time
6998ms
Centos: ~#
3.2. Politica predeterminada DENEGAR TODO
Para permitir que la peticion del comando ping salga del equipo,
podemos realizar lo siguiente:
Centos: ~# iptables -P INPUT DROP
Centos: ~# iptables -P OUTPUT DROP
Centos: ~# iptables -A INPUT -i lo -j ACCEPT
Centos: ~# iptables -A OUTPUT -o lo -j ACCEPT
Centos: ~# iptables -A OUTPUT -p icmp --icmp-type 8 -j ACCEPT
Centos: ~# iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT

Autoevaluación
1. ¿Cuáles son las cadenas de la tabla filter?
(a) POSTROUTING, OUTPUT y INPUT
(b) OUTPUT,FORWARD y PREROUTING
(c) PREROUTING, OUTPUT y POSTROUTING
(d) INPUT, OUTPUT y FORWARD
2. Asumiendo que la política global es aceptar todo lo que no se deniega

de forma explícita. Implementar las siguientes reglas de filtrado de
paquetes a mi maquina local 200.60.172.252. Evite ciertos ataques
spoof colocando filtros antispoof para los paquetes provenientes de la
siguiente red 172.16.0.0/255.255.0.0
(a) iptables -A INPUT -s 172.16.0.0/27 -d 200.60.172.252 -j DROP
(b) iptables -A INPUT -s 200.60.172.252 -d 172.16.0.0/24 -j DROP
(c) iptables -A INPUT -s 172.16.0.0/16 -d 200.60.172.252 -j DROP
(d) iptables -A OUTPUT -s 172.16.0.0/24 -d 200.60.172.252 -j DROP
(e) iptables -A FORWARD -s 172.16.0.0/24 -d 200.60.172.252 -j

DROP
3. ¿Listas cada una de las arquitecturas de Firewall?

88

SEMANA
9
firewall II
TEMA
• Comprender el funcionamiento del filtrado de paquetes reenviados.
• Comprender el funcionamiento del enmascaramiento.
• Comprender el uso de la politica predeterminada DROP.
CONTENIDOS
• Filtrado de paquetes reenviados.

90
Filtrado de paquetes reenviados
1.1. Permitir la salida de la LAN a Internet
Política predeterminada: ACEPTAR TODO
Fig. 1. Red
• Verificamos que las estaciones de trabajo estén correctamente

configuradas.
Debian: ~# ifconfig eth0
Eth0 Link encap: Ethernet Hwaddr 00:00:21:B6:27:22
Inet addr: 10.0.0.2 Bcast: 10.255.255.255
Mask:255.0.0.0
Inet6 addr: fe80: 200:21ff:feb6:2722/64 Scope: Link
UP BROADCAST RUNNING MULTICAST MTU: 1500 Metric: 1
RX packets: 71 errors: 0 dropped: 0 overruns: 0
frame:0
TX packets: 464 errors: 0 dropped:0 overruns:0
carrier:0
Collisions: 0 txqueuelen: 1000
RX bytes: 5552 (5.4 KiB) TX bytes: 50668 (49.4 KiB)
Interrupt: 11 Base addresses: 0x6400
Debian: ~# route –n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0
eth0
0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0
eth0
Debian: ~# cat /etc/resolv.conf
Search home
Nameserver 208.67.222.222
Nameserver 208.67.220.220
#nameserver 200.48.225.130
#nameserver 200.48.225.146
Debian: ~# host www.google.com

Nameserver not responding

www.google.com A record not found, try again
Debian: ~#
Como se puede observar, los parámetros de red están

correctamente configurados, pero al realizar una consulta DNS no
hay respuesta, esto debido a que el firewall no está configurado.
• Configuración del firewall para permitir la salida a Internet de la

LAN.
[root@FW ~]# Echo 1 > /proc/sys/net/ipv4/ip_forward

[root@FW ~]# Iptables –t nat –A POSTROUTING –s 10.0.0.0/8 –j SNAT
–to-source 192.168.1.3
[root@FW ~]# Iptables –L
target prot opt source destination
Chain FORWARD (policy ACCEPTS)


[root@FW ~]# Iptables –L –t nat
Chain PREROUTING (policy ACCEPT)
Chain POSTROUTING (policy ACCEPT)

SNAT all -- 10.0.0.0/8 anywhere to: 192.168.1.3

[root@FW ~]#
• Después de configurar el firewall podemos salir a Internet.

Debian: ~# ping 10.0.0.1
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.914 ms

2 packets transmitted, 2 received, 0% packet loss, time 1001ms
Rtt min/avg/max/mdev = 0.728/0.821/0.914/0.093 ms
Debian: ~# ping 192.168.1.2
--- 192.168.1.2 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1001ms
Rtt min/avg/max/mdev = 1.165/1.226/1.287/0.061 ms
Debian: ~# host www.google.com
www.google.com CNAME google.navigation.opendns.com

92
Google.navigation.opendns.com A 208.67.219.230
Google.navigation.opendns.com A 208.67.219.231
Debian: ~#
1.2. Permitir el ingreso desde Internet hacia la LAN
Política predeterminada: ACEPTAR TODO
• Permitir que los paquetes se reenvíen al Servidor HTTP de la LAN.
Fig. 2. Red
• Si no se configura el Firewall los paquetes entrantes desde Internet

no podrán ingresar al Servidor HTTP (Ver Fig. 3).
• Ejecute en el Servidor Firewall los siguientes comandos:
[root@FW ~]# Iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -

j DNAT --to-destination 10.0.0.2
[root@FW ~]# Iptables -L -t nat

DNAT tcp -- anywhere anywhere tcp dpt: http to: 10.0.0.2

SNAT all -- 10.0.0.0/8 anywhere to: 192.168.1.3

[root@FW ~]#

Fig. 3. Acceso denegado
• Como se muestra, ya se puede ingresar al Servidor HTTP

94
Fig. 4. Acceso permitido

1.3. Permitir el ingreso desde Internet hacia la LAN
Política predeterminada: DENEGAR TODO
• Creación de script básico:
[root@FW ~]# Cat fw.sh

Iptables -F
Iptables -X
Iptables -Z
Iptables -t nat F
Iptables -P INPUT ACCEPT

Iptables -P OUTPUT ACCEPT
Iptables -P FORWARD DROP
Modprobe ip_tables
Modprobe iptable_nat
Modprobe ip_conntrack
Modprobe ip_conntrack_ftp
Modprobe ip_conntrack_netbios_ns
Modprobe ip_nat_ftp
Modprobe ipt_LOG
Modprobe ipt_MARK
Modprobe ipt_MASQUERADE
Modprobe ipt_REDIRECT
Modprobe ipt_TOS
Modprobe ipt_REJECT
Modprobe ipt_limit
Modprobe ipt_mac
Modprobe ipt_state
Modprobe ipt_multiport
Modprobe ipt_tos
Modprobe ipt_mark
Modprobe x_iptable
Modprobe iptable_filter
Iptables -A FORWARD -j LOG
Echo 1 > /proc/sys/net/ipv4/ip_forward

Iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -j SNAT --to-source
192.168.1.3
[root@FW ~]#
[root@FW ~]# Iptables -L
Chain FORWARD (policy DROP)

LOG all -- anywhere anywhere LOG level warning


[root@FW ~]# Iptables -L -t nat


[root@FW ~]#
• Por el momento, están bloqueados los paquetes reenviados; por lo

tanto, no hay salida de la LAN a Internet y tampoco pueden
ingresar al Servidor HTTP
• Permitir consultas a los Servidores DNS
[root@FW ~]# Iptables -A FORWARD -i eth1 -p tcp --dport 53 -j ACCEPT

[root@FW ~]# Iptables -A FORWARD -i eth1 -p udp --dport 53 -j ACCEPT
[root@FW ~]# Iptables -A FORWARD -i eth0 -p tcp --sport 53 -j ACCEPT
[root@FW ~]# Iptables -A FORWARD -i eth0 -p udp --sport 53 -j ACCEPT
[root@FW ~]# Iptables -L

ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp spt:domain
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT udp -- anywhere anywhere udp spt:domain

[root@FW ~]#
[root@FW ~]# cat /proc/net/ip_conntrack
tcp 6 431999 ESTABLISHED src=192.168.1.2 dst=192.168.1.3 sport=1456
dport=22 packets=2019 bytes=182276 src=192.168.1.3 dst=192.168.1.2 sport=22
dport=1456 packets=2617 bytes=180216 [ASSURED] mark=0 use=1 rate=100
udp 17 6 src=10.0.0.2 dst=10.255.255.255 sport=138 dport=138 packets=2
bytes=500 [UNREPLIED] src=10.255.255.255 dst=10.0.0.2 sport=138 dport=138
packets=0 bytes=0 mark=0 use=1 rate=70
bytes=340 src=208.67.222.222 dst=192.168.1.3 sport=53 dport=1068 packets=5
bytes=607 [ASSURED] mark=0 use=1 rate=80
[root@FW ~]#
96
• Esto no es suficiente para que desde la LAN puedan navegar

tcp 6 52 SYN_RECV src=10.0.0.2 dst=208.111.148.94 sport=1035 dport=80 packe
ts=1 bytes=60 src=208.111.148.94 dst=192.168.1.3 sport=80 dport=1035 packets=5 b
ytes=320 mark=0 use=1 rate=10
udp 17 6 src=10.0.0.2 dst=208.67.222.222 sport=1070 dport=53 packets=1 byte
s=60 src=208.67.222.222 dst=192.168.1.3 sport=53 dport=1070 packets=1 bytes=108
mark=0 use=1 rate=30
s=60 src=208.67.222.222 dst=192.168.1.3 sport=53 dport=1071 packets=1 bytes=92 m
ark=0 use=1 rate=20
udp 17 156 src=10.0.0.2 dst=208.67.222.222 sport=1069 dport=53 packets=2 by
tes=120 src=208.67.222.222 dst=192.168.1.3 sport=53 dport=1069 packets=2 bytes=2
00 [ASSURED] mark=0 use=1 rate=20
s=60 src=208.67.222.222 dst=192.168.1.3 sport=53 dport=1072 packets=1 bytes=108
mark=0 use=1 rate=30
udp 17 133 src=10.0.0.2 dst=208.67.222.222 sport=1068 dport=53 packets=6 by
tes=400 src=208.67.222.222 dst=192.168.1.3 sport=53 dport=1068 packets=6 bytes=6
99 [ASSURED] mark=0 use=1 rate=20
[root@FW ~]#
• Como se muestra, las únicas conexiones ASEGURADAS son las

consultas DNS.
• Permitir la salida de las peticiones al puerto 80
[root@FW ~]# iptables -A FORWARD -i eth1 -p tcp --dport 80 -j ACCEPT

[root@FW ~]# iptables -A FORWARD -i eth0 -p tcp --sport 80 -j ACCEPT
[root@FW ~]# iptables -L

ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp spt:http


[root@FW ~]#

tcp 6 7 TIME_WAIT src=10.0.0.2 dst=208.111.148.94 sport=1112 dport=80
packets=5 bytes=755 src=208.111.148.94 dst=192.168.1.3 sport=80 dport=1112
packets=5 bytes=1596 [ASSURED] mark=0 use=1 rate=570
tcp 6 8 TIME_WAIT src=10.0.0.2 dst=66.29.38.249 sport=1114 dport=80
packets=6 bytes=850 src=66.29.38.249 dst=192.168.1.3 sport=80 dport=1114
• Permitir al acceso al Servidor HTTP
[root@FW ~]# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT

--to-destination 10.0.0.2
[root@FW ~]# iptables -A FORWARD -i eth0 -p tcp --dport 80 -d 10.0.0.2 -j
ACCEPT
[root@FW ~]# iptables -A FORWARD -i eth1 -p tcp --sport 80 -s 10.0.0.2 -j
ACCEPT

ACCEPT tcp -- anywhere 10.0.0.2 tcp dpt:http

[root@FW ~]# iptables -L -t nat
DNAT tcp -- anywhere anywhere tcp dpt:http to:10.0.0.2

98

SNAT all -- 10.0.0.0/8 anywhere to:192.168.1.3

[root@FW ~]#
• Permitir sesiones remotas en el Servidor HTTP
[root@FW ~]# iptables -A FORWARD -d 192.168.1.10 -p tcp --dport 22 -d

10.0.0.2 -j ACCEPT
[root@FW ~]# iptables -A FORWARD -p tcp --dport 22 -d 10.0.0.2 -j ACCEPT
[root@FW ~]# iptables -A FORWARD -i eth1 -p tcp --sport 22 -s 10.0.0.2 -j
ACCEPT
[root@FW ~]#

ACCEPT tcp -- anywhere 10.0.0.2 tcp dpt:http
ACCEPT tcp -- 10.0.0.2 anywhere tcp spt:http
ACCEPT tcp -- anywhere 10.0.0.2 tcp dpt:ssh
ACCEPT tcp -- 10.0.0.2 anywhere tcp spt:ssh

[root@FW ~]# iptables -L -t nat
DNAT tcp -- anywhere anywhere tcp dpt:http to:10.0.0.2
DNAT tcp -- anywhere 192.168.1.10 tcp dpt:ssh to:10.0.0.2

SNAT all -- 10.0.0.0/8 anywhere to:192.168.1.3

[root@FW ~]#
dport=22 packets=4158 bytes=374816 src=192.168.1.3 dst=192.168.1.2 sport=22
dport=1456 packets=5267 bytes=453188 [ASSURED] mark=0 use=1 rate=940


dport=22 packets=23 bytes=2379 src=10.0.0.2 dst=192.168.1.2 sport=22 dport=2623
[root@FW ~]#
[root@FW ~]# iptables -L -n


LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:53
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:53
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:80
ACCEPT tcp -- 0.0.0.0/0 10.0.0.2 tcp dpt:80
ACCEPT tcp -- 10.0.0.2 0.0.0.0/0 tcp spt:80
ACCEPT tcp -- 0.0.0.0/0 10.0.0.2 tcp dpt:22
ACCEPT tcp -- 10.0.0.2 0.0.0.0/0 tcp spt:22

[root@FW ~]#
[root@FW ~]# iptables -L -n -t nat
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 to:10.0.0.2
DNAT tcp -- 0.0.0.0/0 192.168.1.10 tcp dpt:22 to:10.0.0.2

SNAT all -- 10.0.0.0/8 0.0.0.0/0 to:192.168.1.3

[root@FW ~]#

100
Autoevaluación
1. ¿Cuál es la política predeterminada del firewall?
2. El objetivo (target) particular REJECT es:
(a) El paquete salta el resto de verificaciones de la regla y continúa

hacia su destino.
(b) Al paquete se le deniega el acceso y no envía nada al equipo que

envió el paquete.
(c) Al paquete se le deniega el acceso y envía un mensaje de error al

equipo que envió el paquete.
(d) El paquete es reenviado a otro host.
(e) El paquete crea una nueva conexión.
3. ¿Cuál es el objetivo que se aplica a una determinada regla que permita

enmascarar todos los paquetes que proviene de una red privada que
salen por un enlace ppp0 con destino a Internet?
(a) SNAT
(b) REDIRECT
(c) MASQUERADE
(d) DNAT
(e) NAT

SEMANA
10
firewall III
TEMA
• Comprender el funcionamiento del filtrado de paquetes usando estados de conexión.
CONTENIDOS
• Estados de conexión.
• Permitiendo paquetes entrantes/salientes.
• Permitiendo paquetes salientes/entrantes.
• Permitiendo paquetes reenviados.

102
ESTADOS DE CONEXIÓN
IPTables los usa en base a cómo trabaja el protocolo TCP y permite definir, de
forma más especifica, reglas en base a si una conexión es nueva o si una
conexión ha generado otra. Esto solo es aplicable al protocolo TCP, ya que
este funciona definiendo 3 vías durante una conexión, también llamado “Three-
way handshake”.
Tomando como base lo anterior, IPTables utiliza los siguientes 3 estados

(states):
• New – Nos indica que el paquete es el primero que vemos cuando un

sistema se trata de conectar a otro enviando un paquete TCP marcado
como SYN (Syncrhonize).
• Related – Una conexión se considera "relacionada" cuando esta ligada

a otra conexión ya "establecida".
• Established – Ha visto tráfico en ambas direcciones y por tanto admitirá

continuamente los paquetes de ese flujo cuando el sistema que inició la
conexión recibe el SYN-ACK (se establece la conexión entre ambos
sistemas).
• Invalid – implica que el paquete no puede ser identificado o que no tiene

ningún estado.
Fig. 1. Estados de conexión

1. Permitiendo paquetes entrantes/salientes

• Permitir el paquete entrante: echo-request

centos:~# iptables -A INPUT –m state --state NEW -p icmp --

icmp-type 8 -s 10.0.0.1 -j ACCEPT
centos:~# iptables –A OUTPUT –m state --state ESTABLISHED –j
ACCEPT
Fig. 2. Permitir paquete echo-request entrante
centos:~# iptables -L
Chain INPUT (policy DROP)
ACCEPT icmp -- 10.0.0.1 anywhere state NEW icmp echo-
request

Chain OUTPUT (policy DROP)

ACCEPT all -- anywhere anywhere state ESTABLISHED
debian:~#

104
2. Permitiendo paquetes salientes/entrantes

Fig. 3. Permitir paquete echo-request saliente
• Permitir el paquete saliente: echo-request

centos:~# iptables -A OUTPUT –m state --state NEW -p icmp --

icmp-type 8 -d 10.0.0.1 -j ACCEPT
centos:~# iptables –A INPUT –m state --state ESTABLISHED –j
ACCEPT
centos:~# iptables -L
Chain INPUT (policy DROP)
ACCEPT all -- anywhere anywhere state ESTABLISHED

Chain OUTPUT (policy DROP)

ACCEPT icmp -- anywhere 10.0.0.1 state NEW icmp echo-
request
centos:~#

3. Permitiendo paquetes reenviados
Fig. 4. Red
• Script que usa el estado de conexión
[root@FW ~]# cat fw1.sh

iptables -F
iptables -X
iptables -Z
iptables -t nat -F
iptables -P INPUT ACCEPT

iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
modprobe ip_tables
modprobe iptable_nat
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ip_conntrack_netbios_ns
modprobe ip_nat_ftp
modprobe ipt_LOG
modprobe ipt_MARK
modprobe ipt_MASQUERADE
modprobe ipt_REDIRECT
modprobe ipt_TOS
modprobe ipt_REJECT
modprobe ipt_limit
modprobe ipt_mac
modprobe ipt_state
modprobe ipt_multiport
modprobe ipt_tos
modprobe ipt_mark
modprobe x_iptable
modprobe iptable_filter
iptables -A FORWARD -j LOG
echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -j SNAT --to-
source 192.168.1.3

106
iptables -A FORWARD –m state --state NEW -i eth1 -p tcp --dport

53 -j ACCEPT
iptables -A FORWARD –m state --state NEW -i eth1 -p udp --dport
53 -j ACCEPT
80 -j ACCEPT
80 -d 10.0.0.2 -j ACCEPT
iptables -A FORWARD –m state --state NEW -p tcp --dport 22 -d
10.0.0.2 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j

ACCEPT
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT

--to-destination 10.0.0.2
iptables -t nat -A PREROUTING -d 192.168.1.10 -p tcp --dport 22
-j DNAT --to-destination 10.0.0.2
[root@FW ~]#

Autoevaluación
1. ¿Cuáles son los posibles estados de conexión de los paquetes?
(a) Established, New, Related y Reject

(b) Invalid, Related, Redirect y Established
(c) New, Established, Related e Invalid
(d) Invalid, Replace, New y Established
2. El estado NEW específica:
3. Que el paquete no está asociados a ninguna conexión conocida y puede

estar defectuoso.
(a) Que el paquete se asocia a una conexión existente.

(b) Que el paquete crea una nueva conexión.
(c) Que el paquete crea una nueva conexión, pero asociada a una
conexión existente.
4. La tabla nat ejecuta:
(a) Operaciones de traducción de direcciones de red.

(b) Operaciones de bloqueo o aceptación de paquetes.
(c) Modificaciones en los campos de las cabeceras de los paquetes.
(d) Altera los paquetes que ingresan al sistema.

108

SEMANA
11
Proxy application firewall I
TEMA
Describir el uso del Servidor Proxy Squid.
• Comprender el funcionamiento del Servidor Proxy.
CONTENIDOS
• Introducción.
• Squid.

110
INTRODUCCIÓN
Un servidor Proxy es un software que realiza tareas de servidor

intermediario. El caso más común es utilizarlo para compartir Internet en
ámbitos donde se posee una única conexión a Internet y varias
computadoras.
El servidor Proxy se conecta, directamente, a Internet y por otra interfaz, a

la red interna, de modo que todos los pedidos a Internet de las
computadoras pertenecientes a la LAN pasan a través del Proxy y es este
en realidad el que hace las conexiones hacia la web y luego entrega las
respuestas a los hosts correspondientes.
Fig. 1. Servidor Proxy
Una de las funciones principales de un servidor Proxy es actuar como cache

de contenido, principalmente, web (http). Esto mejora el desempeño de una
red consumiendo menos recursos, debido que, frente a un nuevo pedido de
un sitio que ya ha sido realizado, en vez de generar tráfico hacia Internet, se
entrega el sitio cuyo contenido se encuentra almacenado en el servidor.
1. SQUID
Squid es un software de libre distribución para realizar la tarea de un
servidor Proxy con prestaciones muy profesionales. Suele acompañar a las
distribuciones más habituales, aunque también puede obtenerse de su sitio
oficial (http://www.squid-cache.org/). Actualmente, la versión estable es la
2.6 STABLE18.
Squid puede funcionar como Servidor Intermediario (Proxy) y caché de

contenido de red para los protocolos HTTP, FTP, GOPHER y WAIS, Proxy
de SSL, caché transparente, caché de consultas DNS y otras muchas más
como filtración de dominios y control de acceso por IP y por usuario. Provee

potentes opciones para tener un completo control sobre los sitios que se
visitan, así como para filtrar, permitir o bloquear el acceso de determinados
equipos, IP’s, dominios, etc.
Instalación de Squid: yum install squid
2.1. Funcionamiento
Squid realiza el almacenamiento de objetos utilizando diferentes

algoritmos:
• LRU (política por defecto): Se eliminan de la caché los objetos que

no han sido accedidos en mucho tiempo, manteniendo en la caché
los que han sido utilizado más recientemente.
• LFUDA: Los objetos más solicitados permanecen en el caché sin
importar su tamaño, de modo que un objeto grande que se solicite
con mayor frecuencia impedirá que se pueda hacer caché de
objetos pequeños que se soliciten con menor frecuencia.
• GDSF: Optimiza la eficiencia por objeto, manteniendo en el caché
los objetos pequeños más solicitados; descarta del caché objetos
grandes que sean solicitado con frecuencia.
2.2. Configuración del servidor
La configuración del servidor Proxy Squid se realiza en un único

archivo de texto plano por lo general, ubicado en
/etc/squid/squid.conf. La sintaxis en este archivo debe comenzar en
la primera columna, sin dejar espacios.
• Nombre del Host y Puerto

La primera configuración básica debe ser el nombre y los puertos
del host. Por defecto, SQUID escucha en el puerto.
visible_hostname proxy
http_port 3128
• Memoria Usada
Para especificar a Squid qué cantidad de memoria debe usar hay
que añadir la siguiente línea al fichero de configuración:
cache_mem 8 MB
• Tamaño de la memoria caché

Aquí se fija el directorio y el espacio que se utilizará del disco duro
para almacenar las páginas. Por defecto, SQUID usara 100 MB, y
lo almacenará por defecto en 16 subdirectorios de primer nivel y en
256 subdirectorios de segundo nivel.
cache_dir ufs /var/cache/squid 100 16 256
• Tiempo de vida de la caché

112
Podemos configurar el tiempo que los objetos permanecerán

almacenados en el servidor.
reference_age 1 month
• Control de acceso
Es necesario establecer listas de control de acceso (acl) que
definan una red o bien ciertas máquinas en particular. A cada acl se
le asignará una regla de control de acceso (acr) que funcionará
bloqueando o permitiendo el acceso a través de SQUID.
Comúnmente, las acl se definen y las acr se aplican de la siguiente
manera:
Acl [nombre de la lista] src/dst [ips que componen la lista]

http_access allow/deny [nombre de la lista]
Para el siguiente ejemplo, la red 192.168.0.0/24 llamada LAN1

tendrá permitido acceder al Proxy:
acl LAN1 src 192.168.0.0/255.255.255.0

http_access allow LAN1
Además de direcciones IP’s, en las acl es posible definir nombres

de dominios y puertos utilizando dstdomain y port de la siguiente
manera:
acl educativas dstdomain edu.pe

acl diario dstdomain diario.com
acl safeports port 443
http_access deny diario

http_access allow educativas
http_access allow safeports
Es importante tener en cuenta que las acl educativas y diario no

hubiesen coincidido, si se visitaban sitios como fich.unl.edu.pe o
deportes.clarin.com. Para bloquear también los subdominios, se
debe utilizar el punto (.) como comodín antes del dominio:
acl educativas dstdomain .edu.pe

acl diario dstdomain .diario.com
Existe una acl que debe estar configurada para que SQUID
funcione:
acl all src 0.0.0.0/0.0.0.0
Esta acl, a diferencia de las demás, debe tener obligatoriamente la

etiqueta all.
Coincidencia en las acl
Para que se produzca una coincidencia (match) en una acl, se

utiliza la función OR, por ejemplo:

acl ips src 192.168.0.10 192.168.0.11 192.168.0.16
Cuando la ip origen sea 192.168.0.11, la coincidencia se dará luego

de la segunda dirección ip, y la acl será considerada verdadera. Por
esta razón, se recomienda incluir las opciones más comunes al
comienzo, para acelerar el proceso de evaluación.
Coincidencias en las acr
Para que una acr coincida, se utiliza la función AND. Para el

ejemplo:
http_access allow educativas safeport
Debe accederse a sitios .edu.pe al puerto 443 para que sea

permitido el acceso.
Parámetros extras
Otro símbolo reservado consiste en la utilización del signo de

admiración de cierre: !. Se utiliza como negación de una
determinada acl, para el ejemplo!,LAN1 significa que el acceso a
Squid es para todos los que no formen parte de LAN1.
2.3. Configuración de los clientes
2.3.1. Navegador konqueror
Desde un equipo cliente (Debian Linux):

• Ejecute el Konqueror.

114
Fig. 2. Navegador Konqueror
• Haga clic en Preferencias → Configurar Konqueror, desde la

barra de menú. (Ver Fig. 3).

Fig. 3. Configuración de Konqueror
• Haga clic en la pestaña Proxy.
• Haga clic en Especificar de forma manual, la configuración

del proxy.
• Haga clic en el botón Configuración. (Ver Fig. 4).

116
Fig. 4. Configuración del Proxy
• Ingrese la dirección IP del servidor Proxy y el número del

puerto.
• Haga clic en el botón Aceptar.
• Haga clic en el botón Aplicar.
2.4. Ejercicios
2.4.2. Caso 1
Considerando que se dispone de una red 192.168.1.0/255.255.255.0,

se desea permitir la salida a Internet de la red local.

Fig. 5. LAN
• Establecer una lista de control de acceso para la red local:

o Definir la IP correspondiente a la red y la máscara de la sub-red:
acl LAN src 192.168.1.0/255.255.255.0
• Establecer una regla de control para la red local:

o Regla que establece acceso permitido a Squid a toda la red
local:
http_access allow LAN
2.4.3. Caso 2

se desea permitir la salida a Internet de algunos equipos.
o Definir una ACL especificando un archivo, el cual contiene una

lista de direcciones IP:
acl permitidos src "/etc/squid/permitidos"
Contenido del archivo /etc/squid/permitidos:

192.168.1.10
192.168.1.12
192.168.1.13
192.168.1.15
192.168.1.16
192.168.1.20
192.168.1.40
• Establecer la regla de control:

o Regla que establece acceso permitido a Squid a la ACL
denominada permitidos:
http_access allow permitidos
http_access deny all

118
2.4.4. Caso 3

se desea denegar la salida a Internet de algunos equipos.
• Establecer una lista de control de acceso para la red local:

o Definir la IP correspondiente a la red y la máscara de la sub-red:
acl LAN src 192.168.1.0/255.255.255.0

lista de direcciones IP:
acl denegados src "/etc/squid/denegados"
Contenido del archivo /etc/squid/denegados:

192.168.1.31
192.168.1.22
192.168.1.33
192.168.1.34
192.168.1.46
192.168.1.50
192.168.1.60

o Reglas que establecen acceso restringido a Squid:
http_access deny denegados
o También pueden definirse reglas valiéndose de la expresión !, la

cual significa no:
http_access allow LAN !denegados
2.4.5. Caso 4
Restringir al acceso a ciertas páginas web.
• Establecer una lista de control de acceso:

lista de paginas web:
acl webdenegadas url_regex "/etc/squid/webdenegadas"
Contenido del archivo /etc/squid/webdenegadas:

www.hotmail.com
www.yahoo.com
gmail.com
www.youtube.com

http_access deny webdenegadas


cual significa no:
http_access allow LAN !webdenegadas
Fig. 5. Acceso denegado
2.4.6. Caso 5
Restringir la descarga de ciertos archivos por su extensión.
• Establecer una lista de control de acceso:

o Definir ACL:
Acl descargas1 urlpath_regex -i \.mp3$ \.zip$ \.exe$

lista de páginas web:
acl descargas1 urlpath_regex etc/squid/descargas1"
Contenido del archivo /etc/squid/descargas1:

\.mp3$
\.zip$
\.exe$
\.scr$
\.pif$

120

http_access deny descargas1

cual significa no:
http_access allow LAN !descargas1
2.5. Verificación de logs
SQUID almacena en el directorio /var/log/squid información sobre los

accesos, diálogos con otros servidores SQUID, etc. Existen varios
archivos de logs. El que nos brinda información sobre el acceso al
servidor es access.log. Cuando se entrega a un cliente un objeto que
se encontraba almacenado, se produce un HIT y si el objeto debe ser
consultado hacia Internet, entonces, es un MISS.
Squid genera 3 ficheros de log:
• access.log: Aquí se guardan las peticiones que se le hacen al

Proxy, podemos saber cuánta gente usa el Proxy, qué páginas son
las más visitadas.
[root@centos:~]# tail -f /var/log/squid/access.log

1176538770.568 195 192.168.1.4 TCP_DENIED/403 1324 GET
http://gmail.com/ - NONE/- text/html
1176538773.646 4 192.168.1.4 TCP_DENIED/403 1346 GET
http://gmail.com/favicon.ico - NONE/- text/html
1176538799.979 12 192.168.1.4 TCP_DENIED/403 1336 GET
http://www.youtube.com/ - NONE/- text/html
1176538800.937 91 192.168.1.4 TCP_DENIED/403 1358 GET
http://www.youtube.com/favicon.ico - NONE/- text/html
1176538818.162 11 192.168.1.4 TCP_DENIED/403 1336 GET
http://www.hotmail.com/ - NONE/- text/html
1176538819.070 82 192.168.1.4 TCP_DENIED/403 1358 GET
http://www.hotmail.com/favicon.ico - NONE/- text/html
1204373729.553 644 192.168.1.2 TCP_MISS/302 606 GET
http://www.cibertec.edu.pe/ - DIRECT/200.0.118.6 text/html
1204373729.963 169 192.168.1.2 TCP_MISS/200 2642 GET
http://www.cibertec.edu.pe/IntroCIBERTEC.html -
DIRECT/200.0.118.6 text/html
1204373732.395 122 192.168.1.2 TCP_MISS/200 3754 GET
http://www.cibertec.edu.pe/libreriajs/AC_RunActiveContent.js
- DIRECT/200.0.118.6 application/x-javascript
1204373772.770 463 192.168.1.2 TCP_MISS/301 737 GET
http://www.macromedia.com/go/getflashplayer -
1204373774.270 1108 192.168.1.2 TCP_MISS/200 25974 GET
http://www.adobe.com/shockwave/download/download.cgi? -

1204373775.573 354 192.168.1.2 TCP_MISS/200 1562 GET

http://www.adobe.com/favicon.ico - DIRECT/216.104.208.201
image/x-icon
[root@centos:~]#
• cache.log: Aquí se van guardando los errores, mensajes de inicio,

etc.
• store.log: Aquí se va guardando lo que pasa con el caché, qué

páginas (objetos) se añaden, cuáles se quitan.
El análisis de los logs, por lo general, se realiza con herramientas de

software independientes de SQUID. Dos de las más utilizadas son
SARG (Squid Analysis Report Grpahics) y Webalizer, las mismas
generan reportes gráficos con estadísticas en un archivo html. Son una
excelente herramienta para llevar un control detallado sobre la
utilización de la navegación web.

122
Autoevaluación
1. El archivo cache.log registra:
(a) El acceso de los clientes al caché de squid
(b) Información del funcionamiento del caché de squid
(c) Los objetos agregados o eliminados en el caché de squid
(d) Todos los eventos del sistema
2. Defina una lista de control de acceso que defina toda la red

192.168.1.32/27
(a) acl lan src 192.168.1.32/255.255.255.224
(b) acl lan urlpath_regex -i 192.168.1.32/255.255.255.224
(c) acl lan src 192.168.1.32/255.255.255.0
(d) acl lan url_regex 192.168.1.32/255.255.255.224
3. El Servidor Proxy no puede procesar los siguientes tipos de conexión:

(Seleccione 2)
FTP
POP3
http
HTTPS
SMTP

SEMANA
12
Proxy application firewall II
TEMA
Descipción del uso del Servidor Proxy Squid.
• Comprender el funcionamiento del Servidor Proxy.
• Configurar un Proxy Transparente.
CONTENIDOS
• Configuración
• Proxy Transparente
• Squid Análisis Report Generator (Sarg)

124
CONFIGURACIÓN
2.1. Bloqueo del MSN Messenger
2.1.1. Configurar el cliente
• Ejecute el IE.
• Haga clic en el menú Herramientas. Luego, en Opciones de
Internet. (Ver Fig. 1)
• Haga clic en la pestaña Conexiones.
• Haga clic en el botón Configuración de LAN.
Fig. 1. Opciones de Internet
• Haga clic en la casilla del Servidor Proxy. (Ver Fig. 2)

• Ingrese los valores correspondientes al servidor Proxy.

Fig. 2. Configuración del cliente
2.1.2. Archivo de registro
Ingrese desde el equipo cliente al MSN y observe los paquetes

relacionados en el archivo /var/log/squid/access.log en el
servidor Proxy.

1204395339.680 342 192.168.1.4 TCP_MISS/200 430 POST
http://207.46.111.57/gateway/gateway.dll? -
DIRECT/207.46.111.57 application/x-msn-messenger
1204395340.204 316 192.168.1.4 TCP_MISS/200 587 POST
1204395345.534 334 192.168.1.4 TCP_MISS/200 605 POST
1204395345.885 304 192.168.1.4 TCP_MISS/401 1098 GET
http://login.passport.com/login2.srf -
1204395346.472 586 192.168.1.4 TCP_MISS/200 423 POST
1204395433.123 420 192.168.1.92 TCP_MISS/302 748 GET
http://www.microsoft.com/isapi/redir.dll? -
1204395433.559 435 192.168.1.92 TCP_MISS/302 581 GET
http://go.microsoft.com/fwlink/? - DIRECT/64.4.52.189
text/html
1204395434.425 865 192.168.1.92 TCP_MISS/200 32207 GET
http://latam.msn.com/ - DIRECT/207.68.183.120 text/html
1204395434.706 352 192.168.1.92 TCP_MISS/200 856 GET
http://rad.msn.com/ADSAdClient31.dll? -
1204395434.783 474 192.168.1.92 TCP_MISS/200 610 GET
http://msnportal.112.2o7.net/b/ss/msnportallatamhome/1/H.

126
1-pdv-2/s85717557388621? - DIRECT/128.241.21.163
image/gif
1204395434.862 428 192.168.1.92 TCP_MISS/200 4681 GET
http://a.rad.msn.com/ADSAdClient31.dll? -
1204395434.878 633 192.168.1.92 TCP_MISS/200 529 GET
http://c.msn.com/c.gif? - DIRECT/207.46.216.62 image/gif
1204395434.931 136 192.168.1.92 TCP_MISS/200 4712 GET
http://rad.msn.com/ADSAdClient31.dll? -
1204395435.055 349 192.168.1.92 TCP_MISS/200 1598 GET
http://b.rad.msn.com/ADSAdClient31.dll? -
1204395435.795 738 192.168.1.92 TCP_MISS/200 17525 GET
http://a.ads1.msn.com/ads/1/0000000001_000000000000000546
396.swf? - DIRECT/4.23.34.124 application/x-shockwave-
flash
1204395436.610 1550 192.168.1.92 TCP_MISS/200 30816 GET
http://ads1.msn.com/ads/1/0000000001_00000000000000052840
7.swf? - DIRECT/4.23.34.124 application/x-shockwave-flash
1204395888.852 1479 192.168.1.92 TCP_MISS/200 22009
CONNECT login.live.com:443 - DIRECT/65.54.179.203 -
1204395890.035 688 192.168.1.92 TCP_MISS/200 529 GET
http://c.msn.com/c.gif? - DIRECT/207.46.216.62 image/gif
1204395903.211 13374 192.168.1.92 TCP_MISS/200 113383
CONNECT by3.omega.contacts.msn.com:443 -
DIRECT/207.46.113.221 -
1204395903.230 8455 192.168.1.92 TCP_MISS/200 180805
CONNECT by3.omega.contacts.msn.com:443 -
DIRECT/207.46.113.221 -
1204395903.428 655 192.168.1.92 TCP_MISS/304 265 GET
http://67.192.58.61/tabclaro/claro_logo_tamano_b.png -
DIRECT/67.192.58.61 -
1204395903.579 343 192.168.1.92 TCP_MISS/304 232 GET
http://www.mercadolibre.com/org-img/MSN/logo_solapa.png -
DIRECT/64.14.123.185 -
2.1.3. Configuración del servidor Proxy
En el archivo /etc/squid/squid.conf realizar:
• Definir ACL:
acl contenido url_regex "/etc/squid/contenido"

acl msn req_mime_type -i ^application/x-msn-messenger$
acl msn1 urlpath_regex gateway.dll
acl msn2 url_regex e-messenger.net
webmessenger.msn.com
Contenido del archivo /etc/squid/descargas1:
Msn
Messenger
live.com
• Definir RCL:
http_access deny contenido
http_access deny msn

http_access deny msn1

http_access deny msn2
2.1.4. Probación de la restricción
Desde el equipo cliente ejecute el Windows Live Messenger
Fig. 3. Cliente MSN
Desde el servidor observamos los paquetes bloqueados:

1204397569.531 2 192.168.1.92 TCP_DENIED/403 1333
CONNECT login.live.com:443 - NONE/- text/html
1204398006.000 4 192.168.1.92 TCP_DENIED/403 1408
GET
http://g.latam.msn.com/8SEESXL030000TBR/TOOLBRNewsFeed1 -
NONE/- text/html
2.2. Mensajes de error en español
En forma predeterminada, los mensajes de error se muestran en

inglés, pero podemos configurar Squid para que se muestren en
español u otro idioma.
Cada distribución ubica los directorios de idiomas en distintos lugares,

por lo que debemos determinar dicha ubicación:
[root@CentOS ~]# cat /etc/squid/squid.conf | grep English

# copy the template English files to another
#error_directory /usr/share/squid/errors/English
# error_directory /usr/share/squid/errors/English
[root@CentOS ~]# ls /usr/share/squid/errors/
Azerbaijani English Hebrew Polish
Simplify_Chinese
Bulgarian Estonian Hungarian Portuguese Slovak

128
Catalan Finnish Italian Romanian Spanish

Czech French Japanese Russian-1251 Swedish
Danish German Korean Russian-koi8-r
Traditional_Chinese
Dutch Greek Lithuanian Serbian Turkish
[root@CentOS ~]#
Modifique el archivo /etc/squid/squid.conf para que los mensajes de

error se muestren en español:
#error_directory /usr/lib/squid/errors/English
#
#Default:
error_directory /usr/lib/squid/errors/Spanish
Reinicie el servidor Proxy:

[root@CentOS ~]# /etc/init.d/squid restart
Parando squid: . [ OK ]
Iniciando squid: . [ OK ]
[root@CentOS ~]#
Desde un equipo cliente probar:
Fig. 4. Mensajes de error en español

2. Proxy transparente
2.1. Configuración del servidor Squid
Modifique en el archivo /etc/squid/squid.conf el parámetro http_port:
http_port 3128 transparent
Para versiones antiguas del Squid modifique las siguientes líneas:

http_port 10.0.0.1:3128
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_wiht_proxy on
httpd_accel_uses_host_header on
Fig. 5. Proxy Transparente
2.2. Configuración del Firewall
Configurando el redireccionamiento del puerto 80 al puert0 3128,

ejecute los siguientes comandos:
[root@CentOS ~]# echo 1 > /proc/sys/net/ipv4/ip_forward
[root@CentOS ~]# iptables -t nat -A PREROUTING -p tcp --dport
80 -i eth1 -j REDIRECT --to-port 3128
[root@CentOS ~]# iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -
j MASQUERADE
[root@CentOS ~]# iptables -L -t nat
REDIRECT tcp -- anywhere anywhere
tcp dpt:http redir ports 3128

130

MASQUERADE all -- 10.0.0.0/8 anywhere

[root@CentOS ~]#
[root@CentOS ~]# /etc/init.d/squid restart
Parando squid: . [ OK ]
Iniciando squid: . [ OK ]
[root@CentOS ~]#
NOTA: También se podría reemplazar:
[root@CentOS ~]# iptables -t nat -A POSTROUTING -s

10.0.0.0/8 -j MASQUERADE
por:
[root@CentOS ~]# iptables -t nat -A POSTROUTING -o eth0

-j SNAT --to-source 192.168.1.3
[root@CentOS ~]# iptables -L -t nat
REDIRECT tcp -- anywhere anywhere
tcp dpt:http redir ports 3128

SNAT all -- anywhere anywhere
to:192.168.1.3

[root@localhost squid]#
2.3. Configuración de las estaciones de trabajo
Defina como gateway predeterminado la dirección IP del servidor

Proxy Transparente.

3. Sarg (Squid Analysis Report Generator)

Sarg es un programa para ver los informes de uso del Squid de una red,
que permite ver a "dónde" están yendo sus usuarios dentro de Internet.
Sarg genera informes en html con muchos campos, como usuarios,

direcciones IP, bytes transmitidos, sitios web and tiempos.
Ejemplo de los informes aquí: http://sarg.sourceforge.net/squid-

reports/index.html
Instalación de Sarg: yum install sarg
3.1. Configuración
El archivo de configuración es /etc/sarg/sarg.conf, modifiquemos las

siguientes líneas:
language Spanish (para definir el idioma Español)

resolve_ip yes (para que muestre nombres en vez de IP’s)
user_ip yes (para que liste por IP y no por UID de Squid)
date_format e (para usar el formato de fecha europeo y no el
americano)
use_comma no (para usar el punto como separador de miles)
topsites_num 200 (para aumentar el número de sitios del topsites a
200)
output_dir /var/www/html/squid-reports
(Directorio donde se guardan los reportes)
3.2. Ejecución
Al ejecutarse el comando sarg se crean las páginas html estáticas con

los accesos del día.
Se configura /etc/crontab para que se ejecute en forma periódica,

agregue la siguiente línea:
40 23 * * * /usr/bin/sarg > /dev/null
3.3. Reportes
Para visualizar los reportes generados desde un navegador cargue la

siguiente dirección:
http://IP_Proxy/squid-reports/

132
Fig. 6. Reportes
Fig. 7. Reportes del día

Fig. 8. Reportes de un cliente

134
Autoevaluación
1. Cuando el servidor Squid está configurado como Proxy transparente:
(a) Las peticiones de los clientes HTTP son redireccionadas al puerto

8082.
(b) Hay que configurar cada cliente HTTP.
(c) No es necesario configurar cada cliente HTTP.
(d) No guarda las páginas web que son accedidas por lo clientes
HTTP.
2. Cuando el servidor Squid está configurado como Proxy transparente:
(a) Las peticiones de los clientes HTTP son redireccionadas al puerto

8082.
(b) Hay que configurar cada cliente HTTP.
(c) No es necesario configurar los equipos cliente.
(d) En los equipos cliente, asignamos como puerta de enlace

predeterminado la dirección IP del servidor Squid.
3. ¿Qué es Sarg?

SEMANA
13
Intrusión detection systems
TEMA
Describir el uso del IDS.
• Comprender el funcionamiento del IDS.
CONTENIDOS
• Introducción.
• Snort.

136
INTRODUCCIÓN
Un IDS o Sistema de Detección de Intrusiones es una herramienta de

seguridad que intenta detectar o monitorizar los eventos ocurridos en un
determinado sistema informático o red informática en busca de intentos de
comprometer la seguridad de dicho sistema.
Los IDS buscan patrones, previamente, definidos que impliquen cualquier

tipo de actividad sospechosa o maliciosa sobre nuestra red o host.
Los IDS aportan a nuestra seguridad una capacidad de prevención y de

alerta anticipada ante cualquier actividad sospechosa. No están diseñados
para detener un ataque, aunque sí pueden generar ciertos tipos de
respuesta ante éstos.
Los IDS aumentan la seguridad de nuestro sistema, vigilan el tráfico de

nuestra red, examinan los paquetes analizándolos en busca de datos
sospechosos y detectan las primeras fases de cualquier ataque como
pueden ser el análisis de nuestra red, barrido de puertos, etc.
1.1. Tipos de IDS
1.1.1. HIDS (Host IDS)
Protege contra un único Servidor, PC o host. Monitorizan gran

cantidad de eventos, analizando actividades con una gran
precisión, determinando de esta manera qué procesos y
usuarios se involucran en una determinada acción. Recaban
información del sistema como ficheros, logs, recursos, etc. para
su posterior análisis en busca de posibles incidencias.
Todo ello, en modo local, dentro del propio sistema. Fueron los
primeros IDS en ser desarrollados por la industria de la
seguridad informática.
1.1.2. NIDS (Net IDS)
Protege un sistema basado en red. Actúan sobre una red

capturando y analizando paquetes de red, es decir, son sniffers
del tráfico de red. Luego analizan los paquetes capturados,
buscando patrones que supongan algún tipo de ataque.
Bien ubicados, pueden analizar grandes redes y su impacto en

el tráfico suele ser pequeño. Actúan mediante la utilización de
un dispositivo de red configurado en modo promiscuo (analizan,
“ven” todos los paquetes que circulan por un segmento de red,
aunque estos no vayan dirigidos a un determinado equipo).
Analizan el tráfico de red, normalmente, en tiempo real. No sólo
trabajan a nivel TCP/IP, también lo pueden hacer a nivel de
aplicación.
Otros tipos son los híbridos.
Por el tipo de respuesta podemos clasificarlos en:
Pasivos – Son aquellos IDS que notifican a la autoridad competente o

administrador de la red mediante el sistema que sea, alerta, etc. Pero
no actúa sobre el ataque o atacante.
Activos – Generan algún tipo de respuesta sobre el sistema atacante
o fuente de ataque, como cerrar la conexión o enviar algún tipo de
respuesta predefinida en nuestra configuración.
1.2. Arquitectura
Normalmente, la arquitectura de un IDS, a grandes rasgos, está

formada por los siguientes elementos:
1. La fuente de recogida de datos. Estas fuentes pueden ser un log,
dispositivo de red, o como en el caso de los IDS basados en host,
el propio sistema.
2. Reglas que contienen los datos y patrones para detectar anomalías
de seguridad en el sistema
3. Filtros que comparan los datos snifados de la red o de logs con los
patrones almacenados en las reglas
4. Detectores de eventos anormales en el tráfico de red
5. Dispositivo generador de informes y alarmas. En algunos casos con
la sofisticación suficiente como para enviar alertas vía mail, o SMS.
Esto es a modo general. Cada IDS implementa la arquitectura de

manera diferente.
1.3. Dónde colocar el IDS
Una actitud paranoica por nuestra parte nos podría llevar a instalar un
IDS en cada host ó en cada tramo de red. Esto último sería un tanto
lógico cuando se trata de grandes redes, no es nuestro caso ahora. Lo
lógico sería instalar el IDS en un dispositivo por donde pase todo el
tráfico de red que nos interese.
1.3.1. Dificultades
Un problema de los IDS es cuando queremos implementarlos en

redes conmutadas, ya que no hay segmento de red por donde
pase todo el tráfico. Otro problema para un IDS son las redes
con velocidades de tráfico muy altas en las cuales es difícil
procesar todos los paquetes.

138
1.3.2. Posición del IDS
Si colocamos el IDS antes de los cortafuegos, capturaremos

todo el tráfico de entrada y salida de nuestra red. La posibilidad
de falsas alarmas es grande.
La colocación detrás de los cortafuegos monitorizará todo el

tráfico que no sea detectado y parado por éste, por lo que será
considerado como malicioso en un alto porcentaje de los casos.
La posibilidad de falsas alarmas es muy inferior.
Algunos administradores de sistemas colocan dos IDS, uno

delante y otro detrás del cortafuegos, para obtener información
exacta de los tipos de ataques que recibe la red, ya que si el
cortafuegos está bien configurado, puede parar o filtrar muchos
ataques.
En ambientes domésticos, podemos colocar el IDS en la misma

máquina que los cortafuegos. En este caso, actúan en paralelo,
es decir, el cortafuegos detecta los paquetes y el IDS los
analiza.
2. SNORT
Snort es un IDS o Sistema de detección de intrusiones basado en red
(NIDS). Implementa un motor de detección de ataques y barrido de puertos
que permite registrar, alertar y responder ante cualquier anomalía
previamente definida, como patrones que corresponden a ataques, barridos,
intentos aprovechar alguna vulnerabilidad, análisis de protocolos, fallas
conocidas, etc. Todo esto en tiempo real.
Snort (http://www.snort.org/) está disponible bajo licencia GPL y funciona

bajo plataformas Windows y UNIX/Linux. Es uno de los más usados y
dispone de una gran cantidad de filtros o patrones ya predefinidos, así como
actualizaciones constantes ante casos de ataques, barridos o
vulnerabilidades que vayan siendo detectadas a través de los distintos
boletines de seguridad.
Este IDS implementa un lenguaje de creación de reglas flexibles, potentes y

sencillas. Durante su instalación, ya nos provee de cientos de filtros o reglas
para backdoor, ddos, finger, ftp, ataques web, CGI, escaneos Nmap….
Puede funcionar como sniffer (podemos ver en consola y en tiempo real qué
ocurre en nuestra red, todo nuestro tráfico), registro de paquetes (permite
guardar en un archivo los logs para su posterior análisis, un análisis offline)
o como un IDS normal (en este caso NIDS).
La colocación de Snort en nuestra red puede realizarse según el tráfico que

quiere vigilarse: paquetes entrantes, paquetes salientes, dentro del firewall,
fuera del firewall y, en realidad, prácticamente, donde queramos.

Una característica muy importante e implementada desde hace pocas

versiones es FlexResp. Permite, dada una conexión que emita tráfico
malicioso, darla de baja, hacerle un DROP mediante el envío de un paquete
con el flag RST activa, con lo cual cumpliría funciones de firewall, cortando
las conexiones que cumplan ciertas reglas predefinidas. No sólo corta las
conexiones, ya que puede realizar otras muchas acciones.
2.1. Instalación de Snort
Desde la página oficial de Snort descargaremos los siguientes

archivos:
• Binario snort-2.8.0.2-1.RH5.i386.rpm
• Checksum MD5 snort-2.8.0.2-1.RH5.i386.rpm.md5
Fig. 1. Descarga de Snort
Verificamos si el archivo se ha descargado sin errores y luego

procedemos a instalar el paquete. (Ver Fig. 2)

140
Fig. 2. Instalación de Snort
2.2. Instalación de las Reglas de Snort
Antes de poder descargar las reglas de Snort, se debe registrar el

usuario.
Fig. 3. Descarga de las Reglas

Para descargas las reglas de Snort, vaya al siguiente enlace:

www.snort.org/pub-bin/dowloads.cgi (Ver Fig. 3). Luego, vaya hasta la
opción de descargas para usuarios registrados.
Verificamos si el archivo se ha descargado sin errores y luego

procedemos a instalar el paquete. (Ver Fig. 4)
Fig. 4. Instalación de Reglas
2.3. Snort en modo Sniffer
El formato genérico para este modo es snort [-opciones] < filtro >
snort -v
Fig. 5. Cabeceras de los paquetes TCP/IP

142
Con esta opción -v iniciamos Snort en modo sniffer visualizando en

pantalla las cabeceras de los paquetes TCP/IP. Esta opción es el
modo verbouse y mostrará las cabeceras IP, TCP, UDP y ICMP.
Si queremos, además, visualizar los campos de datos que pasan por la

interface de red, añadiremos -d.
snort -vd
Fig. 6. Campos de datos de los paquetes TCP/IP
Añadiendo la opción -e, Snort nos mostrará información más detallada.

Nos mostrará las cabeceras a nivel de enlace.
snort -dev
2.3.1. Filtros
Podemos añadir, a parte de las opciones, una serie de filtros

para optimizar los resultados obtenidos. Estos filtros se añadirán
en el mismo formato que usa programas como TCPDump, ya
que usan las mismas librerías de captura de paquetes (libpcap).

snort -vd host 192.168.1.92 and dst port 80
Fig. 8. Filtros
Otra opción a tomar en cuenta es -i para indicar a snort qué interface

de red usar en el caso de que tengamos dos o más.
snort -vde -i 1
2.4. Snort en modo Registro de paquetes
Con estas opciones y dependiendo del tráfico en nuestra red, veremos

pasar gran cantidad de información por nuestra pantalla, con lo cual
sería interesante registrar, guardar estos datos a disco para su
posterior estudio.
snort -dev -l /var/log/snort/
La opción -l indica a Snort que debe guardar los logs en un directorio

determinado, en este caso dentro de la carpeta log se creará una
estructura de directorios donde se archivarán los logs.

144
El formato de los logs se almacena en formato TCPDump. Esto

permite que se puedan estudiar más a fondo con los potentes filtros de
este programa.
Fig. 7. Comando tcpdump
El archivo generado por Snort en modo binario también podemos

leerlo con este mismo aplicativo usando:
snort -r /var/log/snort/snort.log.1204420267
snort –dev -r /var/log/snort/snort.log.1204420267
snort -r /var/log/snort/snort.log.1204420267 tcp

Autoevaluación
1. ¿Cuál no es un modo de funcionamiento de Snort?
(a) Packet Dump
(b) Packet Logging
(c) Packet Syslog
(d) Packet IDS
2. ¿Qué es un HIDS?
3. ¿Qué significa el término “falso positivo” en un IDS?
(a) Es la detección de un intruso.
(b) Es la detección de un ataque.
(c) Es un reporte de un ataque o intrusión donde no existe.
(d) Es la falla para reportar un ataque o intrusión actual.
(e) Es una falla en el sistema IDS.

146

SEMANA
14
Virtual private networks
TEMA
Configurar una VPN.
• Comprender el funcionamiento de la VPN

• Implementar una VPN
CONTENIDOS
• Virtual Private Networks (VPN)

• Openvpn

148
VIRTUAL PRIVATE NETWORKS (VPN)
Las VPN’s son sesiones en un canal de comunicaciones autenticado y

encriptado en una red pública, como es el caso de Internet. Considerando
que las redes son inseguras, la encriptación y autenticación son utilizados
para proteger los datos en tránsito. VPN es considerado un servicio
independiente ya que toda información es transmitida a lo largo de un canal
encriptado. En la siguiente figura, se muestra un esquema de este tipo de
conexiones:
Fig. 1. Esquema de una conexión basada en VPN
En el diagrama mostrado se muestra que los dispositivos están conectados

a través de un túnel configurado en los ruteadores. Para que se pueda
establecer una sesión VPN, ambos equipos deben tener configurados los
mismos parámetros: tamaño de las llaves, método de encriptación, etc. De
esta manera, si se coloca un analizador de protocolos entre ambos
rutedores, sólo se verá tráfico encriptado. El analizador verá el tráfico con
direcciones IP origen y destino de los ruteadores. Dentro de los paquetes
encriptados, van encapsulados los paquetes con las verdaderas direcciones
IP origen y destino que van de una red a otra.

A este proceso, se le llama tunneling. Esto ayuda a evitar que un atacante

pueda conocer qué direcciones establecen conexiones entre si.
Esta característica también puede utilizarse en beneficio propio, ya que son

los ruteadores los que realizan el túnel con sus direcciones públicas, se
pueden utilizar direcciones de red privadas para que vayan encapsulados
en el tráfico encriptado.
Las VPN´s fueron diseñadas y desarrolladas para reemplazar lo siguiente:
• Grupos de módems
• Enlaces WAN dedicados
1.1. Beneficio de las VPNs
• Extender la red de la corporación a través de Internet

• Fomentar los negocios sobre Internet
• Reducir los costos de acceso remoto (dial up)
• Se proporciona movilidad a los usuarios, fomentar el teletrabajo,
conectividad a los recursos centrales de la organización de forma
transparente.
1.2. Tecnologías de VPN
Entre las tecnologías de VPN´s tenemos:
A. Point-to-Point Tunneling Protocol (PPTP)

PPTP trabaja en el nivel de la capa de enace del modelo OSI. Está
diseñado para conexiones de clientes individuales a un servidor
VPN y habilita una sola conexión punto a punto por sesión. Este
protocolo es muy común con conexiones asíncronas que utilizan
clientes Windows XP/2000/2003. PPTP utiliza el protocolo de
autenticación nativo de Point to Point y sus servicios de
encriptación.
B. Layer 2 Tunneling Protocol (L2TP)

L2TP es una combinación de PTP y el protoclo Layer 2
Fordwarding Protocol (L2F) que trabaja en la capa de enlace,
similar a PPTP. Este protoclo es muy utilizado en los enlaces VPN
que se realizan vía dial-up. Este estándar fue diseñado para
conexiones simples cliente/servidor. Por esta razón, se pueden
encapsular múltples protoclos.
C. IPSec
IPSec opera en la capa de red y habilita túneles múltiples y
simultáneos, a diferencia de la conexión simple de los estándares
anteriores. IIPSec tiene la funcionalidad de encriptar y autenticar
datos IP. Forma parte del nuevo estándar IPv6.
Modo de operación:

150
• Modo túnel – El paquete completo es encriptado y encapsulado

en un paquete IPSec. No soporta tráfico que ha sufrido NAT.
• Modo Transporte – Sólo el datagrama es encriptado dejando
visible la dirección IP.
1.3. Elementos de una conexión VPN
• Servidor VPN: Basado en software o equipo, acepta conexiones

de clientes de acceso remoto o routers.
• Cliente VPN: inicia Conexión con el servidor VPN, el cliente VPN
puede usar cualquier protocolo tunnel.
• Túnel: Conexión por donde los datos son encapsulados.
• Conexión VPN: conexión en el cual los datos son encriptados.
• Protocolos Túnel: se usan para establecer, mantener y liberar los
tuneles.
• Datos del Túnel: Los datos que son enviados a través de la
conexión punto a punto.
• Red de Transporte: La red pública o compartida.
1.4. Escenarios típicos de VPN´s
• Interconexión de redes privadas a tráves de Internet
Ejemplo: conexión de dos oficinas de una empresa
o Se establece una VPN entre dos gateways, cada uno de una

red privada.
o Las máquinas de las redes utilizan esos gateways como routers.
o Cuando un gateway recibe un paquete dirigido a la red privada
del otro extremo, lo envía a través de la VPN de modo seguro.
o El tráfico sólo es protegido por la VPN en el recorrido entre los
dos gateways.

• Road Warriors
Ejemplo: trabajadores remotos
o Cada persona con permiso puede conectarse desde cualquier

lugar.
o La computadora debe contar con un cliente VPN, que establece
una conexión al concentrador de VPNs de la red corporativa.
o A partir de ese momento, todo el tráfico, desde la computadora
a la red corporativa, queda protegido por la VPN.
2. OPENVPN
OpenVPN es un excelente producto de software creado por James Yonan
en el año 2001 y que ha estado siendo mejorado desde entonces.
Ninguna otra solución ofrece una mezcla semejante de seguridad a nivel

empresarial, seguridad, usabilidad y riqueza de características.
Es una solución multiplataforma que ha simplificado mucho la configuración

de VPN's dejando atrás los tiempos de otras soluciones difíciles de
configurar como IPsec y haciéndola más accesible para gente inexperta en
este tipo de tecnología.
Caracteristicas:
• Solución VPN SSL flexible

• Software libre bajo licencia GPL
• Espacio de usuario, alta portabilidad
• Multiplataforma: GNU/Linux, *BSD, Mac OS X, Windows

152
Funcionalidad:
• Establece túneles de nivel 2 o 3 sobre un puerto UDP o TCP.

• Permite establecer balanceo de carga entre varios servidores.
• Confidencialidad, autenticidad e integridad usando OpenSSL
• Interfaz gráfica de configuración en Windows y Mac OS X
Interfaz tun
• Un interfaz tun es un adaptador de red virtual.

• El sistema operativo lo ve como una conexión punto a punto.
• Un programa de espacio de usuario puede abrir el interfaz tun y leer y
escribir paquetes IP en la interfaz.
• Un interfaz tap es similar, pero a nivel Ethernet.

2.1. Configuración VPN – Road Warrior (Host to LAN)
Fig. 2. VPN Road Warrior
2.1.1. Preparación del servidor VPN
(1) Se debe tener instalado los siguientes paquetes: pam,

openssl, lzo, openvpn.
# rpm -q pam
pam-0.99..6.2-3.14.el5
# rpm -q openssl
openssl-0.9.8b-8.3.el5
# rpm -q lzo
lzo-1.08-4.2.el5.rf
# rpm -q lzo2
lzo2-2.02-3-el5-rf
# rpm -q openvpn
openvpn-2.0.9-1.el5.rf
(2) Comprobamos el funcionamiento de Openvpn

# openvpn --genkey --secret key
# openvpn --test-crypto --secret key

154
Fig. 3. Verificando el correcto funcioanmiento de Openvpn
(3) Revisemos las direcciones IP pública y privada:

# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0F:3D:CB:7B:74
inet addr:190.12.79.79 Bcast:190.12.79.255
Mask:255.255.255.0
inet6 addr: fe80::20f:3dff:fecb:7b74/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2764 errors:0 dropped:0 overruns:0 frame:0
TX packets:682 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1362998 (1.2 Mb) TX bytes:100959 (98.5 Kb)
Interrupt:185 Base address:0xb800
eth1 Link encap:Ethernet HWaddr 00:15:E9:B0:22:7C
inet addr:192.168.1.250 Bcast:192.168.1.255
Mask:255.255.255.0
inet6 addr: fe80::215:e9ff:feb0:227c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX bytes:33440 (32.6 Kb) TX bytes:1822 (1.7 Kb)
Interrupt:169 Base address:0xb400
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX bytes:23316 (22.7 Kb) TX bytes:23316 (22.7 Kb)
2.1.2. Configuración del servidor VPN
(1) Creamos el directorio /etc/openvpn/easy-rsa

(2) Copiamo el directorio /usr/share/doc/openvpn-2.0.9/easy-rsa-
2.0/ hacia /etc/openvpn/easy-rsa
(3) Trasladamos al directorio /etc/openvpn/easy-rsa
(4) Definimos permisos de ejecución en los scripts.
(5) Inicializamos las variables para poder trabajar con los scripts
para la generación de las variables.

(6) Inicializamos el directorio de las claves.
Fig. 4. Configurar CA
(7) Procedemos a generar el certificado CA. Se nos pedirá una

serie de información sobre nuestra red/empresa que
debemos llenar lo más fielmente posible.
# sh build-ca
La variable que debemos, explícitamente, llenar es: Common

Name.
Fig. 5. Generación del certificado CA
(8) Generación del certificado y de la clave de encriptación para

el servidor.
# sh build-key-server server

156
Fig. 6. Generación del certificado de servidor.
En este paso, también, se nos pedirá de nuevo, información

sobre el certificado propio del servidor. Ingresar en Common
Name un nombre diferente al, anteriormente, escogido. En
este ejercicio: server
(9) El paso anterior nos generó dos archivos en el directorio

/etc/openvpn/easy-rsa/keys/ que se copiarán dentro del mismo
servidor hacia /etc/openvpn.

Fig. 7.
(10) Generando certificados y claves privadas para los clientes.
Cada cliente debe tener su propio certificado y clave de

seguridad. Para cada cliente que tengamos, deberemos
repetir el siguiente paso: los archivos obtenidos debemos
copiarlos hacia el directorio /etc/openvpn/ de los clientes.
En el caso de que nuestros clientes estén en Windows,

debemos copiarlos hacia el directorio c:\program
files\openvpn\
Para generar el certificado y claves privadas para el

cliente, ejecutamos en nuestro servidor, dentro del
directorio /etc/openvpn/easy-rsa/
# cd /etc/openvpn/easy-rsa/
# sh build-key client1
En el ejemplo anterior, generamos la clave y el certificado

para un cliente llamado cliente1.
Debemos hacer notar que al ejecutar el programa sh build-

key, le pasamos como parámetro el nombre del cliente
(cliente1 en el ejemplo anterior), el cual debe ser diferente
para cada cliente. En el common name, ponemos el
nombre del cliente (cliente1 en éste ejemplo) tal y como le
pasamos de parámetro.
(11) Se pueden generar tantas claves como sean necesarias

para cada cliente:
# sh build-key cliente2
# sh build-key cliente3
Esto nos generará dos claves y certificados más, para

cliente2 y cliente3; por favor, en common name debemos
poner client2 ó client3 para cada caso.

158
Fig. 8. Generación del certificado del cliente
(12) El parámetro de Diffie-Hellman debemos generarlo:

# sh build-dh

Fig. 9.
(13) Archivos a copiar al servidor VPN:

Hacia el directorio /etc/openvpn del servidor copiamos los
siguientes archivos: ca.crt, ca.key y dh1024.pem estos
archivos están presentes en el siguiente directorio
/etc/openvpn/easy-rsa/keys/
# cd /etc/openvpn/easy-rsa/keys/
# cp ca.crt ca.key dh1024.pem /etc/openvpn
# ls /etc/openvpn/
Fig. 10.
(14) Archivos a copiar al equipo del cliente

Hacia el directorio /etc/openvpn de cada cliente, copiamos
los siguientes archivos: ca.crt, clientX.crt y clientX.key
Tenga en cuenta que X es un número que se corresponde

con el cliente (para el cliente 2 sería: client2.crt y
client2.key por ejemplo).
Estos 3 archivos deben copiarse de forma segura hacia el

cliente, quizá mediante scp o algún medio magnético
seguro. No deben enviarse por mail, puesto que contienen
la clave (.key) de encriptación del cliente. Estos archivos
están presentes en /etc/openvpn/easy-rsa/keys del
servidor.
Este paso lo realizamos, netamente, desde el equipo del

cliente:

160
# scp 190.12.79.79:/etc/openvpn/easy-rsa/keys/ca.crt
/etc/openvpn
The authenticity of host '190.12.79.79 (190.12.79.79)' can't
be established.
RSA key fingerprint is
8f:38:bb:2a:7b:74:02:71:6c:40:0f:b0:3d:a2:d1:b0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '190.12.79.79' (RSA) to the list
of known hosts.
Password:
ca.crt 100% 1265 1.2KB/s 00:00
# scp 190.12.79.79:/etc/openvpn/easy-rsa/keys/client1.crt
/etc/openvpn
Password:
client1.crt 100% 3583 3.5KB/s 00:00
# scp 190.12.79.79:/etc/openvpn/easy-rsa/keys/client1.key
/etc/openvpn
Password:
client1.key 100% 887 0.9KB/s 00:00
(15) Configuración del servidor.

Creamos el archivo /etc/openvpn/server.conf; debe quedar
como se muestra:
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
#Direcciones que se asignaran a los
#clientes, el server es .1
server 192.168.3.0 255.255.255.0
ifconfig-pool-persist ipp.txt
#Ruta para que los clientes alcancen la red local
del server (1.0/24)
push "route 192.168.1.0 255.255.255.0"
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 4
Como podemos ver, hay nuevos parámetros, los más

importantes son:
• un push de la ruta hacia la red local interna del
servidor. Esa ruta estática permitirá que el road warrior
vea a las máquinas de la red interna.
• server: Indica el rango de direcciones que se asignará
a los clientes que se conecten, deben ser direcciones
no similares a las de la red local.
(16) Configuración en el equipo del cliente:

En este caso, la configuracion es en el directorio

/etc/openvpn/ del equipo cliente. Crearemos el archivo
/etc/openvpn/cliente.conf, así quedaría el archivo de
configuración:
client
dev tun
proto udp
remote 190.12.79.79 1194
resolv-retry infinite
nobind
#Las dos siguientes opciones no van en windows
user nobody
group nobody
persist-key
persist-tun
ca ca.crt
cert cliente1.crt
key cliente1.key
comp-lzo
verb 4
Las configuraciones más interesantes son:

• Client: indica que algunas configuraciones las tomará
del servidor.
• nobind: que no actúe como servidor, que solo vaya
como cliente.
• Recordar que cert y key deben ser únicas para cada
cliente
(17) Iniciamos el servicio openvpn en el lado del servidor

# cd /etc/openvpn/
# openvpn server.conf &
Fig. 11.

162
(18) Revisemos la nueva dirección IP de la tarjeta tun0 del

servidor VPN
# ifconfig tun0
Fig. 12.
(19) Ahora iniciamos el servicio openvpn en el equipo del cliente

VPN
# cd /etc/openvpn/
# openvpn cliente.conf &
(20) Revisemos la nueva dirección IP de la tarjeta tun0 del

cliente VPN
# ifconfig tun0
Fig. 13.
(21) Del lado del equipo cliente, se realiza un ping a las

direcciones IP del servidor VPN
# ping -c3 192.168.1.250
# ping -c3 192.168.3.1

Fig. 14.

164
Autoevaluación
1. ¿Qué es el proceso tunneling?
2. ¿Cuál no es una tecnología de VPN?
(a) PPTP
(b) L2TP
(c) L2F
(d) IPSec

Manual de Gestion de Servidores

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manual de Gestion de Servidores

Cargado por

Copyright:

Formatos disponibles

Gestión de

CARERRAS PROFESIONALES CIBERTEC

SEMANA 6 : Stateful Packet Inspection Firewall I 89

SEMANA 9 : Stateful Packet Inspection Firewall II 101

SEMANA 10 : Stateful Packet Inspection Firewall III 109

SEMANA 11 : Proxy Application Firewall I 123

SEMANA 12 : Proxy Application Firewall II 139

SEMANA 13 : Intrusión Detection Systems 147

SEMANA 14 Virtual Private Networks 161

CIBERTEC CARRERAS PROFESIONALES

CARERRAS PROFESIONALES CIBERTEC

Configuración del software RAID en LInux

• Comprender que es un RAID

• RAID por software en Linux

CIBERTEC CARRERAS PROFESIONALES

En 1987, la Universidad de Berkeley (California), publicó un artículo

CARERRAS PROFESIONALES CIBERTEC

El soporte RAID de Linux incorpora los siguientes niveles:

Se necesita un mínimo de dos unidades de disco para implementar

CIBERTEC CARRERAS PROFESIONALES

2.2. RAID 1: Mirroring "Redundancia. Más rápido que un disco y más

Llamado, también "Mirroring" o "Duplicación" (Creación de discos en espejo).

Se necesita un mínimo de dos unidades para implementar una solución

2.3. RAID 4: "Acceso Independiente con un disco dedicado a paridad."

Basa su tolerancia al fallo en la utilización de un disco dedicado a guardar la

Se necesita un mínimo de tres unidades para implementar una

CARERRAS PROFESIONALES CIBERTEC

La ventaja con el RAID 3 está en que se puede acceder a los discos de

2.4. RAID 5: "Acceso independiente con paridad distribuida."

RAID 5 es el nivel de RAID más eficaz y el de uso preferente para las

CIBERTEC CARRERAS PROFESIONALES

protección y disponibilidad de los datos es fundamental y el coste es un

Se necesita un mínimo de tres unidades para implementar una

Los niveles 4 y 5 de RAID pueden utilizarse si se disponen de tres o más

3. Configuracion de RAID por software en Linux

En Linux raidtools ha sido el paquete de gestión de RAID por software

CARERRAS PROFESIONALES CIBERTEC

De forma alternativa usted puede descargar e instalar el fichero del paquete

3.2. Generacion de particiones y formación del arreglo RAID 1 (Raid

Se requiere que en un disco este asignado a los datos y que tenga

Nota: De los discos a incorporarse lo particionaremos en una sola

Disco Particion Tamaño Tipo

III. Particionando discos:

Utilizaremos el comando “fdisk” para Particionar los discos:

CIBERTEC CARRERAS PROFESIONALES

: n Añadir una nueva partición

: t (Cambiando el tipo de Filesystem al tipo RAID)

:wq salir de fdisk.

Realizar el mismo proceso para /dev/hdd:

IV. Generando el Arreglo RAID 1:

Particiones que Nivel del Raid

mdadm: size set to 208512

CARERRAS PROFESIONALES CIBERTEC

V. Integrando el Arreglo RAID 1 al sistema de archivos:

• Formateando Raid del tipo Ext3

• Creando punto de montaje: #mkdir /info

• Realizando el montaje: mount /dev/md0 /info

• Visualizando los punto de montaje: # df

CIBERTEC CARRERAS PROFESIONALES

• Crear algunos archivos y directorio en “/info”

VI. Activacion Permanente:

Luego de comprobar que en el directorio “/info” esta almacenando

• Archivo de configuración de “mdadm”:

Enviando la información al archivo “mdadm.conf”: