IPTables-Shorewall MemoriaSDC

Software de Comunicaciones
Prctica 9 - Filtrado de Paquetes.

IPTables y Shorewall
Juan Dez-Yanguas Barber
Software de Comunicaciones
Ingeniera Informtica - 5 Curso
______________________________________________________________________________________
Jdyb - Mayo 2013
ndice
1. Introduccin 4
2. Cortafuegos personal 5
2.1. Estado inicial de IPTables 5
2.2. Establecimiento de reglas de ltrado sin estado 7
2.2.1. Establecimiento de la poltica por defecto 7
2.2.2. Establecimiento de reglas 8
2.2.3. Comprobacin de la importancia del orden de las reglas 13
2.3. Redireccin de trco 15
2.4. Usar IPTables para protegerse de una enumeracin con NMap 17
2.5. Filtros con estado para ICMP 19
3. Router con funcin de cortafuegos y NAT 22
3.1. Construccin del escenario 22
3.2. Conguracin del escenario 30
3.3. Instalacin de Shorewall 32
3.4. Conguracin de Shorewall 33
3.4.1. Conguracin de zonas 34
3.4.2. Conguracin de polticas 34
3.4.3. Conguracin de reglas 34
3.4.4. Conguracin de las interfaces 35
3.4.5. Conguracin de enmascaramiento 35
3.5. Conguracin de polticas bsicas 36
3.5.1. Conguracin previa del escenario 36
3.5.2. Conguracin de las polticas en Shorewall 37
3.5.3. Enmascaramiento de direcciones 39
Juan Dez- Yanguas Barber Prctica 9
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 2

3.5.4. Conguracin de reglas para las conexiones salientes 42
4. Apartados opcionales 53
4.1. Securizar servidor SSH contra ataques de fuerza bruta 53
4.2. Control y limitacin del ancho de banda 56
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 3

1. Introduccin
En esta prctica se va a tratar el manejo de net lter, llamado ahora IPTables. Es
un mdulo incluido dentro de ncleo del sistema operativo. Esto implica que no vamos a
tener que instalarlo ni activarlo.
No se tiene que activar porque ya viene activo por defecto pero hace el efecto de
no estar activo porque sus tablas de ltrado estn todas ellas vacas por defecto y poltica
que llevan por defecto es ACCEPT.
El sistema de ltrado se compone de una serie de tablas en diferentes etapas, y en
cada una de ellas es posible aplicar reglas de diferente tipo, a saber entre reglas de
ltrado, reglas de NAT o reglas de manipulacin de paquetes.
A continuacin indicamos mediante un esquema las diferentes reglas que son
aplicables en cada una de las etapas.
Durante el desarrollo de la prctica se har referencia a cada una de las etapas y
tablas que se han visto representadas en la gura. Se tratarn dos escenarios, el primero
de ellos ser la conguracin de un cortafuegos personal y el segundo de ellos tratar de
poner en marcha una mquina con la funcin de reenvo habilitada de manera que actu
como un router dentro de la red con funcin de NAT y cortafuegos.
PREROUTING FORDWARD
Entrega
local
INPUT
POSTROUTING
OUTPUT
Procesado local
NO
SI
Sistema de Filtrado
DNAT
Manipulacin
(Mangle)
SNAT
Manipulacin
(Mangle)
DNAT
Manipulacin
(Mangle)
Filtrado
Manipulacin
(Mangle)
Filtrado
Manipulacin
(Mangle)
Filtrado
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 4

