Limitación del Ancho de Banda en Honeypots
Borrador Incompleto, 05/13/2002
Edward Balas
Advanced Network Management Lab
Indiana University
Sumario
Este documento expone unos métodos para proveer una tasa límite por honeypot.
Específicamente, trataremos cómo hacerlo en una Dummynet de FreeBSD, Enrutado
Avanzado con Linux y Control de Tráfico, Tasas de Acceso Comprometidas (CAR)
de Cisco y Políticas de Tráfico de Juniper. Para todos los casos tratados, se
supone que tendremos 1 honeynet la cual está detrás de un dispositivo de
enrutado o de conmutación que proporciona la tasa limitada. Estas configuraciones
funcionarán con honeynets GEN I o GEN II, pero requerirán hardware adicional.
Advertir que hasta la fecha, los ejemplos de Linux, Cisco y Juniper aún no
han sido probados, y este documento permanecerá incompleto hasta que lo hayan
sido.
Motivación
Hay numerosos riesgos implícitos al implementar una honeynet. Desafortunadamente,
los intentos para reducir estos riesgos a menudo hacen de la honeynet un modelo
menos realista de una red "normal". En el caso de Ataques por Denegación de
Servicios hay una técnica que satisface la reducción de riesgos sin afectar al
realismo, la limitación del Ancho de Banda. De hecho incluso puede aumentar el
realismo, como en las honeynets diseñadas como modelo de una red de bajo ancho
de banda, como un sistema RTB (Red Telefónica Básica). Una de las soluciones
también permite un incremento en la latencia, lo que puede usarse para ocultar
la "localización" de la red en relación a otros componentes.
Sus Opciones
Hay diversas formas de proveer tasas limitadas a una honeynet. La más básica
implica la restricción del uso de características específicas de la red, p.e.
estableciendo los enlaces a 10M en half-dúplex para cada honeypot. Otros pueden
hacerse mediante software y permitir un gran control en la restricción. Cuando
sea posible es mejor utilizar los dos para asegurarse de que si la solución por
software falla el hardware nos ofrecerá una segunda línea de defensa. Más abajo
listamos 4 solicones software: 2 basadas en unix (FreeBSD y Linux) y 2 basadas
en routers (Cisco y Juniper).
Dummynet FreeBSD
Dummynet es una
utilidad del sistema FreeBSD desarrollada por Luigi Rizzo para poner a prueba
los protocolos de red. Conceptualmente trabaja permitiendo al administrador
crear tuberías virtuales en la red. Estas tuberías tienen diversos atributos
como el ancho de banda, profundidad de la cola, y retrasos. El usuario usa
una configuración del cortafuegos para definir qué paquetes entrarán en la
tubería. Cuando se usa una Dummynet puede hacer que la máquina FreeBSD actúe
como un conmutador o un router. Teniendo el dispositivo operativo como
conmutador significa que no será visible en la ruta por un hacker.
Configuración
En este ejemplo vamos a suponer que la máquina FreeBSD trabajará como un puente
cortafuegos y que la interfaz fxp0 es la interfaz pública y que fxp1
es la privada o la interfaz de la honeynet. La configuración de Dummynet al igual
que otras características de cortafuegos se establece a través del comando
ipfw.
ipfw add pipe 1 ip from any to any in via fxp1
ipfw add pipe 2 ip from any to any in via fxp0
ipfw pipe 1 config mask src-ip 0xffffffff bw 128kbits/s
ipfw pipe 2 config mask dst-ip 0xffffffff bw 128kbits/s
Esta configuración nos permite limitar a cada máquina detrás de fxp1 a
128Kbits/s en full-dúplex. Las 2 primeras líneas le dicen a FreeBSD qué tráfico
necesita pasar a través de la tubería. La tercera y cuarta líneas le dicen a
Dummynet cómo configurar las tuberías virtuales.
La tubería 1 está configurada para restringir tráfico a 128Kbits/s basándose
en la dirección IP de origen. El argumento máscara especifica que deberemos
crear una única tubería por cada IP de origen observada. Si usáramos una
máscara de 0xffffff00 entonces se crearía una única tubería por
cada /24. La tubería 2 es similar a la 1, pero en esta examinamos la IP de
destino en vez de la de origen. Las dos tuberías son necesarias porque
estamos modelando un enlace full-dúplex. Así el tráfico en una dirección
entra en la primera tubería y el tráfico en la otra dirección entra en
la segunda tubería.
Esta configuración funciona correctamente con la conmutación ya que no necesita
configurar las direcciones IP que son usadas por los honeypots. Dummynet ya
tiene bastante tiempo y por mi experiencia, es bastante estable,
Control de Tráfico en Linux
El Control de Tráfico en Linux puede
usarse para proporcionar conformación de tráfico de forma genérica. Con este
enfoque necesitará establecer una "clase" separada para cada máquina. Las
ventajas del enfoque Linux son básicamente las mismas que con FreeBSD con
las siguientes excepciones: requiere la especificación de cada máquina en la
configuración, y no es fácil ajustar la latencias para estas máquinas. Esta
herramienta requiere parchear el núcleo. Para las honeynets GENII que
utilizan VMWare, no se ha podido determinar si el TC puede usarse en la
misma máquina que VMWare. Si resulta que funciona, entonces debería funcionar
con soluciones que no trabajen con puentes, p.e. hogwash. Desafortunadamente
debido a la forma en que VMWare GSX hace el puente desde el ethernet virtual
al físico no es posible utilizar Control de Tráfico si está utilizando
red en modo puenteado para las máquinas virtuales. (Esto necesita
verificación).
Configuración
En este ejemplo, suponemos la misma topología que en la configuración FreeBSD
pero eth0 como interfaz público y eth1 para la honeynet.
!----- NOT TESTED YET
#-- step 1 -----
tc qdisc add dev eth0 root handle 0: htb default 0:3
#-- step 2 -----
tc class add dev eth0 parent 0: classid 0:1 htb rate 128kbit ceil 128kbit
tc class add dev eth0 parent 0: classid 0:2 htb rate 128kbit ceil 128kbit
tc class add dev eth0 parent 0: classid 0:3 htb rate 10Mbit ceil 10Mbit
#-- step 3 -----
tc filter add dev eth0 protocol ip parent 0:0 prio 1 u32 \
match ip dst 10.0.0.1 flowid 0:1
tc filter add dev eth0 protocol ip parent 0:0 prio 1 u32 \
match ip dst 10.0.0.2 flowid 0:2
#-- repeat for other direction -----
tc qdisc add dev eth1 root handle 1: htb default 1:3
tc class add dev eth1 parent 1: classid 1:1 htb rate 128kbit ceil 128kbit
tc class add dev eth1 parent 1: classid 1:2 htb rate 128kbit ceil 128kbit
tc class add dev eth1 parent 1: classid 1:3 htb rate 10Mbit ceil 10Mbit
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 \
match ip src 10.0.0.1 flowid 1:1
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 \
match ip src 10.0.0.2 flowid 1:2
En este ejemplo estamos ajustando cada dirección del tráfico de forma independiente,
para cada dirección hacemos lo siguiente:
- Crear una disciplina raíz de entrada en cola para la interfaz en cuestión.
- Definir clases para ser usadas por la raíz, cada clase define lo
equivalente a un tubería en FreeBSD.
- Definir filtros que clasifiquen qué tráfico debe ir a cada clase.
CAR Cisco
La
Tasa de Acceso Comprometida es una característica proporcionada en las
versiones modernas del IOS de Cisco. Esta característica es bastante usada por
los ISP para proveer servicios de sub-tasas a los clientes. Un ejemplo de un
servicio de sub-tasa es un cliente que se conecta a un ISP a través de una
interfaz Gig-E pero sólo compra un ancho de banda de 500MBytes inicialmente. CAR
puede usarse para limitar las tasas por host pero, como en la solución Linux, cada
máquina debe ser definida en la configuración.
!----- NOT TESTED YET
interface eth0/0
rate-limit input access-group 1 128000 0 0
conform-action transmit exceed-action drop
rate-limit output access-group 2 128000 0 0
conform-action transmit exceed-action drop
rate-limit input access-group 3 128000 0 0
conform-action transmit exceed-action drop
rate-limit output access-group 4 128000 0 0
conform-action transmit exceed-action drop
!
access-list 1 permit ip from 10.0.0.1 to any
access-list 2 permit ip from any to 10.0.0.1
access-list 3 permit ip from 10.0.0.2 to any
access-list 4 permit ip from any to 10.0.0.2
En el ejemplo anterior, editamos los bloques de interfaz de eth0/0 y
añadimos los comandos para la tasa límite que especifican lo siguiente:
- Dirección a la que aplicat la limitación de tasa.
- Grupo de acceso (la access-list) a usar para cada patrón.
- BPS de media.
- BPS a ráfagas.
- BPS Máximo.
Después, vemos las listas de acceso definidas que son necesarias por los límites
de tasa. Para cada máquina que quiera limitar, se necesitan 4 sentencias de
configuración adicionales.
Políticas de Tráfico en Juniper
Las Políticas
de Juniper, como las soluciones Linux y Cisco, utilizan un algoritmo Token-bucket para
hacer cumplir los límites de tasa. La configuración de Juniper además requiere la
definición explícita de las máquinas a limitar. Una ventaja distinta del Juniper
respecto del Cisco es la habilidad de usar Políticas en combinación con
Malla de Circuitos para proporcionar limitación de tasas sin modificar el TTL. La
no decrementación del TTL por los componentes del Control de Datos en una
honeynet singifica que no serán visibles al hacker a través de 'traceroute',
lo que aumenta el realismo de la red.
!------ NOT TESTED YET ------
[edit]
firewall{
family inet {
!-- step 1 -----
policer 128k-pipe {
if-exceeding{
bandwidth-limit 128k;
burst-size-limit 0k;
} then {
discard;
};
!-- step 2 -----
filter number1 {
!-- step 3 -----
term 1 {
destination-address 10.0.0.1/32
} then {
policer 128k-pipe;
accept;
}
term 2{
destination-address 10.0.0.2/32
} then {
policer 128k-pipe;
accept;
}
}
filter number2 {
term 1 {
source-address 10.0.0.1/32
} then {
policer 128k-pipe;
accept;
}
term 2{
source-address 10.0.0.2/32
} then {
policer 128k-pipe;
accept;
}
}
[edit interfaces]
eth-0/0/0 {
unit 0{
family inet{
!-- step 4 -----
filter {
input number1;
output number2;
}
}
}
Dentro de la configuración de Juniper, haga lo siguiente:
- Entre a la configuración del cortafuesgos y añada un bloque
de políticas que definan los límites en las tasas.
- Añada 2 filtros uno por cada dirección del tráfico.
- Por cada filtro añada 1 término para cada máquina a ser limitada.
- Entre al bloque de interfaz y añada los 2 filtros.
Sumario
Más abajo hay un sumario sobre algunas de las características que diferencian
a las distintas soluciones. Hay 3 categorias en la que nos hemos fijado:
Facilidad de Configuración, Decremento del TTL, y Latencia Configurable. La
primera categoría mide si realmente el sistema requiere que el administrador
defina cada máquina que debe ser limitada, si lo hace entonces no se considera
fácil de usar. La segunda categoria es un indicador de si realmente la
solución se puede usar conjuntamente con conmutadores (en el caso que Cisco
pueda hacer CAR en un conmutador, necesitará verificarse). La última categoria
indica si la solución permite establecer una cantidad específica de latencia
en la ruta.
| Solución |
FreeBSD |
Linux |
Juniper |
Cisco |
| Fácil Configuración |
SI |
NO |
NO, pero sintaxis agradable |
NO |
| No hay Decremento TTL |
SI |
SI |
SI |
NO |
| Latencia Configurable |
SI |
NO |
NO |
NO |