En el post anterior sobre shorewall 4.2 expliqué su instalación y configuración para una red básica. Ahora voy a documentar lo mismo pero con la última versión de shorewall 4.4. La nueva versión tiene cosas muy interesantes pero la que a mi más me interesó es el soporte de flow (“flow” traffic classifier, lo explicaré en otro post).
Definición de la red
eth1: Interfase para conexión a internet (ip dinámica)
eth2: Interfase para la red local (192.168.8.0/24)
Hacemos una copia de la instalación anterior y eliminamos (si existe)
1 2 3 | mkdir shorewall.old cd shorewall.old sudo mv /etc/shorewall/* ./ |
Descargamos e Instalamos
1 2 3 4 5 6 | mkdir shorewall cd shorewall wget http://shorewall.de/pub/shorewall/4.4/shorewall-4.4.4/shorewall-4.4.4.1.tar.bz2 tar jxf shorewall-4.4.4.1.tar.bz2 cd shorewall-4.4.4.1 sudo ./install.sh |
Documentación oficial
En toda instalación de un firewall hay particularidades, por lo que recomiendo leer la documentación oficial de shorewall. Iré poniendo links a la documentación oficial sobre cada acción.
[DOC] Sobre la estructura de los ficheros de configuración
Comandos necesarios para el arranque: /etc/shorewall/init
Que cargue con el modulo de IFB, creando solo un dispositivo que será ifb0.
1 2 3 | qt modprobe ifb numifbs=1 qt ip link set dev ifb0 up qt mkdir -p /var/lock/subsys/ |
/etc/shorewall/interfaces
1 2 3 | #ZONE INTERFACE BROADCAST OPTIONS net eth1 loc eth2 detect dhcp |
/etc/shorewall/masq
[DOC] NAT – NAT2
1 2 | #INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC MARK eth1 192.168.8.0/24 |
/etc/shorewall/zones
[DOC] Zonas bajo control
1 2 3 4 | #ZONE TYPE OPTIONS IN OUT fw firewall net ipv4 loc ipv4 |
/etc/shorewall/policy
[DOC] Politica general
1 2 3 4 5 6 | #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST loc net ACCEPT loc $FW ACCEPT $FW loc ACCEPT $FW net ACCEPT all all REJECT info |
/etc/shorewall/rules
[DOC] Reglas
1 2 3 4 5 6 7 8 | # ACTION SOURCE DEST PROTO DEST PORT(S) ORIGINAL DESTRATE LIMIT # Redirección de puertos DNAT net loc:192.168.8.78 tcp 5900 DNAT net loc:192.168.8.78 tcp 8500:8600 DNAT net loc:192.168.8.78 udp 8500:8600 # FROM Net TO firewall ACCEPT net $FW icmp ACCEPT net $FW tcp 22 |
* Hasta aquí es lo básico en cuando a seguridad y NAT, con esto la red ya funciona. A partir de aquí es QoS o Traffic Shaping.
/etc/shorewall/tcdevices
[DOC] Devices – Redirigir el tráfico a IFB
1 2 3 4 | #NUMBER: IN-BANDWITH OUT-BANDWIDTH OPTIONS REDIRECTED #INTERFACE INTERFACES 1:eth1 - 300kbit classify 2:ifb0 - 6000kbit classify eth1 |
/etc/shorewall/tcclasses
[DOC] Clases
Ahora es donde voy a dar mi opinion sobre como deberían ir estas clases, esto depende de la experiencia de cada uno, pero en fin, esta es la mía:
- Dividir en tres partes VoIP y Video IP (1:10 y 2:10) , ICMP/DNS y puertos conocidos (1:11 y 2:11) y por último tráfico desconocido (1:19 y 2:19)
- Antes le daba mayor prioridad a SSH o ICMP y en mantenimientos he cortado llamadas y en alguna prueba de rendimiento también me quede sin teléfonos (que también puede ser un ataque DDoS u otros..)
- La segunda clase sera para icmp y dns y tráfico conocido, y esta esta dividida en subclases con el fin de garantizar un mínimo a cada conexión
- En mi red tengo un servidor DNS para que los equipos no vayan a buscar cada dominio en internet, de modo que al DNS le doy más prioridad que al trafico en si mismo ya que se realiza pocas veces y agiliza la navegación
- Y ya que tengo servicios dentro de la red que son utilizados en ocasiones desde fuera de ella considero que se aplican los mismos principios para el trafico entrante
- Sobre los porcentajes que he utilizado en este ejemplo es por el ancho de banda que tengo en esa instalación, esto cada uno lo tiene que mirar pero yo he intentado garantizar 128kbit a la voip tanto de subida como de bajada
- Lo de enviar el tráfico desconocido a la última clase es para evitar el esfuerzo y la complicación de identificar las conexiones P2P, hay otras técnicas pero al final después de muchas pruebas esto es lo que me ha resultado más fácil de mantener
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | #INTERFACE:CLASS MARK RATE: CEIL PRIORITY OPTIONS ## DMAX:UMAX # # # # eth1 # # 1:10 - full*43/100 full*9/10 1 tcp-ack,tos-minimize-delay # voip 1:11 - full*47/100 full*9/10 2 tcp-ack,tos-minimize-delay # icmp / dns 1:11:101 - full*2/10 full 11 # openvpn 1:11:102 - full*2/10 full 12 # vnc 1:11:103 - full*2/10 full 13 # http/https 1:11:104 - full*2/10 full 14 # mail 1:11:105 - full*2/10 full 15 # irc,msn,... 1:19 - full*10/100 full*9/10 99 tos-minimize-cost,default # # # # ifb0 # # 2:10 - full*3/100 full*9/10 1 tcp-ack,tos-minimize-delay # voip 2:11 - full*87/100 full*9/10 2 tcp-ack,tos-minimize-delay # icmp / dns 2:11:101 - full*2/10 full 11 # openvpn 2:11:102 - full*2/10 full 12 # vnc 2:11:103 - full*2/10 full 13 # http/https 2:11:104 - full*2/10 full 14 # mail 2:11:105 - full*2/10 full 15 # irc,msn,... 2:19 - full*10/100 full*9/10 99 tos-minimize-cost,default |
/etc/shorewall/tcfilters
[DOC] Filtros para identificar el tráfico
Yo he identificado estos puertos como útiles para mi red, como decía antes, cada uno sabrá lo que le es útil y lo que no.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | #INTERFACE: SOURCE DEST PROTO DEST SOURCE #CLASS PORT(S) PORT(S) # # OUTGOING TRAFFIC # 1:10 - - udp - 4569,5060 1:10 - - tcp - 4569,5060 1:11 - - icmp echo-request,echo-reply 1:11 - - tcp - 53,22 1:11 - - udp - 53 1:101 - - udp - 1194 1:101 - - tcp - 1194 1:102 - - tcp - 5900 1:103 - - tcp - 80,443 1:104 - - tcp - 25,465,110,995,143,993 1:105 - - tcp - 1493,1542,1863,1963,5222,6667 # # # # INCOMING TRAFFIC # # 2:10 - - udp 4569,5060 2:10 - - tcp 4569,5060 2:11 - - icmp echo-request,echo-reply 2:11 - - tcp 53,22 2:11 - - udp 53 2:101 - - udp 1194 2:101 - - tcp 1194 2:102 - - tcp 5900 2:103 - - tcp 80,443 2:104 - - tcp 25,465,110,995,143,993 2:105 - - tcp 1493,1542,1863,1963,5222,6667 |
Esto es todo, ahora compilamos:
1 | sudo /etc/init.d/shorewall restart |
Hola, queria consultarte si es posible realizar esto mismo pero controlando por ip las velocidades, es decir, hacer un QoS que funcione por IP y dando limites por clases tambien. Un saludo y gracias.
Hola @Emiliano, Si se puede. En el fichero tcfilters puedes añadir IP en lugar de puertos. En este manual he puesto solo puertos, se aplica a todos los usuarios por igual. Pero tu podrías añadir un filtro más por ip, este clasificaría todo el tráfico de esa IP hacia una class con más o menos prioridad, según necesites.
Ejemplo (esto no funcionaría con el manual de este post, hay que crear las clases específicas):
# /etc/shorewall/tcfilters
1:130 192.168.10.11 –
2:130 – 192.168.10.11
Esto enviaría todo el tráfico de 192.168.10.11 a las clases 1:130 y 2:130 (incomming y outgoing). También podrías definir una clase de la red 192.168.10.0/24
Hola Gabriel,
Tenemos un servidor en proceso de actualización con la versión 4.0.15-1 en Debian, ahora he instalado Shorewall en Ubuntu con la versión 4.4.6-1 y he tenido varios WARNINGS y un ERROR corregido al clonar parte de la configuración.
Si me permites me gustaría saber (si está en tu conocimiento) si hay diferentes soluciones a las que yo he aplicado y de lo contrario pues que sirva para si alguien se encuentra.
En primer lugar parece que la regla “norfc1918” que configuraba en el fichero interface ha dejado de utilizarse, la he tenido que quitar junto a RFC1918_LOG_LEVEL de la configuración de Shorewall.
Las direcciones de broadcast tb deben haber sido dejadas de hacer servir ya que me daba el aviso, en su lugar he utilizado el parámetro detect
El ERROR que me daba exactamente era Invalid VLSM (255.255.192.0), por lo que investigué parece ser que ya no se acepta la forma de colocar la mascara con IP/mascara. En su lugar he utilizado el formato CIDR IP/rango.
Te suena?