2. Cortafuegos personal
En este apartado trataremos el primer escenario comentado anteriormente en el
cual usaremos IPTables como ltro de control para lo que entre o salga de nuestro equipo
local.
2.1. Estado inicial de IPTables
Lo primero que vamos a hacer es comprobar el estado de las interfaces de nuestro
equipo que veremos que cuenta con una interfaz virtual, la interfaz fsica y la interfaz de
loopback. Es la misma conguracin que hemos usado en anteriores ocasiones.
Ahora comprobaremos el estado de IPTables, que veremos que tiene todas las
tablas de las cadenas de reglas vacas y con poltica por defecto ACCEPT que es como
se encuentra por defecto. Para visualizar el contenido de las tablas lo haremos con el
siguiente comando.
Si no se especica tabla la que se muestra por defecto es la de ltrado y si no se
especica la cadena mostrar todas aquellas en las que este presente la tabla. Por
ejemplo, si es la tabla de ltrado mostrar OUTPUT, INPUT y FORWARD.
"#$%&'() *+,-#."/0 '")$%12 *0,3-)$1%1 043(1-) 5( #6(1$- ( 78) (0
9(: 5( 5-3"0"-) - #1-$-.-'-)2
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 5

Mostraremos ahora las reglas de las tablas de NAT para todas las cadenas en las
que este presente y veremos que de nuevo no hay regla alguna. Fijndonos en el
diagrama de la introduccin vemos que las tablas de NAT se encuentran en la cadena de
PREROUTING, POSTROUTING y OUTPUT.
Finalmente mostramos las reglas de las tablas de manipulacin o mangle, esta vez
la tabla estar presente en todas las cadenas de reglas. De nuevo no habr reglas por
defecto y la poltica por defecto ser ACCEPT.
Tal como se indic no ha sido necesaria instalacin ni activacin de nada al ser un
mdulo del propio ncleo del sistema, solo que al no tener reglas y tener la poltica
ACCEPT por defecto no afecta al funcionamiento del sistema en lo que a conexiones se
reere.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 6

2.2. Establecimiento de reglas de ltrado sin estado
En el enunciado se nos indica que vamos a proceder al establecimiento de reglas
sin estado en las cadenas de INPUT y OUTPUT. Lo primero que se har es jar la poltica
y posteriormente se jarn las reglas que se nos indican.
2.2.1. Establecimiento de la poltica por defecto
Estableceremos en este apartado las polticas por defecto de DROP para las
cadenas OUTPUT y INPUT. Esto lo debemos de hacer sobre las tablas de ltrado que son
sobre las que estamos trabajando, ya que son las tablas por defecto podremos indicar la
tabla en el comando o no hacerlo ya que como se indic se toma por defecto la tabla de
ltrado.
"#$%&'() *8 ,#-';$".%2 <=>8=> ,.%5(0%2 ?@<8
Hay que tener cuidado en la aplicacin de las reglas en un entorno de produccin,
por ejemplo, al haber aplicado esta poltica sin tener ninguna regla de exclusin
estbamos conectados por ssh a la mquina y lgicamente la conexin se perdi en el
momento de aplicar la regla.
Mostramos ahora el resultado de las reglas con los comandos de listado que vimos
anteriormente. Sigue sin haber reglas pero ahora la poltica por defecto en la tabla de
ltrado para las cadenas de OUTPUT e INPUT son de DROP.

______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 7

La situacin actual se dira que es una situacin de bloqueo total en lo que se
reere a conexiones de la mquina. Por ejemplo levantamos el servidor http y el servidor
DNS e intentamos conectarnos desde la mquina antriona.
2.2.2. Establecimiento de reglas
En el enunciado se nos indica que habilitemos el intercambio de trco ICMP para
los equipos de la red local. Esto requerir la habilitacin en direccin entrante y saliente,
ya que se requerir que nuestra mquina responda a las peticiones y que tambin le
puedan llegar o enviar ella misma. Y solo se debe habilitar para dentro de la propia
subred.
"#$%&'() *$ A"'$(1 *B ,%C%5"12 <=>8=> *# ,#1-$-.-'-2 ".3# *5
,5()$"0-2 DEFGDHGDIJGKLFM *N BOOP8>
Antes de aplicar las reglas veremos el efecto que se produce, la mquina no puede
hacer ping ni recibir ping de otra mquina.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 8

Aplicamos a continuacin las reglas siguiendo la sintaxis indicada anteriormente.
La sintaxis debe ser estricta tal como se ha indicado en maysculas y minsculas.
Si se intenta ahora el ping se quedar parado porque podr enviar pero no recibir
las respuestas.
Aplicaremos ahora la regla pero en sentido entrante.
A continuacin comprobamos que ahora si se puede enviar pings a otra mquina
de la misma subred y que responde a los ping enviados desde una mquina de la misma
subred.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 9

Sin embargo comprobamos que no se pueden enviar pings a otra mquina que no
est en la subred.
A continuacin el enunciado tambin nos indica que habilitemos el trco saliente
hacia el puerto 80 TCP. Hay que tener en cuenta que aunque apliquemos la regla el
trco web no funcionar porque no est habilitado el trco del DNS ni tampoco est
habilitado el trco entrante en otros puertos, de manera que podr enviar la peticin pero
la respuesta normalmente se recibe en otros puertos no privilegiados que no son el 80.
Si se quiere que el trco web funcione habr que habilitar una regla anloga en
sentido entrante que permita el trco TCP originado en el puerto 80.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 10

Probamos a continuacin a lanzar una peticin a google pero por la direccin IP y
no por el dominio.
Si lo hacemos por el nombre de dominio no podr resolverlo porque no se ha
habilitado el trco saliente DNS ni tampoco entrante.
Vamos a habilitar ahora el trco DNS para comprobar que funcione
correctamente.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 11

Si queremos que desde la mquina local se pueda acceder al servidor web de la
mquina virtual con esta conguracin no debera ser posible ya que no se ha habilitado
el trco entrante que tenga como destino el puerto 80 TCP ni el puerto 53 UDP para el
DNS.
Finalmente en el enunciado se nos pide que se permitan conexiones entrantes
hacia el puerto 22 que es el puerto de SSH.
Con esta regla pasar lo mismo que en anteriores ocasiones, no se deja salir el
trco con origen en el puerto 22 por lo que no podr establecerse una conexin ssh
hacia la mquina.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 12

Para que funcione ejecutaremos la siguiente regla.
Y comprobamos que la conexin desde el cliente se establece correctamente.
Se muestra nalmente el resultado de todas las reglas aplicadas en este apartado.
2.2.3. Comprobacin de la importancia del orden de las reglas
Se nos pide que partamos de una conguracin sin ltrado, para ello borraremos la
tabla de ltrado y jaremos las polticas por defecto en ACCEPT.
La opcin -F se indica para borrar por completo la cadena de reglas, no se ha
indicado en los comandos la tabla porque la tabla de ltrado es la que se toma por defecto
como se ha indicando en ocasiones anteriores.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 13

No hemos hablado anteriormente del orden de las reglas porque no era necesario,
eran todas las reglas de diferentes protocolos. Las reglas son evaluadas en orden, por lo
que si se ponen primero las ms restrictivas no se conseguir el efecto deseado.
Veamos un ejemplo. Queremos bloquear todo el trco saliente TCP salvo el
dirigido a una direccin concreta de nuestra subred. Nos quedamos como era lgico de
nuevo sin la conexin ssh.
Con esta ltima regla se habilita el trco saliente TCP hacia la mquina antriona.
Pero veremos que la realidad es otra, no vamos a poder establecer una conexin SSH
desde la mquina antriona. Y eso es porque primero est la regla ms restrictiva,
establecer una conexin SSH coincide con la primera regla y no se sigue evaluando. Por
tanto si se quiere que funcione se deben de aplicar primero las reglas ms especcas.
Ahora la conexin SSH si debera de funcionar desde la mquina antriona.
Probamos a establecer una conexin SSH desde otra mquina de la misma subred
y observaremos que no funciona, podr aceptar la conexin porque tiene poltica
ACCEPT y la peticin llegar pero no se podr establecer porque la respuesta nunca
podr salir.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 14

2.3. Redireccin de trco
En este apartado se nos pide que se redirija todo el trco web que se realice con
destino www.ceu.es, hacia otro servidor web externo como por ejemplo www.google.es.
Lo ms adecuado para esto ser aplicar reglas de NAT en la cadena de reglas
OUTPUT, que si nos jamos en el diagrama ser la que est en la salida del equipo local.
Y en ese momento cambiaremos la direccin de destino por la que nosotros deseemos.
Esta vez en las reglas si que tendremos que especicar la tabla de la regla puesto que no
va a ser la de ltrado sino la tabla de NAT.
"#$%&'() *$ 0%$ *B <=>8=> *# $.# **5#-1$ IK *5 QQQG.(6G() *N ?RB>
**$-*5()$"0%$"-0 DEJGDSMGJMGFDHTIK
Hacemos la prueba a continuacin.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 15

Se podra haber aplicado la regla tambin por la direccin ip de destino en vez de
por el dominio que sera mejor si por cualquier motivo se bloqueara al servicio DNS.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 16

2.4. Usar IPTables para protegerse de una enumeracin con
NMap
En este apartado se nos indica que probemos a identicar el sistema operativo de
la mquina virtual usando NMAP desde otra mquina. Para posteriormente aplicar una
regla con estado que prohiba las conexiones TCP invlidas y ver posteriormente el efecto
de la regla en la ejecucin de NMap.
NMap analiza las respuestas del objetivo ante patrones de ataque que enva, lo
que hace es enviar muchas peticiones de varios tipos, ya sean normales o mal formadas
(no empezando como una peticin TCP normal que ha de empezar con SYN). Y ante el
patrn de respuesta a dichas peticiones puede saber el sistema operativo y otros datos en
base a una base de datos de patrones de respuesta.
El comando a ejecutar para que se obtenga el sistema operativo es el siguiente.
03%# *< DEFGDHGDIJGDKK
No obstante parece que no se ha detectado el sistema operativo como se
esperaba, posiblemente la versin de CentOS que estamos usando no estn en los
listados de patrones de respuesta de NMap. Hay que tener en cuenta que hemos lanzado
la deteccin sobre una mquina que no tiene levantados servicios salvo el SSH, lo cual
dicultar ms la deteccin lgicamente.
Con este ejercicio se pretenda que se mostrase como despus de introducir una
regla con estado en IPTables se dejase de detectar el sistema operativo ya que se
rechazaran las peticiones TCP mal formadas, de manera que al no detectarse ni siquiera
sin ltro alguno, se puede decir que no se va a ver el resultado completo que se pretenda
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 17

con el ejercicio. No obstante a continuacin vamos a mostrar el comando que se debera
de introducir para el ltro con estado.
IPTables clasica los paquetes en varios estados posibles, para ello se basa en
analizar las conexiones TCP y tambin las conexiones producidas a la vez, por ejemplo
FTP tiene una conexin de control y otra de datos.
NEW: Intentando abrir una nueva conexin.
ESTABLISHED: Parte de una conexin ya existente.
RELATED: Relacionada aunque no realmente parte de una conexin existente

(ejemplo de FTP).
INVALID: No es parte de una conexin existente e incapaz de crear una conexin

nueva.
Si lo que queremos es evitar que se abran conexiones TCP invlidas contra
nuestro servidor lo que haremos ser establecer un ltro con estado que obligue a que las
conexiones se inicien siempre con un segmento SYN. El comando indicado a
continuacin indica que se ha de tirar cualquier conexin en el estado NEW que no sea
un segmento SYN.
"#$%&'() *B 7R8=> *# $.# U **)V0 *3 )$%$( **)$%$( RPW *N ?@<8
Volvemos a lanzar el comando Nmap pero como ya antes no se detect el sistema
operativo poca diferencia observaremos ahora.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 18

Aunque el caso de prueba no ha funcionado de la manera que se esperaba con lo
que hay que quedarse es con el concepto de ltros con estado y el comando que se ha
introducido para rechazar las conexiones TCP invlidas.
2.5. Filtros con estado para ICMP
En este ejercicio se nos pide que se parta de una conguracin sin ltros y con
poltica por defecto de DROP. Posteriormente una vez que est todo el trco bloqueado
se pide denir reglas con estado que permitan el trco ICMP siempre que sea iniciado
por nosotros o relacionado con nuestras conexiones.
Lo primero borramos la tabla del ejercicio anterior y aplicamos la poltica DROP por
defecto en las cadenas de reglas INPUT y OUTPUT.
Con el primer comando mostrado a continuacin permitiremos todas las
conexiones ICP salientes, por tanto podremos establecer nuevas conexiones, abrir otras
relacionadas o que formen parte de la conexin activa. Con la segunda regla permitimos
que nos lleguen conexiones ICMP pero solo las respuestas a las nuestras, no se permite
que se establezca una nueva conexin contra nosotros (no incluido en la regla pero la
poltica es DROP)
"#$%&'() *B <=>8=> *# ".3# *3 )$%$( **)$%$( RPWXPY>BZ+7Y[P?X@P+B>P?
*N BOOP8>
"#$%&'() *B 7R8=> *# ".3# *3 )$%$( **)$%$( PY>BZ+7Y[P?X@P+B>P? *N
BOOP8>
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 19

Si establecemos una nueva conexin desde la mquina antriona a la mquina
virtual no debe ser permitido ya que no se permiten conexiones nuevas en sentido
entrante.
Sin embargo si abrimos la conexin desde la mquina virtual si se recibirn las
conexiones entrantes que son respuesta.

Finalmente visto que funciona vamos a borrar las reglas y poner poltica por
defecto ACCEPT de una manera distinta a como lo hemos estado haciendo. En CentOS
se dispone de un script para realizar acciones con iptables como por ejemplo borrar las
reglas, exportarlas o restaurarlas.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 20

Ahora si que podemos abrir una conexin SSH y veremos como las reglas se han
borrado y las polticas son ACCEPT.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 21

3. Router con funcin de cortafuegos y NAT
Esta ser la segunda parte de la prctica en la que vamos a tener una mquina con
funcin de reenvo de trco e iptables habilitado en ella aplicando reglas en el reenvo de
paquetes. Esta mquina tendr dos interfaces de red en dos sub-redes diferentes, en
cada una de las sub-redes tendremos otra mquina virtual. Por tanto vamos a trabajar con
tres mquinas virtuales en este apartado.
Para la realizacin de este apartado se usar shorewall que es una herramienta
que traduce reglas a ms alto nivel en un chero de conguracin a reglas de IPTables,
esto se hacer porque en el entorno en que vamos a trabajar es bastante ms complejo
que en el caso anterior y si ya vimos que se complicaba anteriormente teniendo que estar
atento no solo a la apertura de conexiones sino a las respuestas y los puertos en que son
originadas. Este escenario ser mucho ms complejo al pasar conexiones entre distintas
subredes y otros aspectos.
3.1. Construccin del escenario
En este apartado vamos a construir el escenario descrito anteriormente. Lo
considero lo sucientemente complejo como para explicar la construccin del mismo y
hacer las pruebas pertinentes de su funcionamiento.
Lo primero que se va a hacer es disponer de varias mquinas virtuales como ya se
ha comentado, han de ser tres.
La primera de ellas que ser la que normalmente hemos estado usando ser la que
va a actuar como router. Lo primero que tendremos que hacer es aadir una segunda
interfaz fsica mediante las opciones de VMWare, la segunda interfaz que aadamos debe
de estar en modo Host-Only para que este una subred diferente.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 22

Reiniciamos ahora el servicio de red de la mquina virtual y se deben de ver las
dos interfaces fsicas cada una en una subred diferente.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 23

El siguiente paso ser arrancar una segunda mquina virtual que se situe dentro de
la subred 172.16.183.0/24 que ser nuestra red privada. Para ello esa mquina debe de
tener la conguracin de red en modo NAT.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 24

Si observamos la direccin IP veremos que est dentro de la subred indicada.

Pasaremos ahora a la conguracin de la tercera y ltima mquina virtual, sta
deber estar en la subred que vamos a llamar pblica que ser la 172.16.212.0/24, para
ello deber estar dentro de la subred que crea VMWare para las mquinas con la interfaz
de red en modo HostOnly.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 25

En este momento el escenario estar congurado correctamente. Tenemos una
mquina virtual que se usar como router con interfaces en la red pblica y en la red
privada y en cada una de esas redes tenemos una mquina virtual con una interfaz que
tienen asignada una direccin IP de la subred correspondiente.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 26

Ahora mismo debera poderse hacer un ping desde y hacia cada una de las
mquinas de la misma subred pero no podr hacerse desde una mquina de una subred
hacia otra mquina de diferente subred ya que la mquina que actuar como router no
tiene habilitada la funcin de reenvo. Esta funcin deber ser habilitada.
Comprobamos ahora que podemos hacer ping con xito en la red privada entre las
dos mquinas que hay en la misma que son la mquina virtual y la interfaz de la mquina
virtual que actuar como router.
Realizaremos el mismo proceso dentro de la red pblica comprobando que las dos
mquinas se puede hacer ping entre s.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 27

Finalmente otro aspecto a comprobar es que si no se aade ninguna ruta en la
tabla de de rutas de la mquina que har la funcin de router en este momento de la
conguracin no se debera poder alcanzar la subred privada desde la red pblica. A la
inversa si que podr ser porque al estar en NAT la red privada, las interfaces de la misma
tienen una puerta de acceso que ser el router de VMWare el cual les permitir llegar.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 28

En este momento se tiene ya congurado el escenario que se nos pide a falta de
hacer algunas conguraciones en las mquinas para habilitar el encaminamiento entre las
dos redes. Dado que hasta ahora lo hemos explicado todo mediante texto vamos a
proponer un grco donde se explica la conguracin actual de la que disponemos.
Privada
172.16.183.0/24
Pblica
172.16.212.0/24
Router
eth0: 172.16.183.100
eth1: 172.16.212.129
VM Red Privada
eth0: 172.16.183.200
VM Red Pblica
eth0: 172.16.212.131
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 29

3.2. Conguracin del escenario
Ahora lo que falta ser completar la conguracin del escenario construido. Para
ello lo que haremos es congurar en la Mquina virtual de la red privada la direccin IP de
eth0 en la mquina que actuar de router como puerta de enlace.
El siguiente paso ser habilitar el reenvo de paquetes en la mquina virtual que
actuar como router. Para ello nos podemos encontrar con varias formas, por ejemplo en
Mandriva se puede hacer modicando el chero de conguracin /etc/syscong/network, y
aadiendo una nueva variable FORWARD_IPV4.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 30

En nuestra distribucin que es CentOS este mismo chero existe, pero al reiniciar
el servicio de red no se habilita la variable de sistema correspondiente al reenvo de
paquetes /proc/sys/net/ipv4/ip_forward. Se puede visualizar el contenido de la variable
con un comando cat.
En nuestra distribucin habr que hacerlo en la conguracin del sistema situada
en el chero /etc/sysctl.conf. En la lnea net.ipv4.ip_forward, se debe asignar a esta
variable el valor binario 1, tal como se puede apreciar en la captura de pantalla.
Si visualizamos ahora la variable que hemos mencionado anteriormente despus
de reiniciar el servicio de red podemos observar como ahora si est habilitada.
La mquina de la red pblica seguir sin tener conexin con la red privada debido a
que no tiene puerta de enlace. De momento no la pondremos puesto que la manera
correcta de alcanzar este puesto ser haciendo NAT, que como veremos se nos pedir
prximamente en el enunciado.
Por otra parte, aunque no conguremos este parmetro, cuando pasemos a los
siguientes apartado en los que se usa Shorewall veremos que funciona igualmente, pero
ser porque en la conguracin de shorewall hay un parmetro para ajustar esto, de
manera que cuando shorewall se active se activar el forwarding de paquetes. Aunque
despus explicaremos los cheros de conguracin de shorewall, este parmetro lo
podemos encontrar en el chero /etc/shorewall/shorewall.conf.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 31

3.3. Instalacin de Shorewall
Para la instalacin de Shorewall nos hemos de dirigir al directorio donde nuestra
mquina virtual tiene los paquetes instalables que ser /usr/local/src/shorewall.
Vemos que tenemos varios paquetes de instalacin rpm, el principal de shorewall y
tambin disponemos de las dependencias del mismo. Instalaremos todos los paquetes.
Lo haremos de la misma manera que hemos instalado paquetes otras veces, con el
comando rpm.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 32

3.4. Conguracin de Shorewall
En este apartado describiremos la conguracin de shorewall para posteriormente
empezar a congurarlo deniendo las reglas que se nos vayan pidiendo en el enunciado.
Los archivos de conguracin estarn situados en el directorio /etc/shorewall.
Como vemos el directorio tiene numerosos cheros, pero nosotros nos
centraremos en seis de ellos que sern los cheros de conguracin.
zones: Archivo de conguracin para denir las zonas
policy: Archivo para denir las polticas por defecto
rules: Fichero de denicin de reglas
masq: Para la conguracin del enmascaramiento
interfaces: Para la identicacin de las interfaces
shorewall.conf: Conguracin general

______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 33

3.4.1. Conguracin de zonas
Lo primero que haremos ser congurar las zonas en el archivo correspondiente.
Cuando lo abramos nos encontraremos que ya tiene una zona dentro del mismo llamada
fw, esta zona hace referencia al mismo equipo. Nosotros tendremos que aadir dos zonas
ms, la zona local o zona de la red privada y la zona pblica.
3.4.2. Conguracin de polticas
En este paso explicaremos el archivo de polticas. Este archivo es usado para
establecer polticas por defecto en el paso de los paquetes de una zona a otra. Es decir,
habr una poltica a aplicar por ejemplo en el paso de la zona privada a la zona pblica,
otra poltica en el sentido inverso, etc... Tambin es posible establecer en este chero de
conguracin el nivel de registro de la actividad (logs), la tasa de conexiones permitidas,
tamao mximo de las rfagas y nmero mximo de conexiones permitidas
simultneamente.
3.4.3. Conguracin de reglas
En este chero se establecen reglas que actuarn como excepciones a las polticas
establecidas en el chero de polticas, cumplen la misma funcin que las reglas de
IPTables. Basndose en un origen y destino de las conexiones y otros parmetros como
el protocolo, el puerto, o las direcciones IP establecer reglas ms especcas.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 34

3.4.4. Conguracin de las interfaces
En este archivo se conguran las interfaces del equipo asocindolos a las zonas en
que estn presentes.
Tambin se indican en este archivo otros parmetros como sus direcciones de
difusin y conguraciones como dhcp si se usa en la subred que gestiona. A continuacin
mostramos una conguracin vlida para nuestro escenario.
3.4.5. Conguracin de enmascaramiento
En el archivo masq se establece en enmascaramiento de direcciones IP en el
trco que atraviesa algunos de los interfaces del cortafuegos.
Las conguraciones se pueden establecer el enmascaramiento por direcciones IP o
especicando la interfaz en la que va a ser enmascarado. Veremos ejemplos en el
apartado correspondiente.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 35

3.5. Conguracin de polticas bsicas
En este apartado se llevar a cabo la conguracin de algunas polticas bsicas
que se nos describen en el enunciado.
Es aceptado el trco local hacia el exterior.
Est prohibido el trco entrante desde el exterior.
Se acepta el trco saliente desde el cortafuegos hacia cualquier zona.
Se acepta trco entrante al cortafuegos desde la red local.

3.5.1. Conguracin previa del escenario
Lo primero que vamos a hacer es poner como puerta de enlace por defecto al
router en la mquina de la subred pblica porque sino no vamos a ser capaces de probar
la correcta conguracin ya que la mquina del exterior no va a poder llegar a la red
privada no porque est impedido sino por problemas de conectividad. Esto no ser en una
situacin normal lo ms adecuado, lo ms adecuado sera usar NAT.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 36

3.5.2. Conguracin de las polticas en Shorewall
Con el objetivo de cumplir las especicaciones enunciadas anteriormente vamos a
congurar el chero policy en situado en /etc/shorewall/policy para establecer las polticas.
Ahora pasamos a aplicar las reglas con el script de shorewall. Observamos que ha
fallado y vamos al log del sistema para observar que es lo que ha ocurrido.
Nos indica que el inicio de shorewall est deshabilitado y tenemos que habilitarlo
en el chero de conguracin general. Esta variable que se nos pide activar est puesta
como seguridad para evitar que shorewall sea activado accidentalmente antes de ser
congurado. Hay que tener en cuenta que un inicio accidental de shorewall en un sistema
administrado remotamente si las reglas no estn conguradas correctamente te puede
dejar sin la conexin remota.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 37

Se puede comprobar que la conguracin que permite trco local hacia el servidor
del rewall se ha establecido correctamente porque no se ha perdido la conexin SSH
mediante la cual estamos administrando la mquina.
Comprobamos ahora que no hay comunicacin desde el exterior a la red local ni al
cortafuegos.
Si que hay comunicacin desde el interior de la red local hacia el exterior, haciendo
ping a la red pblica.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 38

Tambin hay comunicacin desde el cortafuegos hacia cualquier zona.
3.5.3. Enmascaramiento de direcciones
En este apartado se pretende enmascarar direcciones desde la red interior hacia la
red exterior. De manera que si por ejemplo la mquina de la red privada quieres salir al
exterior la direccin origen de esos paquetes ser la de la interfaz pblica del cortafuegos.
Para la realizacin de esta conguracin editaremos el archivo /etc/shorewall/
masq. Como ya comentamos se puede hacer basado en las direcciones o en las
interfaces, de manera que lo podremos congurar de dos formas posibles.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 39

Se reinicia shorewall para activar las nuevas reglas de enmascaramiento.
Para comprobar la correcta conguracin vamos a dejar la mquina de la red
privada enviando pings hacia el exterior en concreto a la direccin 172.16.212.131.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 40

trco de la interfaz eth0 con tcpdump. Con el comando vamos a ltrar los que provengan
de la misma mquina para ver ms clara la salida del comando.
$.#563# *" ($\K )1. \-)$ DEFGDHGDIJGFKK
Observamos una peticin Echo desde la direccin local a la direccin pblica, tal
como habamos hecho el ping.
Ahora pondremos en marcha de la misma manera el tcpdump en la interfaz eth0 en
la mquina de destino pblica, en ella se tienen que ver peticiones Echo con destino ella
misma pero con direccin origen 172.16.212.129.
$.#563# *" ($\K
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 41

Con esto se comprueba que el enmascaramiento de direcciones est funcionando
correctamente.
3.5.4. Conguracin de reglas para las conexiones salientes
En este apartado se nos pide implantar una serie de reglas para las conexiones
salientes de la red privada de manera que la salida est ms restringida.
Conguracin de la poltica por defecto
Lo primero que se nos indica es que por defecto las salidas van a estar rechazadas
exceptuando una serie de servicios, por tanto lo primero que haremos ser cambiar la
poltica por defecto a REJECT (ms adecuado su uso en el interior ya que devuelve un
rechazo).
Tambin se pide en el enunciado que se impida el trco entrante desde el exterior,
que se acepte el trco saliente del cortafuegos hacia cualquier zona y nalmente que el
cortafuegos acepte trco entrante hacia si mismo desde la red local.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 42

Aunque hayamos aplicado polticas aqu por peticin expresa en el enunciado lo
normal sera restringir todo como se indica en el regla nal que en este caso se ha puesto
para que no se dejara de contemplar nada y que lo que se haya quedado sin contemplar
sea denegado.
Como digo, no este el uso normal del chero de polticas, sino que se suele
denegar todo como indico a continuacin y todas las comunicaciones que se quieran
permitir se indican mediante reglas en el chero correspondiente. Al estilo de como se
haca con las polticas de las tablas de iptables.
Las peticiones que vengan de Internet al resto de las zonas de desprecian sin ms,
mientras que las comunicaciones en el resto de las zonas de indica la denegacin dando
informacin y evitando los timeout. De manera que es ms elegante al comportarse de
manera diferente para tus usuarios que para el resto de Internet
Observemos que ahora no es posible hacer un ping desde la red privada hacia el
exterior (despus de haber reiniciado Shorewall). Se nos da un mensaje de error
proveniente del cortafuegos, y ello es debido a haber puesto como poltica por defecto
REJECT en vez de DROP, su hubiramos puesto DROP no devolvera respuesta alguna,
simplemente tirara los paquetes sin responder a ellos.

______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 43

Conguracin de las reglas
Una vez que la poltica ha sido cambiada nos dirigiremos al chero de reglas en el
que especicaremos reglas especcas para los requisitos que el enunciado nos indicar.
El chero que editaremos estar situado en el directorio /etc/shorewall/rules.
Se nos pide que habilitemos la sida de una serie de servicios como por ejemplo
http, https, SMTP, etc... En el chero de conguracin vemos que se establece el origen y
destino y vemos que en el caso de los puerto podemos poner tanto el puerto especco
como el nombre del servicio.
Aadimos tambin la posibilidad de usar ICMP hacia el exterior ya que es ms fcil
hacer as las pruebas.
Reiniciamos Shorewall para aplicar las reglas y pasamos a realizar las pruebas
pertinentes.
Probamos en primer lugar a realizar el ping que probamos anteriormente desde la
red privada hacia el exterior y vemos que funciona correctamente.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 44

Levantamos un servidor web en la mquina de la red pblica para comprobar que
funciona tambin la salida de la red privada para hacer consultas a pginas web.
Nos situamos en la mquina de la red privada e intentamos visitar una web en la
direccin 172.16.212.131 que es la mquina de la red pblica.
Observamos que la conguracin ha sido correcta ya que se ha mostrado la pgina
que se esperaba, que ha sido un index.html que hemos situado en el servidor web recin
levantado en la mquina pblica.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 45

Conguracin de Port Forwarding
En el enunciado tambin se nos indica que hagamos pblico algn servicio de la
red privada hacia el exterior. Por ejemplo un servidor web que se levante dentro la
mquina de la red privada al que se pueda entrar desde una mquina de la red pblica.
Para que esto sea posible las peticiones enviadas a la direccin pblica de la red
privada (172.16.212.129) y al puerto 80 sern redirigidas a la direccin IP del servidor web
en el puerto 80. Esto recibe el nombre de port-forwarding.
Con la regla indicada lo que hacemos es especicar un cambio en la direccin de
destino mediante el uso de Destination-NAT (DNAT) para las peticiones que vayan
dirigidas al puerto 80 de la direccin pblica de la red privada y su destino pasar a ser el
de la mquina 172.16.183.200 (manteniendo el mismo puerto).
Lo primero que vamos a hacer para probar la conguracin ser eliminar la puerta
de enlace por defecto de la mquina pblica ya que al haber implementado DNAT ya
puede alcanzar la red privada sin problemas (en las conexiones para las que haya DNAT).
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 46

Ahora en la conguracin del router reiniciamos shorewall para aplicar la regla
congurada, y en la mquina privada 172.16.183.200 hemos de levantar un servidor web.
Ahora en la mquina pblica intentamos acceder a la direccin pblica de la red
privada desde un navegador.
Se nos debe de mostrar una pgina web creada en un index.html sobre el servidor
web que se ha levantado en la mquina privada.
Con esta prueba queda comprobado que la regla de DNAT est funcionando
correctamente.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 47

Conguracin de acceso va SSH al cortafuegos desde el exterior
En este apartado se pretende congurar un acceso SSH al servidor en el cual est
implementado el cortafuegos, pero desde el exterior, recordemos que la poltica para
estos casos era DROP.
Tambin se especica que el acceso solo se permita desde una direccin de la red
pblica concreta. Para realizar esta conguracin acudiremos de nuevo al chero de
reglas.
Reiniciamos shorewall para aplicar la nueva regla.
Comprobamos su correcto funcionamiento y vemos que el funcionamiento es
correcto.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 48

Si queremos probar que de verdad solo se admite la conexin SSH desde la
mquina que hemos especicado podemos levantar una cuarta mquina en la red
pblica, que deber estar con la interfaz en modo Host Only.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 49

______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 50

Redireccin del trco DNS
En este caso se nos indica que todo el trco DNS saliente se debe redirigir a un
servidor DNS externo concreto. Por ejemplo, todas las peticiones DNS que se hagan
desde la red local van a ser redirigidas al DNS 8.8.8.8 que es el DNS de google.
Esto lo haremos mediante DNAT, las peticiones que vengan desde la red privada al
puerto 53 UDP sern redirigidas a la IP 8.8.8.8 en el mismo puerto. No se incluye el
puerto 53 TCP porque las peticiones DNS no lo usan, solo se usa para sincronizacin
entre servidores DNS.
El ejemplo que hemos puesto no va a funcionar porque en nuestro esquema
consideramos como net una red del entorno virtual de VMWare que no tiene salida al
exterior. Pero si que vemos la conguracin que se ha de aplicar.
Por no levantar un servidor DNS y congurar zonas en el equipo de la red pblica
vamos a hacer el mismo ejemplo con un servidor HTTP que es ms fcil de arrancar. En
el chero de conguracin de reglas podremos una lnea de conguracin parecida tal
como se muestra en la siguiente captura, la nica diferencia es que ahora se dirigirn las
peticiones a la direccin IP de la mquina virtual en la red pblica, en cuanto el protocolo
ser el protocolo TCP por el puerto 80 que es por donde se realiza el trco HTTP.
Ahora con la nueva regla introducida despus de reiniciar shorewall para aplicar las
reglas lo que veremos es que cualquier trco web originado en la subred privada nos
llevar a la direccin IP indicada.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 51

______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 52

4. Apartados opcionales
4.1. Securizar servidor SSH contra ataques de fuerza bruta
El enunciado nos pone bajo el supuesto de que tenemos un servidor ssh que est
siendo atacado con intento de obtener las contraseas mediante fuerza bruta, para lo cual
se estn registrando peticiones de acceso continuas al mismo.
Para evitar esto se puede tratar de reducir el nmero de accesos por direccin IP.
Con el siguiente comando estaramos reduciendo el nmero mximo de conexiones
paralelas al servidor por la direccin del cliente.
"#$%&'() *B 7R8=> *# $.# **)V0 **5#-1$ FF *3 .-00'"3"$ **.-00'"3"$*
%&-9( J *N @P]PO>
"#$%&'() *B 7R8=> *# $.# **)V0 **5#-1$ IK *3 .-00'"3"$ **.-00'"3"$*
%&-9( FK **.-00'"3"$*3%)^ FM *N ?@<8
connlimit-above: Si el nmero de conexiones existentes es mayor que lo indicado.
connlimit-mask: Para aplicar la regla por un grupo de hosts, el nmero indica la
longitud de la mscara.
Si lo que queremos es poder limitar las conexiones en el tiempo podemos usar el
mdulo recent el cual permite monitorizar conexiones recientes con lo cual podramos
limitar el nmero de intentos por minuto por ejemplo.
Necesitaremos dos comandos.
"#$%&'() *B 7R8=> *# $.# **)V0 **5#-1$ FF *3 )$%$( **)$%$( RPW *3
1(.(0$ **)($
"#$%&'() *B 7R8=> *# $.# **)V0 **5#-1$ FF *3 )$%$( **)$%$( RPW *3
1(.(0$ **6#5%$( **)(.-05) HK **\"$.-60$ M *N ?@<8
El primer comando tomar las peticiones de inicio de sesin a SSH y al haber
puesto el ag SET nos asegura que tomar las direcciones IP de los clientes y las aadir
a la lista de direcciones recientes que necesita el mdulo recent para poder comprobar las
conexiones recientes.
La segunda regla es donde ocurrir el ltrado. El ag UPDATE comprobar si las
direcciones IP de las nuevas conexiones al puerto 22 ya existen en la lista de conexiones
recientes. El ag SECONDS establece el intervalo de tiempo en segundos. Finalmente la
opcin HITCOUNT establece el nmero de ocurrencias que debe haber de este tipo de
paquetes para aplicar la accin de la regla.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 53

Resumiendo, la segunda regla har un DROP de una conexin si la direccin IP
que inicia la conexin ya est en la lista de recientes, ha mandado algn paquete en los
ltimos 60 segundos y esos paquetes enviados han sido ms de 4 en total.
Respecto a limitar el nmero mximo de intentos de login por cada sesin ya no es
algo que se pueda hacer con iptables, es ms bien algo propio de SSH por tanto este
ajuste lo realizaremos mediante las conguraciones de OpenSSH, lo haremos con la
opcin MaxAuthTries. Es interesante aplicar esto porque si por ejemplo limitamos a dos
los intentos ya no se puede intentar ms veces en la misma conexin por lo que se tendr
que abrir otra y en pocas ms que lo intente ya ser restringido por las propias reglas de
iptables que hemos especicado anteriormente.
Hemos congurado los comandos de iptables que hemos indicado como se puede
mostrar en la siguiente captura.
Tambin hemos realizado la conguracin de mximo dos intentos de login en el
chero de conguracin de SSH y hemos reiniciado el servicio.
Ahora realizamos varios intentos de login continuos y comprobamos el efecto que
han tenido las reglas conguradas. Veremos que no nos deja ms que dos intentos por
conexin y no nos dejar intentarlo ms de tres veces.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 54

Tambin disponemos de la opcin MaxStartups que limita el nmero mximo de
pantallas de login o conexiones simultneas de login. Si bien es cierto que una vez que la
sesin haya sido iniciada se pueden tener ms terminales de ssh, el nmero se reere
solo a pantallas de login. Por tanto como vemos se puede proteger el acceso a servidor
ssh contra ataques de fuerza bruta con unos pocos ajustes.
La informacin referente a los comando de IPTables para este apartado ha sido
obtenida de la siguiente pgina web: http://soi57.net/blog/iptables-para-limitar-el-numero-
de-conexiones-entrantes/. Por otra parte se ha encontrado en esta otra pgina web las
opciones para securizar SSH mediante la conguracin del mismo servidor: http://
www.linuxtotal.com.mx/index.php?cont=info_seyre_004.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 55

4.2. Control y limitacin del ancho de banda
Gracias a la funcin de modicacin de iptables es posible usarlo para marcar la
cabecera de determinados paquetes atendiendo a condiciones como las que se han visto
durante el desarrollo de la prctica. Posteriormente, una vez han sido marcados los
paquetes es posibles usar Trafc Control (TC) para aplicar restricciones de ancho de
banda a las clases identicadas.
Conguracin de Trafc Control
Supongamos una interfaz eth4 de un router en el ejemplo que trataremos. Vamos a
crear dos clases de trco 1:10 y la 1:12, por defecto todo el trco se dirige a la de
menor prioridad que es la ltima mencionada. La primera mencionada que es la clase
1:10 tiene una mayor prioridad, si hay algo pendiente de enviar en esta clase ser
enviado por encima de la clase 1:12.
Por otra parte la clase de trco 1:10 tiene un ratio de 100kbit, aunque puede usar
todo el ancho de banda de 1500kbit compartindolo con la clase 1:12.
El trco UDP (protocolo 0x11 0xff de la cabecera IP) ser puesto en la clase de
prioridad mxima 1:10, lo que ser bueno para juegos en primera persona para asegurar
una latencia baja y que no se vea perjudicado por el trco de menor prioridad.
Llegados a este punto se puede ver que se han creado dos canales de salida de
diferentes prioridades, sabiendo que el de mayor prioridad puede llegar a perjudicar al de
menor prioridad tal y como se desea. El problema es que tanto el trco de baja prioridad
como el de alta prioridad pueden ser perjudicados por ujos de gran ancho de banda,
causando que otros ujos de la misma prioridad se vean perjudicados por estos.
Para poner solucin al problema planteado se aaden dos colas SFQ (Stochastic
Fairness Queueing) a las clases de baja prioridad y alta prioridad para asegurar que los
ujos individuales de trco son identicados y cada uno de ellos cuenta con la misma
oportunidad de enviar sus datos de las respectivas clases. Esto debera evitar el problema
de inanicin dentro de las mismas clases.
SFQ es un algoritmo de la familia de Fair Queing, menos preciso que otros pero
por otra parte con menor necesidad de clculo. Estas colas dividen por conversaciones o
ujos TCP, lo que hace que se cree un gran conjunto de colas FIFO, una por cada
conversacin, dando la misma oportunidad a las conversaciones, lo que evita como se ha
comentado que se provoque inanicin entre distintas conversaciones de la misma
prioridad.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 56

3-5(3"A_($\M
$. `5"). %55 5(9 a3-5(3"A 1--$ \%05'( DT \$& 5(A%6'$ DF
$. .'%)) %55 5(9 a3-5(3"A #%1(0$ DT .'%))"5 DTD \$& 1%$( DbKK^&"$ .("'
DbKK^&"$ &61)$ DK^
$. .'%)) %55 5(9 a3-5(3"A #%1(0$ DTD .'%))"5 DTDK \$& 1%$( EKK^&"$ .("'
DbKK^&"$ #1"- D &61)$ DK^
$. .'%)) %55 5(9 a3-5(3"A #%1(0$ DTD .'%))"5 DTDF \$& 1%$( IKK^&"$ .("'
IKK^&"$ #1"- F
$. A"'$(1 %55 5(9 a3-5(3"A #1-$-.-' "# #%1(0$ DTK #1"- D 6JF 3%$.\ "#
#1-$-.-' KcDD KcAA A'-Q"5 DTDK
$. `5"). %55 5(9 a3-5(3"A #%1(0$ DTDK \%05'( FKT )A` #(1$61& DK
$. `5"). %55 5(9 a3-5(3"A #%1(0$ DTDF \%05'( JKT )A` #(1$61& DK
Conguracin de IPTables
En lo referido a la conguracin de iptables hemos aadido las reglas en la etapa
de POSTROUTING. Esto permite modicar los paquetes antes de que sean encolados
para su envo por una determinada interfaz de salida, y esto es justo lo que nos interesa.
En ese punto los paquetes pueden haber sido generados en la propia mquina
localmente o provenir de otra mquina y estar ah para ser reenviados,
independientemente de que estn preparados para salir por la misma interfaz (eth4 en
este caso). Pasarn todos ellos por la cadena de mangle de esta etapa y ser ah donde
se clasique el trco y se realicen otros ajustes.
En las reglas de iptables que vamos a ver a continuacin se puede ver que todo el
trco es ajustado con el ag de mnimo retardo "minimize-delay (trco ssh interactivo
por ejemplo) en las clases de alta prioridad. Tambin todo el trco HTTP, HTTPS, y DNS
TCP ser clasicado como de alta prioridad. Recordando tambin que todo el trco UDP
ser de alta prioridad, lo que incluir todo el trco DNS UDP.
3-5(3"A_($\M
"#$%&'() *$ 3%0d'( *B 8<Y>@<=>7Re *- a3-5(3"A *# $.# *3 $-) **$-)
f"0"3":(*?('%V *N O+BYY7gh **)($*.'%)) DTDK
"#$%&'() *$ 3%0d'( *B 8<Y>@<=>7Re *- a3-5(3"A *# $.# **5#-1$ bJ *N
O+BYY7gh **)($*.'%)) DTDK
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 57

"#$%&'() *$ 3%0d'( *B 8<Y>@<=>7Re *- a3-5(3"A *# $.# **5#-1$ IK *N
"#$%&'() *$ 3%0d'( *B 8<Y>@<=>7Re *- a3-5(3"A *# $.# **5#-1$ MMJ *N
Por la informacin que se ha podido obtener a estas reglas las deberan
acompaar otras bajo las mismas condiciones en la tabla de ltrado porque estas reglas
aplican las modicaciones sobre los paquetes pero no hace que los mismos abandonen la
cadena de reglas, por tanto habra que aadir las reglas ACCEPT correspondientes en la
tabla de ltrado.
Como se explic al principio se usa IPTables para clasicar el trco y Trafc
Control actuar segn las reglas especicadas sobre las clases de trco que vendrn
indicadas en los paquetes al haber sido marcadas con las opciones de mangle.
Se ha obtenido este ejemplo y las rdenes de Trafc Control e IPTables de la
siguiente pgina web: http://www.funtoo.org/Trafc_Control.
______________________________________________________________________________________
______________________________________________________________________________________
Jdyb - Mayo 2013 58

IPTables-Shorewall MemoriaSDC

Cargado por

Información del documento

Título original

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

IPTables-Shorewall MemoriaSDC

Cargado por

Copyright:

Formatos disponibles

Software de Comunicaciones

Prctica 9 - Filtrado de Paquetes.

NEW: Intentando abrir una nueva conexin.

ESTABLISHED: Parte de una conexin ya existente.

RELATED: Relacionada aunque no realmente parte de una conexin existente

INVALID: No es parte de una conexin existente e incapaz de crear una conexin

zones: Archivo de conguracin para denir las zonas

policy: Archivo para denir las polticas por defecto

rules: Fichero de denicin de reglas

masq: Para la conguracin del enmascaramiento

interfaces: Para la identicacin de las interfaces

shorewall.conf: Conguracin general

Es aceptado el trco local hacia el exterior.

Est prohibido el trco entrante desde el exterior.

Se acepta el trco saliente desde el cortafuegos hacia cualquier zona.

Se acepta trco entrante al cortafuegos desde la red local.

También podría gustarte