Muchos administradores de linux intentan cotrolar el ancho de banda de sus usuarios pero no encuentran como una opcion de seria con el controlador de trafico (tc) y un temporizador (htb). Son herramientas, que al formar parte del propio sistema operativo tiene un elevado nivel de eficiencia y precisión. Además de ser muy eficiente, es muy sencillo anular su efecto ya que con una simple línea, se anulan los efectos producidos.
Establece primero el ancho de banda máximo disponible en tu línea de transmisión, este valor puede ser, por ejemplo, de 10Mbps (Clase 1). Luego define todos los límites previstos o CLASES. Por ejemplo para definir que diferentes límites serán (sin importar aún a que corresponde cada límite)
512Kbps (Clase 2)
256Kbps (Clase 3)
24Kbps (Clase 4).
Con estos valores tienes definidas 4 CLASES.
Algunos servicios, usuarios o subnets, con 1Mbps, otros con 512Kbps, otros con 256Kbps y los últimos con 24Kbps.
Luego de definidas las CLASES, debes definir que corresponderá a cada clase, por ejemplo, gerencia tendrá el máximo ancho de banda posible (Clase 1), el correo corporativo será de Clase 3, Internet Clase 4, Desarrollo Clase 2, Videoconferencia Clase 1, y el resto de usuarios estarán limitados a la Clase 4.
Luego que has definido los parámetos del sistema debes crear el Script que implemente el "limitador".
Suponiendo que el limitador se aplicará, en un servidor Linux por donde pasa todo el tráfico de Internet, videoconferencia y correo corporativo. Este servidor tiene dos placas de red, una externa (eth0) y la otra interna (eth1). Tu proveedor de Internet conectado a eth0 brinda un ancho de banda de 1Mbps. Tu red interna está configurada para funcionar a 10Mbps máxima. Además tienes contratado un enlace punto a punto con una sucursal de 64Kbps por el cual viaja tanto, internet, correo corporativo y canales de voz.
La distribución de direcciones ip y puertos es la siguiente:
a)La Gerencia forma una subnet con la siguiente numeración: 172.16.21.0/24.
b)Nuestra sucursal es la subnet 172.16.31.0/24
100. El resto de los usuarios pertenecen a la subnet 172.16.1.0/24
d)El puerto usado por nuestro proxy de internet es el 3128
Definimos 4 clases de ancho de banda:
1. 10Mbps
2. 256 Kbps
3. 128 Kbps
4. 24Kbps
Definimos que grupo pertenece a cada clase.
Gerencia pertenecerá a la Clase I
Internet pertenecerá a la Clase II
El resto de los usuarios ocupará la Clase III
La sucursal será parte de la Clase IV.
En el caso de la sucursal, los servicios de internet y correo corporativo estarán limitados a 24Kbps, dejando el resto para canales de voz y otros servicios que no pasen por el servidor donde instalaremos el limitador.
El Script tendría el siguiente contenido:
#!/bin/bash
#Definimos la placa de red interna, ya que es la que nos interesa administrar.
DEV=eth1
#Definimos el camino al comando "tc", en caso de que no este en el PATH
TC=tc ; este es el caso en el que esta en el PATH
#Definimos todos los limites de ancho de banda a utilizar en Kbps.
RATE1=1000
RATE2=256
RATE3=128
RATE4=24
# Esta linea elimina toda posible definición anterior de FILTROS y CLASES
$TC qdisc del dev $DEV root 2>&1 >/dev/null
#Definimos las CLASES existentes, ademas de la CLASE root y la CLASE master que son necesarias para el funcionamiento del script, pero que no debemos modificar.
#CLASE root y master
$TC qdisc add dev $DEV root handle 1: htb default 60
$TC class add dev $DEV parent 1: classid 1:1 htb rate ${RATE1}kbit
#CLASES y orden prioridad
#CLASE I
$TC class add dev $DEV parent 1:1 classid 1:10 htb rate ${RATE}kbit ceil ${RATE}kbit prio 1
$TC qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
#CLASE II
$TC class add dev $DEV parent 1:1 classid 1:20 htb rate ${RATE2}kbit ceil ${RATE2}kbit prio 2
$TC qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
#CLASE III
$TC class add dev $DEV parent 1:1 classid 1:30 htb rate ${RATE3}kbit ceil ${RATE3}kbit prio 3
$TC qdisc add dev $DEV parent 1:30 handle 30: sfq perturb 10
#CLASE IV
$TC class add dev $DEV parent 1:1 classid 1:40 htb rate ${RATE4}kbit ceil ${RATE4}kbit prio 1
$TC qdisc add dev $DEV parent 1:40 handle 40: sfq perturb 10
#Ya están las 4 CLASES definidas, ahora hay que definir los FILTROS.
# FILTRO1 (Subnet GERENCIA a CLASE I)
$TC filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip dst 172.16.21.0/24 flowid 1:10
$TC filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip src 172.16.21.0/24 flowid 1:10
# FILTRO2 (INTERNET a CLASE II)
$TC filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip dport 3128 flowid 1:20
$TC filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip sport 3128 flowid 1:20
# FILTRO3 (Subnet RESTO USUARIOS a CLASE III)
$TC filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip dst 172.16.1.0/24 flowid 1:30
$TC filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip src 172.16.1.0/24 flowid 1:30
# FILTRO4 (Subnet SUCURSAL a CLASE IV)
$TC filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip dst 172.16.31.0/24 flowid 1:40
$TC filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip src 172.16.31.0/24 flowid 1:40
#Ya esta listo para correr, si queremos podemos mostrar las clases y limites establecido (no muestra a quien pertenece cada subnet o servicio).
$TC qdisc show dev $DEV
$TC class show dev $DEV
#Fin del Script
viernes, 17 de febrero de 2012
Siete pasos para mejorar la seguridad SIP en Asterisk
Aqui les dejo unos excelente consejos que escribio Rodrigo A. MArtin para mejoras la seguridad sip en asterisk.
En los últimos meses han aparecido una serie de nuevas herramientas que hace
posible a cualquier novato atacar y cometer fraudes en equipos SIP, incluyendo los
sistemas basados en Asterisk.
Existen herramientas fácilmente disponibles que hacen un barrido de redes en
busca de hosts que ofrezcan servicios SIP, luego, una vez encontrado, realiza un
barrido en busca de extensiones y contraseñas.
Exiten ciertas reglas, de aplicación inmediata, que eliminan muchos de los
problemas de seguridad, protegiendo al servidor Asterisk de los barridos masivos y
los ataques posteriores. Estos métodos y herramientas de protección ya existen,
simplemente hay que aplicarlos.
1) No aceptar pedidos de autenticación SIP desde cualquier dirección IP.
Utilizar las líneas “permit=” y “deny=” de sip.conf para sólo permitir un
subconjunto razonable de direcciones IP alcanzar cada usuario/extensión listado en
el archivo sip.conf. Aún aceptando llamadas entrantes desde “anywhere” (via
[default]) no se debe permitir a esos usuarios alcanzar elementos autenticados.
2) Estblecer el valor de la entrada “alwaysauthreject=yes” en el archivo
sip.conf. Esta opción está disponible desde la versión 1.2 de Asterisk, pero su por
defecto su valor es "no", lo que puede ser potencialmente inseguro. Estableciendo
este valor en "yes" se rechazarán los pedidos de autenticación fallidos utilizando
nombres de extensiones válidas con la misma información de un rechazo de usuario
inexistente. De esta forma no facilitamos la tarea al atacante para detectar
nombres de extensiones existentes utilizando técnicas de "fuerza bruta".
3) Utilizar claves SEGURAS para las entidades SIP. Este es probablemente la
más importante medida de seguridad. Si alguna vez viste programas que generan y
prueban claves por fuerza bruta sabrás que se necesita algo más que palabras y
números para una clave segura. Usar símbolos, números, una mezcla de letras
minúsculas y mayúsculas y al menos 12 caracteres de largo.
4) Bloquear los puertos del Asterisk Manager Interface. Usar “permit=” y
“deny=” en manager.conf para limitar las conexiones entrantes sólo a hosts
conocidos. Una vez más utilizar claves seguras aquí también, 12 caracteres al
menos en una combinación de números, letras y símbolos.
5) Permitir sólo una o dos llamadas por vez por entidades SIP cuando sea
posible. Limitar el uso no autorizado de las líneas voip es una sabia decisión, esto
también es util para el caso que usuarios legítimos hagan pública su clave y pierdan
control de su uso.
6) Los nombres de usuarios SIP deben ser diferentes que sus extensiones.
A pesar de ser conveniente tener una extensión “1234Z que mapee a una entrada
SIP “1234Z la cual es también el usuario SIP “1234Z, esto también facilita a los
atacantes para descubrir nombres de autenticación SIP. En su ligar usar las
direciones MAC del dispositivo, o alguna combinación de frases comunes +
extensión MD5 hash (por ejemplo: desde el shell prompt, hacer “md5 -s
ThePassword5000Z)
7) Asegurarse que el contexto [default] sea seguro. No permitir que
llamadores no autenticados alcancen contextos que les permitan llamar. Permitir
sólo una cantidad limitada de llamadas activas pasen por el contexto default
(utilizar la función “GROUP” como contador). Prohibir totalmente las llamadas no
autenticadas (si es que así lo queremos) estableciendo “allowguest=no” en la parte
[general] de sip.conf.
En los últimos meses han aparecido una serie de nuevas herramientas que hace
posible a cualquier novato atacar y cometer fraudes en equipos SIP, incluyendo los
sistemas basados en Asterisk.
Existen herramientas fácilmente disponibles que hacen un barrido de redes en
busca de hosts que ofrezcan servicios SIP, luego, una vez encontrado, realiza un
barrido en busca de extensiones y contraseñas.
Exiten ciertas reglas, de aplicación inmediata, que eliminan muchos de los
problemas de seguridad, protegiendo al servidor Asterisk de los barridos masivos y
los ataques posteriores. Estos métodos y herramientas de protección ya existen,
simplemente hay que aplicarlos.
1) No aceptar pedidos de autenticación SIP desde cualquier dirección IP.
Utilizar las líneas “permit=” y “deny=” de sip.conf para sólo permitir un
subconjunto razonable de direcciones IP alcanzar cada usuario/extensión listado en
el archivo sip.conf. Aún aceptando llamadas entrantes desde “anywhere” (via
[default]) no se debe permitir a esos usuarios alcanzar elementos autenticados.
2) Estblecer el valor de la entrada “alwaysauthreject=yes” en el archivo
sip.conf. Esta opción está disponible desde la versión 1.2 de Asterisk, pero su por
defecto su valor es "no", lo que puede ser potencialmente inseguro. Estableciendo
este valor en "yes" se rechazarán los pedidos de autenticación fallidos utilizando
nombres de extensiones válidas con la misma información de un rechazo de usuario
inexistente. De esta forma no facilitamos la tarea al atacante para detectar
nombres de extensiones existentes utilizando técnicas de "fuerza bruta".
3) Utilizar claves SEGURAS para las entidades SIP. Este es probablemente la
más importante medida de seguridad. Si alguna vez viste programas que generan y
prueban claves por fuerza bruta sabrás que se necesita algo más que palabras y
números para una clave segura. Usar símbolos, números, una mezcla de letras
minúsculas y mayúsculas y al menos 12 caracteres de largo.
4) Bloquear los puertos del Asterisk Manager Interface. Usar “permit=” y
“deny=” en manager.conf para limitar las conexiones entrantes sólo a hosts
conocidos. Una vez más utilizar claves seguras aquí también, 12 caracteres al
menos en una combinación de números, letras y símbolos.
5) Permitir sólo una o dos llamadas por vez por entidades SIP cuando sea
posible. Limitar el uso no autorizado de las líneas voip es una sabia decisión, esto
también es util para el caso que usuarios legítimos hagan pública su clave y pierdan
control de su uso.
6) Los nombres de usuarios SIP deben ser diferentes que sus extensiones.
A pesar de ser conveniente tener una extensión “1234Z que mapee a una entrada
SIP “1234Z la cual es también el usuario SIP “1234Z, esto también facilita a los
atacantes para descubrir nombres de autenticación SIP. En su ligar usar las
direciones MAC del dispositivo, o alguna combinación de frases comunes +
extensión MD5 hash (por ejemplo: desde el shell prompt, hacer “md5 -s
ThePassword5000Z)
7) Asegurarse que el contexto [default] sea seguro. No permitir que
llamadores no autenticados alcancen contextos que les permitan llamar. Permitir
sólo una cantidad limitada de llamadas activas pasen por el contexto default
(utilizar la función “GROUP” como contador). Prohibir totalmente las llamadas no
autenticadas (si es que así lo queremos) estableciendo “allowguest=no” en la parte
[general] de sip.conf.
Suscribirse a:
Entradas (Atom)