Manual DFL-800 Espanol

CONTENIDOS
I Prefacio xvi
Versión del Documento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Extensión de responsabilidad . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Acerca de este Documento. . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Convenciones Tipográficas . . . . . . . . . . . . . . . . . . . . . . . . xviii
II Vista General del Producto 2
1 Capacidades 3
1.1 Características del Producto . . . . . . . . . . . . . . . . . . . . . . . . . . 3
III Introducción de Redes 6
2 El modelo OSI 7
3 Principios del Firewall 9

3.1 El Rol del Firewall . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 ¿Qué es un Firewall? . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 ¿Cómo trabaja un Firewall? . . . . . . . . . . . . . . . . . 9
3.2 ¿Contra qué NO protégé el Firewall? . . . . . . . . . . . 10
3.2.1 Ataques en Componentes Inseguros pre-instalados . . . . . 11
3.2.2 Usuarios Inexpertos en Redes protegidas . . . . . . . 11
3.2.3 Data-Driven Network Attacks . . . . . . . . . . . . . . . 11
3.2.4 Ataques Internos . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.5 Modems y Conexión VPN . . . . . . . . . . . . . . 13
3.2.6 Agujeros entre DMZs y Redes Internas . . . . . . 14
i
ii
IV Administración 18
4 Plataforma de Configuración 19
4.1 Configurando Via WebUI . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.1 Vista General . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.2 Interface Layout . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.3 Operaciones de Configuración . . . . . . . . . . . . . . . . . . 22
4.2 Monitoreo Via CLI . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 Registro 25
5.1 Vista General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1.1 Importancia & Capacidad . . . . . . . . . . . . . . . . . . 25
5.1.2 Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2 Receptores de Registro . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.1 Receptor Syslog . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.2 Receptor de Registro de Memoria. . . . . . . . . . . . . . . . . . . 29
5.2.3 Receptor de Evento SMTP . . . . . . . . . . . . . . . . . . . . 29
6 Mantenimiento 31
6.1 Actualización del Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2 Reset a valores de fabrica . . . . . . . . . . . . . . . . . . . . . . 32
6.3 Respaldo de Configuración . . . . . . . . . . . . . . . . . . . . . . . . 34
7 Ajustes Avanzados 35
7.1 Vista General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
V Fundamentos 38
8 Objetivos Lógicos 39
8.1 Libro de Direcciónes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1.1 Dirección IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1.2 Dirección Ethernet . . . . . . . . . . . . . . . . . . . . . . . 41
8.2 Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.2.1 Tipos de Servicio . . . . . . . . . . . . . . . . . . . . . . . . 42
8.2.2 Reporte de Error & Protección de Conexión . . . . . . . . . 46
8.3 Programas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.4 Certificados X.509 . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.4.1 Introducción a Certificados . . . . . . . . . . . . . . . . . 49
8.4.2 Certificados X.509 en los Firewalls D-Link . . . . . . . . . . 51
Guía de Usuario de los Firewalls D-Link

iii
9 Interfaces 53
9.1 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.1.1 Interfaces Ethernet . . . . . . . . . . . . . . . . . . . . . . 53
9.1.2 Interfaces Ethernet en los Firewalls D-Link . . . . . . . . . 54
9.2 Virtual LAN (VLAN) . . . . . . . . . . . . . . . . . . . . . . . . 56
9.2.1 Infraestructura VLAN . . . . . . . . . . . . . . . . . . . . 56
9.2.2 802.1Q VLAN Estandard . . . . . . . . . . . . . . . . . . 57
9.2.3 Implementación VLAN . . . . . . . . . . . . . . . . . . . 58
9.2.4 Utilizando LANs Virtuales para Expandir Interfaces Firewall . . 59
9.3 DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.3.1 Cliente DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.4 PPPoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
9.4.1 PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
9.4.2 Configuración de Cliente PPPoE . . . . . . . . . . 62
9.5 Grupos de Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
9.6 ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
9.6.1 Tabla ARP. . . . . . . . . . . . . . . . . . . . . . . . . . . 66
10 Routing 69
10.1 Vista General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
10.2 Jerarquía de Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
10.3 Algoritmos Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 71
10.3.1 Routing Estático . . . . . . . . . . . . . . . . . . . . . . . . 71
10.3.2 Routing Dinámico . . . . . . . . . . . . . . . . . . . . . . . 72
10.3.3 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
10.4 Ruta de Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
10.4.1 Escenario: Configuración de Ruta de Failover. . . . . . . . . 78
10.5 Implementación de Routing Dinámico . . . . . . . . . . . . . . . . 81
10.5.1 Proceso OSPF. . . . . . . . . . . . . . . . . . . . . . . . . 81
10.5.2 Política de Routing Dinámico . . . . . . . . . . . . . . . . . 81
10.5.3 Escenarios: Configuración de Routing Dinámico . . . . . . 82
10.6 Escenario: Configuración de Routing Estático. . . . . . . . . . . . 87
10.7 Politica basada en Routing(PBR) . . . . . . . . . . . . . . . . . . . . . 88
10.7.1 Vista General. . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10.7.2 Politica basada en Routing Tables . . . . . . . . . . . . . . . . 89
10.7.3 Politica basada en Routing Policy . . . . . . . . . . . . . . . . 89
10.7.4 Ejecución PBR . . . . . . . . . . . . . . . . . . . . . . . . 89
10.7.5 Escenario: Configuración PBR . . . . . . . . . . . . . . . 91
10.8 ARP Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

iv
11 Fecha & Tiempo 95

11.1 Ajustando la Fecha y Tiempo . . . . . . . . . . . . . . . . . . . . . 96
11.1.1 Fecha y Tiempo actual. . . . . . . . . . . . . . . . . . . 96
11.1.2 Zona Horaria . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
11.1.3 Horario de Verano(DST) . . . . . . . . . . . . . . . . 97
11.2 Sincronización de Tiempo . . . . . . . . . . . . . . . . . . . . . . . . 98
11.2.1 Protocolos de Sincronización de Tiempo. . . . . . . . . . . . . . 98
11.2.2 Servidores de Tiempo. . . . . . . . . . . . . . . . . . . . . . . . . 98
11.2.3 Ajuste Máximo. . . . . . . . . . . . . . . . . . . 99
11.2.4 Intervalo de Sincronización . . . . . . . . . . . . . . . . . . 99
12 DNS 101
13 Ajustes de Registro 103

13.1 Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
13.1.1 Definiendo Receptor Syslog . . . . . . . . . . . . . . . . . . 103
13.1.2 Habilitando registros . . . . . . . . . . . . . . . . . . . . . . . 104
VI Políticas de Seguridad 108
14 Reglas IP 109
14.1 Vista General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
14.1.1 Campos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
14.1.2 Tipos de Acción . . . . . . . . . . . . . . . . . . . . . . . . . . 111
14.2 Traducción de Dirección. . . . . . . . . . . . . . . . . . . . . . . . . . 112
14.2.1 Vista General. . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
14.2.2 NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
14.2.3 Traducción de dirección en los Firewalls D-Link . . . . . . . . . 114
14.3 Escenarios: Configuración de Reglas IP. . . . . . . . . . . . . . . . . 116
15 Acceso (Anti-spoofing) 123

15.1 Vista General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
15.1.1 IP Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . 123
15.1.2 Anti-spoofing . . . . . . . . . . . . . . . . . . . . . . . . . 124
15.2 Regla de Acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
15.2.1 Función. . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
15.2.2 Ajustes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
15.3 Escenario: Ajustando Regla de Acceso . . . . . . . . . . . . . . . . . 126

v
16 DMZ & Port Forwarding 127

16.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
16.1.1 Conceptos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
16.1.2 Planificación DMZ. . . . . . . . . . . . . . . . . . . . . . . . 129
16.1.3 Beneficios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
17 Autentificación del Usuario 131

17.1 Vista General de Autentificación. . . . . . . . . . . . . . . . . . . 131
17.1.1 Métodos de Autentificación. . . . . . . . . . . . . . . . . . 131
17.1.2 Criterio de Contraseña. . . . . . . . . . . . . . . . . . . . . . 132
17.1.3 Tipos de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
17.2 Componentes de Autenticación . . . . . . . . . . . . . . . . . . . . . 134
17.2.1 Base de Datos de Usuarios Locales(UserDB) . ... . .. . . . . . 134
.17.2.2 Servidor de Autenticación Externo . . . . . . . . . . . . . . 134
17.2.3 Agentes de Autenticación . . . . . . . . . . . . . . . . . . . 135
17.2.4 Reglas de Autenticación . . . . . . . . . . . . . . . . . . . . 136
17.3 Proceso de Autenticación . . . . . . . . . . . . . . . . . . . . . . . . 137
17.4 Escenarios: Configuración de Autenticación de Usuario . . . . . . . . . 137
VII Inspeccion de Contenido 146
18 Application Layer Gateway (ALG) 147

18.1 Vista General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
18.2 FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
18.2.1 Conexiones FTP. . . . . . . . . . . . . . . . . . . . . . . 148
18.2.2 Escenarios: Configuracion FTP ALG . . . . . . . . . . . 150
18.3 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
18.3.1 Componentes & Asuntos de Seguridad . . . . .. . . . . . . . . . 155
18.3.2 Solucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
18.4 H.323 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
18.4.1 Vista General Standard H.323. . . . . . . . . . . . . . . . . . 158
18.4.2 H.323 Componentes . . . . . . . . . . . . . . . . . . . . . . 158
18.4.3 H.323 Protocolos . . . . . . . . . . . . . . . . . . . . . . . . 159
18.4.4 H.323 ALG Vista General . . . . . . . . . . . . . . . . . . . . 160
18.4.5 Escenarios: Configuración H.323 ALG . . . . . . . . . . 161
19 Sistema de Deteccion de Intrusos (IDS) 181

19.1 Vista General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
19.1.1 Reglas de Deteccion de Intrusos . . . . . . . . . . . . . . . . . . 182
19.1.2 Patron de coincidencia . . . . . . . . . . . . . . . . . . . . . . . 182

vi
19.1.3 Accion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

19.2 Cadena de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
19.2.1 Escenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
19.2.2 Escenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
19.3 Grupos de Firmas . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
19.4 Actualización automática de Base de datos de Firmas
. . . . . . . . . . . . 186
19.5 Repecion de registros SMTP para eventos IDS . ... . . . . . . . . . . 187
19.6 Escenario: Configurando IDS . . . . . . . . . . . . . . . . . . . . . . 189
VIII Red privada virtual (VPN) 192
20 VPN Básico 193

20.1 Introducción a VPN . . . . . . . . . . . . . . . . . . . . . . . . . 193
20.1.1 VPNs vs Conexiones fijas . . . . . . . . . . . . . . . . 193
20.2 Introduccion a la Criptografia . . . . . . . . . . . . . . . . . . . 195
20.2.1 Encriptacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
20.2.2 Autenticacion e Integridad . . . . . . . . . . . . . . . . . 198
20.3 ¿Por VPN en los Firewalls? . . . . . . . . . . . . . . . . . . . . . . . . 200
20.3.1 Despliegue VPN. . . . . . . . . . . . . . . . . . . . . . . 201
21 VPN Planificacion 207

21.1 Consideracion en Diseño de VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
21.1.1 Seguridad en Punto de Termino . . . . . . . . . . . . . . . . . . . . . . 208
21.1.2 Distribucion de Claves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
22 VPN Protocolos y Tuneles 213

22.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
22.1.1 IPsec protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
22.1.2 IPsec Modos de Encapsulacion. . . . .. . . . . . . . . . . . . . 214
22.1.3 IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
22.1.4 IKE integridad y autenticacion. . . . . . . . . . . . . . . . . . . . 219
22.1.5 Escenarios: Configuracion IPsec . . . . . . . . . . . . . . . . . 223
22.2 PPTP/ L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
22.2.1 PPTP . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 228
22.2.2 L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
22.3 SSL/TLS (HTTPS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
D-Link Firewalls User’s Guide

vii
IX Administración de Tráfico 246
23 Traffic Shaping 247

23.1 Vista General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
23.1.1 Funciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
23.1.2 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
23.2 Pipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
23.2.1 Procedencias y Garantías . . . . . . . . .. . . . . . . . . . . . . . 250
23.2.2 Agrupando usuarios en un conducto .. . .. . . . . . . . . . . . . 252
23.2.3 Balanceo de Carga Dinámico . . . . . . . . . . . . . . . . . . . . 253
23.3 Pipe Reglas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
23.4 Escenarios: configurando Traffic Shaping . . . . . . . . . . . . . . . 253
24 Servidor de Balanceo de Carga (SLB) 261

24.1 Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
24.1.1 EL Modulo SLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
24.1.2 características SLB. . . . . . . . . . . . . . . . . . . . . . . . . . 262
24.1.3 Beneficios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
24.2 SLB Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
24.2.1 Modos de. Distribución . . . . . . . . . . . . . . . . . . . . 264
24.2.2 Algoritmos de Distribucion . . . . . . . . . . . . . . . . . . . 264
24.2.3 Verificación del estado del Servidor
. . . .. . . . . . . . . . . . . . . 265
.24.2.4 Paquetes que fluyen en SAT ... . . . . . . . . . . . . . . . . . 266
24.3 Escenario: Habilitando SLB . . . . . . . . . . . . . . . . . . . . . . . . . 266
X Características Misceláneas 270
25 Clientes Misceláneo 271

25.1 Vista General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
25.2 DNS Dinamico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
25.3 Registro automatico de cliente
. . . . . . . . . . . . . . . . . . . . . . . 272
25.4 HTTP Poster . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
25.4.1 URL Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
26 Servidor y relay DHCP 275

26.1 DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
26.2 DHCP Relayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

viii
XI Modo Transparente 280
27 Modo Transparente 281

27.1 Vista General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
27.2 Implementacion de modo transparente en los Firewall Dlink . . . . 282
27.3 Escenarios: Habilitando Modo Transparente . . . . . . . . . . . . . . . . . . . . . 284
XII Zona de Defensa 290
28 Zona de defensa 291

28.1 Vista General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
28.2 Switch de zona de defensa . . . . . . . . . . . . . . . . . . . . . . . . 291
28.2.1 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
28.3 Reglas Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
28.4 Bloqueo Manual y Listas Excluyentes . . . . . . . . . . . . . . . . . 293
28.5 Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
28.6 Escenario: Configurando la zona de defensa . . . . . . . . . . . . . . . . 294
XIII Alta Disponibilidad 298
29 Alta Disponibilidad 299

29.1 Alta Disponiblidad Basica . . . . . . . . . . . . . . . . . . . . . . . 299
29.1.1 ¿Qué hará la Alta Disponibilidad para Ud? . . . . . . . . . 299
29.1.2 ¿ Qué no hará la Alta Disponibilidad para Ud? . . . . . . 300
29.1.3 Ejemplo de configuración de Alta disponibilidad . . . . . . . . .. . .. 301
29.2 Como se logra realizar un Failover . . . . . . . . . . . . . . . 301
29.2.1 La dirección IP compartida y mecanismo de Failover . . 302
29.2.2 Palpitaciones Cluster . . . . . . . . . . . . . . . . . . . . . . 303
29.2.3 La interfaz de sincronizacion . . . . . . . . . . . . . . . 304
29.3 Configurando un Cluster de Alta Disponibilidad . . . . . . . . . . . . . . 304
29.3.1 Planificando el Cluster de Alta Disponibilidad . . . . . . . . . . 305
29.3.2 Creando un Cluster de Alta Disponibilidad . . . . . . . . . . . 305
29.4 Cosas que debe mantener presentes . . . . . . . . . . . . . . . . . . . . . . . 307
29.4.1 Asuntos de estadística y registros . . . . . . . . . . . . . . . . 307
29.4.2 Asuntos de Configuracion . . . . . . . . . . . . . . . . . . . . . 308
XIV Apéndice 310
Referencia a Comandos de Consola 313

ix
Lista de Comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

About . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
ARPSnoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Certcache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
CfgLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Cpuid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
DHCPRelay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
DHCPServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
DynRoute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Frags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
HTTPPoster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Ifacegroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
IfStat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Ikesnoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Ipseckeepalive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
IPSectunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
IPSecstats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Killsa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Lockdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Loghosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Netcon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Netobjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Pipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Proplists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
ReConfigure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Remotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Scrsave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

x
Sysmsgs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Stats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Uarules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Userauth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Userdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Vlan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
B Soporte a clientes 339

FIGURES & TABLES
2.1 The OSI 7-Layer Model. . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 WebUI Authentication Window. . . . . . . . . . . . . . . . . . . 20

4.2 WebUI Main Display. . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1 A VLAN Infrastructure. . . . . . . . . . . . . . . . . . . . . . . . 57

9.1 802.1Q Standard Ethernet Frame. . . . . . . . . . . . . . . . . . 58
10.1 Route Failover Scenario . . . . . . . . . . . . . . . . . . . . . . . 78

10.2 OSPF Process Scenario . . . . . . . . . . . . . . . . . . . . . . . 82
10.3 Static Routing Scenario . . . . . . . . . . . . . . . . . . . . . . . 87
14.1 Dynamic NAT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

14.1 SAT Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
16.1 A Web Server in DMZ . . . . . . . . . . . . . . . . . . . . . . . . 128
18.1 FTP ALG Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . 150

18.2 FTP ALG Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . 153
18.3 H.323 Scenario 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
18.4 H.323 Scenario 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
18.5 H.323 Scenario 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
18.6 H.323 Scenario 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
18.7 H.323 Scenario 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
19.1 IDS Chain of Events Scenario 1 . . . . . . . . . . . . . . . . . . 183

19.2 IDS Chain of Events Scenario 2 . . . . . . . . . . . . . . . . . . 185
19.3 Signature Database Update . . . . . . . . . . . . . . . . . . . . . 187
xi
xii
19.4 An IDS Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
20.1 VPN Deployment Scenario 1 . . . . . . . . . . . . . . . . . . . . 201

22.1 LAN-to-LAN Example Scenario. . . . . . . . . . . . . . . . . . . 223

22.2 IPsec Roaming Client Example Scenario. . . . . . . . . . . . . . 225
22.1 PPTP Encapsulation. . . . . . . . . . . . . . . . . . . . . . . . . . 228
22.2 L2TP Encapsulation. . . . . . . . . . . . . . . . . . . . . . . . . . 235
23.1 IPv4 Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . 251
24.1 A SLB Logical View. . . . . . . . . . . . . . . . . . . . . . . . . . 262

24.2 A SLB Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
27.1 Transparent Mode Scenario 1. . . . . . . . . . . . . . . . . . . . 284

27.2 Transparent Mode Scenario 2. . . . . . . . . . . . . . . . . . . . 286
28.1 A Zone Defense Scenario. . . . . . . . . . . . . . . . . . . . . . . 295
29.1 Example HA Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . 301

LISTA DE ESCENARIOS
Sección 10.4: Configuración Route Failover. . . . . . . . . . . . 78
Sección 10.5: Configuración Dynamic Routing. . . . . . . . . . . . 82
Sección 10.6: Configuración Static Routing. . . . . . . . . . . . . . 87
Sección 10.7: Configuración PBR . . . . . . . . . . . . . . . . . . . . 91
Sección 14.3: Configuración IP Rules . . . . . . . . . . . . . . . . . . 116
Sección 15.3: Configuración Access Rule . . . . . . . . . . . . . . . . . . 126
Sección 17.4: Configuración User Authentication . . . . . . . . . . 137
Sección 18.2: Configuración FTP ALG . . . . . ……… . . . . . . . . . . . 150
Sección 18.4: Configuración H.323 ALG . . . . . . . . . . . . . . . 161
Sección 19.6: Configuración de IDS . . . . . . . . . . . . . . . . . . . . . . . 189
Sección 22.1: Configuración IPsec. . . . . . . . . . . . . . . . . . . 223
Sección 23.4: Configuración de Traffic Shaping . . . . . . . . . . . . . . . . 253
Sección 24.3: Habilitando SLB . . . . . . . . . . . . . . . . . . . . . . . 266
Sección 27.3: Habilitando Transparent Mode . . . . . . . . . . . . . . 284
Sección 28.6: Configuración de Zone Defense . . . . . . . . . . . . . . . . . 294
xiii
Parte I
Prefacio
xiv
Versión de Documento
Version No.: 1.0
Advertencia
La información en esta guía de usuario está sujeta a cambios sin previo aviso.
Acerca de este Documento

Esta Guía de Usuario esta diseñada para ser un manual de configuración útil así como
una herramienta de aprendizaje de trabajo Internet y conocimientos de seguridad
para los administradores de red.
El documento intenta no sólo presentar medios para llevar a cabo

ciertas operaciones del producto, sino entregar fundamentos sobre en qué
conceptos están basadas las funciones, cómo varias secciones del producto
trabajan efectivamente, y por qué ciertos grupos de configuraciones son ejecutadas
con el fin de aumentar la comprensión del lector.
El contenido de esta guía está lógicamente organizado en Partes, Capítulos, y

Secciones, con análisis de Escenarios para cada característica principal, para permitir
mejor al lector aprender varias funciones. En forma consecutiva a las partes y capítulos
detallados, será presentada información suplementaria y un índice de términos
relevantes en esta guía.
Convenciones Tipográficas
Ejemplo:
Pasos de configuración para realizar ciertas funciones.
WebUI
:
Pasos ejemplo para WebUI.
Nota
Información adicional que el usuario debe tener en conocimiento.
Tip
Sugerencias en la configuración que deben ser tomadas en consideración.
Aviso
Información crítica que el usuario debe seguir al llevar a cabo cierta acción.
Advertencia
Información critica que el usuario DEBE seguir para evitar un daño potencial
xvii
Parte II
Vista General del Producto
CAPITULO 1
Capacidades
1.1 Caracteristicas del Producto

Las características claves de los firewalls D-Link pueden ser resumidas como:
• Asistente de arranque de fácil ejecución
• Interfaz gráfica de usuario basado en web (WebUI)
• Efectivo y de fácil mantención
• Políticas de control completo de seguridad
• Capas de puerta de enlace de aplicación avanzada (FTP, HTTP, H.323)
• Métodos avanzados de monitoreo y registro
• Cumplimiento VLAN total
• Soporte para la construcción VPN (IPSec, PPTP, L2TP)
• Detección de errores de Ruta
• Ruteo avanzado (OSPF)
• Soporte de Modo Transparente
• Balance de Registro de Servidor
• Sistema de Detección de Intrusos
3
4 Capitulo 1. Capacidades
• Zona de Defensa
• Alta Disponibilidad (Algunos modelos)
Detalles sobre cómo hacer funcionar estas características son encontradas en

capítulos específicos en esta guía de usuario.
Parte III
Introducción a Redes
CAPITULO 2
El modelo OSI
El modelo Open System Interconnection (OSI) define un marco primario para

comunicaciones inter-computacionales, a través de la categorización de diferentes
protocolos para una gran variedad de aplicaciones de red, en siete pequeñas capas
más manejables. El modelo describe cómo los datos de una aplicación en un computador
pueden ser transferidas a través de un medio de red, a una aplicación en otro computador.
El control de tráfico de datos es pasado de una capa a la siguiente
partiendo de la capa de aplicación de un computador, avanzando a la capa
de abajo, atravesando por el medio a otro computador y luego
transfiriéndolo a la parte superior de la jerarquía. Cada capa maneja un cierto grupo de
protocolos, de manera que las tareas para realizar una aplicación puedan ser distribuidas
a diferentes capas para ser implementadas independientemente.
Tabla 2.1 muestra la definición de 7 capas. Funciones básicas y los

protocolos comunes envueltos en cada capa son explicados a
continuación.
Capa de aplicación
– define la interfaz de usuario que soporta las aplicaciones directamente.
Protocolos: HTTP, FTP, DNS, SMTP, Telnet, SNMP, etc.
Capa de presentación
– traduce las diversas aplicaciones a un formato uniforme de red que
Pueda ser comprendido por el resto de las capas.
Capa de Sesión
– establece, mantiene y termina las sesiones a través de la red.
Protocolos: NetBIOS, RPC, etc.
7
8 Capítulo 2. El modelo OSI
7 Capa de Aplicación
6 Capa de Presentación
5 Capa de Sesión
4 Capa de Transporte
3 Capa de Red
2 Capa de Datos-Link
1 Capa Física
Tabla 2.1: Modelo OSI de 7-Capas.
Capa de Transporte
– controla el flujo de datos y entrega un manejo de errores. Protocolos: TCP,
UDP, etc.
Capa de Red
– despliega el direccionamiento y ruteo. Protocolos: IP, OSPF, ICMP,
IGMP, etc.
Capa de Datos-Link
– estructura los datos. Protocolos: Ethernet, PPP, etc.
Capa Física
– define los soportes de hardware.
Los firewalls D-Link manejan el tráfico de red y despliegan diversas funciones

para garantías de seguridad y soporte de aplicación a través de las 7 capas del
modelo OSI.

CAPITULO 3
Principios Firewall
3.1 El Rol del Firewall

3.1.1 ¿Qué es un Firewall?
Cuando usted conecta su computador ó su red de área local a otra red
ej. el internet, se deben tomar ciertas medidas para prevenir que intrusos
tengan acceso a fuentes y materiales que usted considere confidenciales ó
sensibles. Con el fin de conseguir esto, se debe implementar un firewall en la
red. Esta tarea es para asegurar que sólo es permitido el flujo de comunicación
aprobada entre redes y que la comunicación no autorizada es bloqueada
y registrada.
3.1.2 ¿Cómo trabaja un Firewall?

El propósito primario de un firewall es reforzar el estado de políticas de seguridad sobre
quién puede comunicarse con quién y de qué manera.
El firewall consigue ésto examinando el tráfico que pasa a través de éste,

comparando la información con un conjunto de reglas programadas en éste y
tomando una decisión basada en factores tales como la dirección del emisor,
dirección de destino, protocolo y puertos. Esto le permite instalar menos servicios de
seguridad de red en sus redes protegidas y prevenir de que intrusos tengan acceso
a éstos servicios.
La mayoría de los firewalls, incluyendo los firewalls D-Link, aseguran que el tráfico
de red
9
10 Capitulo 3. Principios del Firewall
cumpla con las definiciones actuales de protocolo. Esto puede prevenir que
servicios mal implementados en los servidores protegidos y clientes software sean
expuestos a datos inesperados, causando que éstos se suspendan ó se caigan. En
resumen un firewall es la respuesta de la red a una seguridad
deficiente por parte del anfitrión.
3.2 ¿Contra qué NO protege el Firewall?
La seguridad implica mucho más que sólo firewalls. Sin embargo, en la mayoría de
los casos, instalar un firewall es necesariamente el primer paso para asegurar su red
y computador.
Esta sección no está específicamente dedicada a los firewalls D-Links; sino que
trata de los firewalls en general. Los problemas descritos aquí pueden ocurrir
independiente de cual firewall usted elija instalar.
Una idea errónea común es que toda la comunicación está inmediatamente

asegurada una ves que pasa a través del firewall. Esto sin embargo no es verdad.
Muchos ejecutivos de marketing y vendedores sonríen y reclaman que “nuestro

Firewall le protegerá contra todo”. Se espera que esto sea sólo
pura ignorancia de parte de ellos y no un intento consciente de engañar a
potenciales compradores.
Un firewall puede sólo proteger contra aquello a lo que ha sido diseñado.

Desafortunadamente, es imposible predecir todos los virus que otros software pueden
tener. En adición, hay un gran número de situaciones en donde un firewall
no puede entregar una total protección a toda la comunicación que pasa
a través de éste.
La siguiente es una selección de problemas de seguridad con los que a menudo

un firewall es incapaz de lidiar, y en algunas instancias entregamos soluciones para
combatir éstos.
Tome nota de que ésto sólo raya la superficie en términos del número de
problemas existentes.
Una protección completa sólo puede ser alcanzada a través una comprensión profunda
de todas las debilidades posibles en los protocolos de red y en el software utilizado,
y de la implementación de medidas apropiadas para compensar éstas.

3.2. ¿Contra qué NO protege el Firewall? 11
3.2.1 Ataques en Componentes Inseguros pre-instalados

Un problema muy común es el hecho de que sistemas operativos y aplicaciones
usualmente contienen componentes inseguros pre-instalados. Tales componentes
incluyen servicios indocumentados presentes en computadores conectados a
Internet, permitiendo el ingreso de conexiones de red externas. Un ejemplo de
esta forma de vulnerabilidad son los componentes de ”simplificación” que permiten
el acceso directo ODBC vía HTTP en servidores web.
La característica más común para la mayoría de estos componentes es que no

están previstos para el uso en una red pública, en donde intrusos pueden utilizar la extra
funcionabilidad a mano para interrumpir fácilmente en el sistema. Sin embargo, los
sistemas modernos están frecuentemente previstos con tales componentes pre-instalados
con el fin de hacer el sistema fácil de utilizar.
Una buena precaución a tomar es revisar todos los sistemas conectados a Internet,
clientes y servidores, y remover todas las funcionalidades innecesarias.
3.2.2 Usuarios inexpertos en Redes protegidas

Ningún firewall en el mundo puede proteger contra el daño que usuarios inexpertos
pueden provocar a una red protegida.
Si éstos “asisten” a un intruso de una manera u otra, ej. abriendo un

programa no reconocido enviado vía email tal como ”merryxmas2001.exe”,
se puede lograr más daño que si colocáramos juntos todos los virus de aplicaciones y
sistemas operativos.
Todos los intentos de asegurar las redes de una organización deben ser precedidos
por una profunda investigación sobre que puede o no ser permitido.
El resultado de ésto debe ser una política de seguridad que se aplique a todas las partes
de la organización, desde la administración inferior. Con la intención de que tales políticas
funcionen, todos los usuarios deben estar conscientes de estas políticas y por qué
deben ser reforzadas.
3.2.3 Ataque a los datos de la Red

Normalmente, un firewall puede sólo proteger un sistema contra ataques de datos
en circunstancias excepcionales. Tales ataques incluyen:
• Paginas HTML contenedoras de javascript o Java que atacan la red

”desde el interior” cuando la página es vista en un buscador ó programa
e-mail. La única protección posible contra esta clase de ataque,

aparte de un software de mejor escritura, es deshabilitar tales servicios o

limitando la navegación a computadores menos sensibles.
• Páginas HTML que vinculan en los contenidos de archivos locales cuando éstos
están abiertos sin scripts. Tales páginas pueden, a menudo con la ayuda
de usuarios locales confiados que son engañados en ”Ayudar” a la página
haciendo click en un botón, enviando el archivo vinculado hacia adelante a un
servidor Internet desconocido.
• Los documentos enviados por email que contienen scripts hostiles son
activados una vez que el documento es abierto. Maneras posibles para proteger su
sistema contra estas formas de ataque incluyen el evitar utilizando
un software buscador basado en email o deshabilitando el script e introduciendo
puertas de enlace mail que pueden bloquear scripts y otros códigos ejecutables.
• Buffer overruns, contra los cuales muy raramente proveen protección los firewalls.
Buffer overruns pueden ocurrir en cualquier aplicación, con un resultado net de
intrusos que son capaces de conseguir que los computadores protegidos ejecuten
cualquier comando. Aquí, la única solución es asegurar que sólo las aplicaciones
bien escritas, las cuales son diseñadas específicamente para ser inmunes a
esta forma de ataque son bien instaladas y utilizadas. Desafortunadamente los
software más actuales no están escritos con este problema en mente. Al
momento de escribir, se es de la opinión de que esto plantea la mejor amenaza
técnica para todas las formas de ataque basado en red, cuando casi todo el
software es susceptible a buffer overruns.
• Virus y troyanos. Un firewall puede por supuesto ser conectado a

scanners de virus, puertas de enlace mail y otros dispositivos similares con el fin
de incrementar seguridad, pero debe ser notado que la funcionalidad
fundamental de un firewall no entrega normalmente tal protección.
• Incluso si un firewall es conectado a un scanner de virus, es posible que los virus

atacantes pueden estar tan bien ocultos que el scanner es incapaz de
detectarlos. En adición, un scanner de virus puede sólo detectar los virus que
reconozca. Si alguien diseña un virus específicamente para atacar sus
sistemas o aquellos de un pequeño grupo de personas, o si el troyano o virus
en cuestión no se encuentra en circulación lo suficiente para
que se vuelva bien conocido, el scanner de virus no lo reconocerá.
En el presente, las tareas más comunes para ataques de datos son:
• Servidores públicos tales como servidores mail, servidores DNS y servidores

web. Los servidores Web son claramente representados en esta categoría debido
a su enorme complejidad.

3.2. ¿Contra qué NO protege el firewall? 13
• Scripts hechos a la medida en servidores web. Es ahora muy fácil ampliar la

funcionabilidad de su servidor web escribiendo pequeños, programas a la
medida para manejar una multitud de tareas. Sin embargo, una consciencia
insuficiente de problemas potenciales pueden conducirle, la mayoría de las veces,
a realizar pequeñas modificaciones, dificultando la detección de errores que pueden
habilitar a un intruso para ganar acceso a su sistema.
• Los buscadores de Web. La automatización de procesos y la simplificación de

operaciones para el beneficio de los usuarios crean un incremento en la
complejidad interna y de este modo incrementa el riesgo de vulnerabilidades.
• El software Desktop, ante todo desea en buena medida soportar

lenguajes scripting, por la misma razón que un buscador . Los lenguajes
scripting entregan acceso casi ilimitado a computadores locales y a todas las
fuentes de red conectados. Como resultado, los intrusos pueden causar todo
tipo de problemas si éstos pueden obtener usuarios internos para abrir
documentos contenedores de scripts malévolos.
3.2.4 Ataques internos

Un firewall sólo puede filtrar datos que pasan a través de éste. Por lo tanto, no puede
ofrecer protección alguna contra ataques internos en las redes locales, donde todos
los computadores se comunican directamente entre ellos.
En adición, los firewalls no pueden proveer protección contra los usuarios

locales introduciendo un software prejudicial a la red desde un medio removible, o a
través de la exportación de información sensible del mismo modo.
Esto puede parecer obvio. Sin embargo, la mayoría de la gente subestima el impacto
de tal daño.
Aunque diferentes Fuentes entregan diferentes imágenes, es claro que más de un

50% de todos los problemas de seguridad de datos son el resultado de ataques
internos. Algunas fuentes colocan esta imagen a una altura del 80%.
3.2.5 Módems y Conexión VPN

Un error común es creer que los módems y puertas de enlace VPN son tan seguros
como la red protegida y pueden ser conectados directamente a ésta sin protección.
Guía de Usuario de los firewalls D-Link

Modem pools puede estar sujetas a ataques directos y, en casos extremos,

las líneas telefónicas pueden ser interceptadas. Switches, localizados en
cualquier punto de las redes tele-comunicacionales o en la oficina, pueden ser
reprogramados sin que el intruso necesite estar cerca de éstos.
Cuando éste se vuelve a las conexiones VPN, es importante recordar que

aunque las conexiones mismas pueden ser seguras, el nivel total de seguridad es
sólo tan alto como la seguridad de los puntos de término del túnel.
Se vuelve cada vez más común para los usuarios en el flujo conectarse
directamente a las redes de sus compañías desde sus laptops vía VPN. Sin embargo,
el laptop mismo no es a menudo protegido. En otras palabras, un intruso puede obtener
acceso a las redes protegidas a través de un laptop no protegido con
conexiones VPN ya abiertas.
Una precaución básica a tomar es la protección de su red contra ataques a los modems
y conexiones VPN, asegurando que los computadores móviles jamás se
comuniquen directamente con el Internet. En cambio, deben siempre ser
dirigidos a través de VPN o modem de conexión y la red de la compañía, sin importar
a aquellos a los que se desea comunicar. De esta manera, éstos disfrutan
mas o menos el mismo nivel de protección que el resto de la red. Para conexiones
VPN, un cliente VPN competente que puede bloquear todos los tráficos Internet
entrantes, a un lado de aquellos que pasan a través de las conexiones VPN,
deben ser instalados en cada laptop.
Una conexión VPN o modem pool no debe jamás ser considerado como una parte
directa de una red protegida. Los puntos de término VPN deben en cambio ser localizados
en un DMZ especial o fuera del firewall al que están dedicadas sus tareas. Al hacer esto,
usted puede restringir cuáles servicios pueden ser accedidos vía VPN y
modem y por lo tanto asegurar que ése servicio esté bien protegido contra intrusos.
En casos en donde el firewall pone en relieve una puerta de enlace VPN integrada, es
usualmente posible imponer los tipos de comunicación permitidos. El Firewall
D-Link pone a flote tal facilidad.
3.2.6 Entradas entre DMZ y las Redes Internas

Aunque la llegada de extranets y comercio electrónico ha servido para conducir
envíos desarrollados, y como mas y más compañías comienzan a hacer
datos internos disponibles vía servidores web, los riesgos de seguridad como resultado
son incrementados.
3.2. ¿Contra qué NO protege el firewall? 15
Es ahora una práctica común localizar servidores web en zonas desmilitarizadas,

donde éstos se comunican con fuentes de datos en redes protegidas. En tales casos,
los ataques a los datos plantean una gran amenaza.
El problema con los agujeros entre DMZ y redes internas no es realmente un problema
en sí. Mas bien, es una consecuencia de los problemas discutidos con anterioridad.
Mucha gente abre estos agujeros sin tener cuidado de los problemas que pueden
causar, lo cual es el por qué hemos elegido destacar estos problemas en
una sección separada.
La razón para localizar un servidor web en un DMZ es simple – el servidor no puede

confiar en ser completamente seguro. ¿Qué sucede si alguien gana control sobre
el servidor y hay un agujero abierto a través del cual se puede ganar acceso
a las fuentes de datos en la red interna? El resultado es que las redes “protegidas”
están abiertas a ataques desde el Internet, utilizando un servidor web como
intermediario.
¡No subestime los efectos de ésta vulnerabilidad! En nuestra experiencia,

incluso el atacante más inexperto necesita sólo unos minutos para ganar
acceso a las redes protegidas utilizando técnicas estandarizadas y bien conocidas,
específicamente desarrolladas para explotar éste tipo de agujeros.
La más simple defensa contra ésto es el incremento de la segmentación de la red.

A través de la localización de fuente de datos, ej. un servidor SQL, en un segmento
de red separada y previniéndole de la comunicación directa con el resto de la red,
usted puede limitar el daño causado por semejante ataque.
Nota
El problema aquí no son los paquetes IP que son dirigidos a través de los servidores
DMZ, por eso el deshabilitar ”IP forwarding” no le proveerá ninguna protección.
El problema es que los intrusos pueden ejecutar comandos en estos servidores
del mismo modo que cualquiera en el teclado.
Debe también ser notado que su red interna será aún vulnerable
a los ataques incluso si el canal entre el DMZ y la red interna esta
hecha en un protocolo no-dirigible como un NetBEUI. Nuevamente, el problema
no son los paquetes que atraviesan redes inseguras hacia la red interna.

Mejor dicho, el problema es que aparatos inseguros pueden ejecutar comandos en

aparatos “protegidos”.
Otra forma de protección valiosa considerada es ajustar una fuente de datos

separados que contienen información limitada a la que el servidor web tiene
acceso. Esta debe sólo contener información estimada suficientemente insensible
a ser accedida desde un servidor web. Este proceso requiere de una exportación
automática de datos desde la fuente interna de datos a la fuente externa de datos,
para ser ejecutados cuando la información necesite ser actualizada, o en
determinados momentos del día. Un problema insuperable puede presentarse
cuando el servidor web necesite actualizar la fuente de datos. La mejor manera de
afrontar tal problema es mover la fuente afectada de datos a un segmento
separado de red, y de este modo reducir el daño potencial en caso de intromisión.

Parte IV
Administración
Esta parte cubre aspectos básicos de la gestión y administración
de los Firewalls D-Link, incluyendo:
• Plataforma de Configuración
• Registro
• Mantenimiento
• Ajustes Avanzados
CAPITULO 4
Plataforma de Configuración
4.1 Configurando Vía WebUI

4.1.1 Vista General
Los firewalls D-Link pueden ser configurados utilizando una interfaz web. Una
interfaz web es usualmente una manera rápida y eficiente para configurar un firewall, que
no requiere que el administrador instale ningún programa específico para configurar
éste. Esto también permitirá al administrador configurar el firewall remotamente,
de manera virtual desde cualquier lugar en el mundo.
4.1.2 Diseño de Interfaz

Antes de utilizar la interfaz WebUI, el usuario deberá ser autentificado a través del
ingreso de nombre de usuario/contraseña en la ventana de autentificación,
mostrado en la Figura 4.1.
Una vez registrado en el WebUI, al usuario se le presentará una página con tres
Secciones distintas, como se muestra en la Figura 4.2:
• Barra de Menu
• Lista con Vista de Arbol
• Ventana principal
19
20 Capitulo 4. Plataforma de Configuración
Figura 4.1: Ventana de Autentificación WebUI.
Figura 4.2: Ventana Principal WebUI.

4.1. Configurando Via WebUI 21
Barra Menu
La barra menu consiste en un número de botones con tanto una sola opción ó
múltiples sub-opciones.
• Home
Dirijase a la página de inicio del WebUI.
• Configuración
- Guardar y Activar: Guarda la configuración y activa las modificaciones.
- Descartar Modificaciones: Descarta las últimas modificaciones en la configuración.
• Herramientas
- Ping: Herramienta utilizada para ping anfitriones en la red. Útil para la solución
de problemas y depuración.
- Backup: Herramienta utilizada para guardar y restaurar respaldos de la configuración

actual.
- Reset: En esta página es posible reiniciar el firewall y reestablecerlo

a lo predeterminado de fábrica.
- Upgrade: En esta página las firmas IDS y firmware del firewall pueden ser
modernizados.
• Estado
- System: Aquí es mostrado el estado del sistema. Carga CPU, conexiones etc.
- Logging: Aquí es donde la carga almacenada en la memoria de registro es

desplegada.
- Connections: Despliega las conexiones actuales a través del firewall.
- Interfaces: Despliega el estado para interfaces y túneles.
- IPSec: Despliega el estado de información IPSec.
- Routes: Despliega la actual tabla de ruteo.
- DHCP Server: Despliega la información en uso para servidores DHCP.
- IDS: Despliega el estado de información IDS.
- SLB: Despliega el estado de información SLB.

22 Capítulo 4. Plataforma de Configuración
- Zona de Defensa: Despliega el estado de la información de la Zona de

Defensa.
• Logout
Log out from the WebUI.
• Help
Lea la última version de este manual.
Lista con Vista de Arbol
La vista arbol es un listado de las secciones de configuración en el firewall.

El árbol puede ser expandido para mostrar opciones de configuración más detallada.
Ventana Principal
La ventana principal despliega la sección de configuración seleccionada o el objeto a

modificar. Asegúrese de hacer click en el botón de OK para guardar los cambios
realizados a un objeto, o cancelar para descartarlos, antes de navegar más en la WebUI.
4.1.3 Operaciones de Configuración

Cuando se configura el firewall, las mismas direcciones IP, definiciones de red,
servicios etc, son a menudo utilizados en múltiples localizaciones a lo largo
de la configuración. Para simplificar la administración y hacerla más fácil para modificar
direcciones IP, redes etc, logical objects (véa 8 Logical Objects) son utilizados
a lo largo de la configuración del firewall.
Cuando el usuario ha configurado el firewall vía WebUI, la configuración

deberá ser guardada y activada antes de que la nueva configuración sea
utilizada por el firewall. Esto es realizado a través de la opción de barra menú ”Save and
Activate” bajo ”Configuration”.

4.2. Monitoreando Via CLI 23
4.2 Monitoreo Vía CLI

Los administradores pueden asimismo monitorear y solucionar problemas en el firewall
Interface de comandos (CLI), a través del empleo del puerto de Consola
en el Firewall.
La serie de puerto de consola es un puerto RS-232 que permite una conexión a un PC

o terminal. Para accesar el puerto de consola, son necesarios los siguientes
requisitos:
• Una terminal o computador (portátil) con un puerto serial la habilidad

de emular una terminal (ej utilizando el software Hyper Terminal incluido
en la mayoría de las instalaciones Microsoft Windows). La terminal
debe tener los siguientes ajustes: 9600 baud, No parity, 8 bits
y 1 stop bit.
• Un cable RS-232 con conectores apropiados.
Para conectar una terminal al puerto consola, siga los siguientes pasos:
1. Coloque los ajustes terminales como ha sido descrito con anterioridad.
2. Conecte uno de los conectores del cable RS-232 directamente al

puerto de consola en el hardware del firewall.
3. Conecte el otro extremo del cable a la terminal o conector serial del

c computador que hace correr el software de comunicación.
A través del texto basado en el Interface de comandos (CLI) de la consola, un

análisis más profundo de varios aspectos estadísticos del firewall pueden ser
conducidos también como un detector de problemas avanzado. Una referencia
detallada de varios comandos que pueden ser utilizados en esta interfaz es cubierta
en el Apéndice A, Referencia de Comandos de Consola.
Nota
Actualmente, el CLI puede sólo ser utilizado para visualización de estadísticas y estados.
El firewall no puede ser configurado a través de esta interfaz.

CAPITULO 5
Registro
Este capítulo trata de los principios de registro y entrega una breve introducción al
diseño de los firewalls de registro D-Link. Para información acerca de cómo implementar
la función de registro por el firewall, refiérase a 13, Ajustes de registro
en la parte de Fundamentos.
5.1 Vista General

El registro es una práctica para mantener el contacto con aquellas actividades
pertinentes a la operación de firewall y a las políticas de seguridad que el firewall
está reforzando. El archivo generado desde el registro ayuda a los administradores a
observar en detalle qué eventos han ocurrido. Los firewalls D-Link entregan una
variedad de opciones para registrar actividades.
5.1.1 Importancia & Capacidades

A pesar de qué política de seguridad es implementada por el firewall,
el registro es crítico para asegurar que la implementación está corriendo sin
problemas además de mantenerse en alerta sobre lo que está ocurriendo en el entorno de
una red. Esto entrega a los profesionales la habilidad de monitorear la operación del
dispositivo y asegurar que los eventos en progreso están anticipados.
Desde que el firewall se encarga de todo el tráfico que pasa a través de sus
interfaces desde una red protegida a otras áreas y además de los otros caminos
alrededor, ninguna desconfiguración o uso incorrecto de las funciones pueden resultar
25
26 Chapter 5. Logging
en una discontinuidad de servicios. A través de la revisión de salida de registro, hay

una gran oportunidad de que administrador sea capaz de imaginar los
eventos problemáticos, y tomar las acciones necesarias para corregir esos
problemas. Una vez que los problemas son resueltos, el contenido correcto puede
encontrado en la nueva información de registro para verificar que los cambios
apropiados han sido realizados.
El registro puede también ser utilizado en el Intrusion Detection System (IDS). El tráfico
sospechado e intentado, fallido, o ataques exitosos contra el firewall y la red
pueden ser registrados, con notificaciones enviadas para alertar a los administradores.
Esta información de registro es muy útil para que los administradores determinen
cómo puede ocurrir una intromisión y qué método de contra-taque puede ser
adherido para mejorar las implementaciones del firewall.
Tan pronto como los eventos requeridos por el registro ocurran, el firewall genera
respuestas basadas en tales eventos, y luego éstas son exportadas en archivos
de una forma u otra a uno o más receptores de registro.
5.1.2 Eventos
Hay un número de situaciones diferentes que pueden causar que los firewalls D-Link
generen y entreguen datos de registro. Cada una de tales ocasiones es referida
como un evento.
Algunos eventos, por ejemplo, el inicio y cierre del firewall, generarán siempre
entradas de registro. Otros, por ejemplo, para registrar si una regla especificada es
coincidente, son configurables. La razón más obvia y simple transmisión
por evento generado es, por supuesto, cuando el registro es configurado en la regla del
firewall, tal como una regla IP, reglas de Autentificación del Usuario, Reglas Threshold,
etc.
Los eventos de interés para captura generalmente caen en tres categorías claras:
Firewall System Issues, Security Policy, y Network Connection Status.
System Issues
Esta categoría de eventos registra el estado del sistema del firewall y cambios del
hardware, por ejemplo:
• BUFFERS– eventos con respecto al uso del buffer.
• TIMESYNC– tiempos de sincronización de eventos firewall.
• HWM– hardware monitoreador de eventos.
• SYSTEM– Inicio & Cierre.

5.1. Overview 27
Security Policy
La información sobre diferentes acciones gatilladas por las reglas de firewall
son entregadas en esta categoría, incluyendo:
• ACCEPT– paquetes aceptados para futuras intromisiones.
• FWD- paquetes direccionados sin estado
• DROP– paquetes rechazados.
Conexiones de Red
Varias conexiones de tráfico, estados de routing, y registro de actividades del
usuario para depurar y monitorear el ambiente de la red caen en esta categoría.
Tanto los servicios autorizados como conexiones rechazadas pueden ser
registradas. Normalmente, el nombre de los servicios (o nombre de protocolo) es
utilizado como la etiqueta para el evento en la entrada de registro. Los eventos
más
comunes dentro de ésta categoría son enlistados a continuación.
• USAGE
– estadísticas periódicas del uso del sistema, tal como amplitud de banda,
conexiones, y etc.
• CONN
– eventos de estado de ingeniería, ej. apertura/cierre de conexiones.
• NETCON
– eventos de gestión remota del administrador.
• IFACEMON
– eventos de control de interfaz.
• DHCP/DHCPRELAY/DHCPSERVER
– eventos para cliente DHCP, para la retransmisión, o para el servidor.
• ARP
– mensajes de registro provenientes de la ingeniería ARP.
• FRAG
–mensajes de registro provenientes de la ingeniería de manejo fragmentada.
• OSPF/DYNROUTING
– información para el ruteodinámico.
• RFO
– dirige eventos fail over.
• PPP/PPPOE/PPTP/L2TP/GRE/IPSEC
– eventos para diferentes túneles.
• USERAUTH
– eventos para la autentificación del usuario.

28 Capítulo 5. Registro
• HA
– Eventos de Alta Disponibilidad.
• IDS/IDSUPDATE
– Eventos de Detección de Intrusos y actualización de base de datos.
• ZONEDEFENSE
– Eventos de Zona de Defensa.
• SNMP
– accesos SNMP permitidos y rechazados.
• IP.../TCP...
– información concerniente a paquetes TCP/IP.
5.2 Receptores de Registro

Un receptor de registro es un computador distinto, conocido como ”Syslog server”,
o una sección de memoria construida en el firewall para manejar todos los
eventos registrados, generados por el firewall.
Una vez que un nuevo evento es recibido, el receptor adhiere una entrada en el archivo
de registro para grabar los datos.
5.2.1 Receptor Syslog

El Firewall D-Link puede enviar datos de registro a los receptores Syslog.
El Syslog es un protocolo estandarizado para el envío de datos de registro a
loghosts, aunque no haya un formato estandarizado para estos mensajes de registro.
El formato utilizado por el Firewall D-Link es ideal para procedimientos automatizados,
filtración y búsqueda.
Aunque el formato exacto de cada entrada de registro depende de cómo trabaje
el recipiente syslog particular, la mayoría son muy similares. El modo en el cual los registros
son leídos es además dependiente del receptor. Los demonios Syslog en servidores
UNIX usualmente registran a archivos de texto, línea por línea.
La mayoría de los receptores syslog introducen cada entrada de registro con un registro
de tiempo y la dirección IP del artefacto que envía el dato de registro:
Feb 5 2000 09:45:23 gateway.ourcompany.com
Esto es seguido por el texto que el emisor ha elegido enviar. Todas las entradas de
registro del Firewall D-Link son introducidas por ”FW:” y una categoría, ej.
”DROP:” .

5.2. Receptores de Registro 29
Con
Febel5fin de facilitar
2000 09:45:23elgateway.ourcompany.com
procesamiento automatizado
FW:deDROP:
todos los mensajes, los
Firewalls D-Link copian todos los datos de registro a una sola línea del texto. Los
datos siguientes al texto inicial son presentados en el formato nombre=valor. Esto
permite a los filtros automáticos encontrar fácilmente los valores que están buscando
El texto subsiguiente depende del evento que ha ocurrido.
sin suponer que una parte específica de datos se encuentra en una localización
específica en la entrada de datos. En un firewall D-Link, pueden ser configurados por
sobre 8 receptores Syslog y éstos pueden ser agrupados en uno o más grupos de
receptores. Comparado con el Memory Log Receiver el cual es introducido a
continuación, los receptores Syslog pueden ser utilizados para salvar y a largo plazo
almacenar los eventos registrados. Estos servidores de registro entregan una gestión
centralizada de archivos de registro, y el respaldo de los archivos, es posible
dependiendo del receptor(es) Syslog particular en uso.
5.2.2
Receptor de registro de memoria
Los firewalls D-Link pueden actuar como receptor de registro con su memoria
incorporada. Cuando la memoria de receptor de registro es habilitada en el firewall,
todos los eventos serán guardados en el archivo de registro en la memoria, y las
entradas más actuales generadas del archivo pueden ser desplegadas para el
administrador si lo solicita. Este almacenamiento de archivos de registro es temporal,
todos los contenidos del archivo pueden ser limpiados luego de ser reiniciado el
firewall, y ahí no hay respaldo. Solo una memoria de receptor de registro puede ser
configurada por un firewall
.
5.2.3
Receptor de Evento SMTP
Una única característica designada para eventos de registro IDS/IDP y alertas es
entregada por los firewalls D-Link, denominada como Receptor de Evento SMTP.
Con una apropiada configuración, el firewall está capacitado para registrar posibles
intromisiones y notificar al administrador enviando e-mail(s) para especificar
dirección(es) e-mail. Para mayor información acerca de esta función, refiérase a 19.5
Receptor de Registro SMTP para Eventos IDS.
31
CAPITULO 6
Mantenimiento
6.1 Actualizaciones del Firmware

Los Firewalls D-Link pueden ser modernizados con nuevos firmwares para introducir
nuevas funcionalidades y corregir problemas conocidos. Asegúrese de revisar regularmente
la website de soporte D-Link para nuevos firmware modernizados.
Ejemplo: Modernizando el Firmware
Este ejemplo describe cómo modernizar un Firewall D-Link con una nueva
versión de firmware.
WebUI
:
1. Verifique Versión Actual

Primero que todo, verifique cual versión de firmware está actualmente corriendo
en el Firewall D-Link.
Status → System: Tome nota del número de ”Firmware Version” ubicado bajo
”System Status”.
2. Descarga de Firmware Modernizado
Diríjase al website de soporte D-Link y navegue en la sección de soporte de su modelo
firewall. Revise si se encuentra disponible una modernización de la versión firmware que
usted está actualmente corriendo en el firewall.
Si existe una nueva versión, descárguela y colóquela en su hardrive y tome nota
de dónde coloca su nuevo archivo.
32 Capitulo 6. Mantenimiento
3. Modernize el Firmware Firewall
Diríjase a WebUI de su Firewall D-Link y navegue hacia la página Tools →

Upgrade en la barra de herramientas. Bajo ”Firmware Upload”, haga click en el botón
de ”Browse”. Seleccione el archivo de modernización de firmware que recientemente
descargó del website de soporte D-Link.
Haga click en el botón de ”Upload Firmware” y espere hasta que el archivo sea cargado
a continuación de esto se mostrarán las instrucciones en la página.
Aviso
NO SUSPENDA EL PROCESO DE CARGA DEL FIRMWARE.
La carga del firmware tomará algunos minutos dependiendo de la velocidad de

su conexión al firewall.
6.2 Reset a Valores de Fábrica
Hay tres maneras de reajustar el Firewall D-Link a sus ajustes firmware y configuración
predeterminados de fábrica.
1. Reajuste a Ajustes Preestablecidos de Fábrica desde el WebUI
En el WebUI del Firewall navegue a la página de Tools → Reset en la barra de

herramientas. Seleccione Reset to Factory Defaults, confirme y espere hasta que el
proceso de revertir esté completo.

6.2. Reajustar a Predeterminados de Fábrica. 33
2. Reajuste a los ajustes predeterminados de Fábrica vía Consola en

Serie.
Conecte el cable en serie y adjunte utilizando un software emulador de terminal
(si es utilizado Windows, puede ser utilizado el accesorio de comunicación
HyperTerminal). Reajuste el firewall. Presione cualquier tecla cuando aparezca el mensaje
”Press any key to abort and load boot menu” en la consola. Cuando aparezca el menu
seleccione ”Reset to factory defaults”, confirme y espere a que el proceso de revertir
se complete.
El siguiente procedimiento sólo se aplica al DFL-800:
3. Reajuste a los ajustes predeterminados de Fábrica utilizando el Switch

de Reajuste
Reajuste el firewall. Presione y mantenga por 20 segundos el botón de
”reset to factory defaults”. Espere a que el proceso de revertir esté completo y el
firewall se inicie.
El siguiente procedimiento sólo se aplica al DFL-1600/2500:
3. Reajuste a valores Predeterminados de Fábrica utilizando el Keypad y Display.
Reajuste el firewall. Presione cualquier tecla en el teclado cuando aparezca el mensaje

”Press keypad to Enter Setup” en la visualización. Seleccione ”Reset firewall”,
confirme seleccionando ”yes” y espere a que el proceso de revertir sea completado.
Aviso
NO SUSPENDA EL PROCESO DE REAJUSTAR A LOS AJUSTES DE FABRICA.
Si es suspendido, el firewall puede dejar de funcionar correctamente.
Luego del proceso de reajuste, los ajustes del firewall serán restaurados
permanentemente.

34 Capítulo 6. Mantenimiento
6.3 Respaldo de Configuración

La configuración de los Firewalls D-Link puede ser respaldada y restaurada a
solicitud. Esto puede por ejemplo ser utilizado para recordar
”last known good” configuración cuando se experimenta con diferentes ajustes de
configuración.
Para crear un respaldo de la configuración actual:
WebUI
:
Crear y Descargar el Paquete de Respaldo

En el WebUI del firewall D-Link navegue hacia la página Tools → Backup
en la barra de herramientas. Haga click en ”Download configuration”, seleccione un
nombre para el respaldo instantáneo y descargue el paquete.
Para restaurar una configuración respaldada:

WebUI
:
Restaurar el Paquete de Respaldo

En la WebUI del firewall D-Link navegue a la página de Tools → Backup
en la barra de herramientas. En la sub-sección de ”Restore unit’s configuration” ,
utilice la funcionalidad del buscador para localizar el paquete de respaldo. Haga click
en ”Upload configuration” y cuando se le pregunte, elija activar la configuración.
Nota
La funcionalidad de respaldo SOLO incluye la configuración del firewall.

La información Dinámica tal como el arriendo de base de datos del servidor DHCP ó
lista de bloqueo de la Zona de Defensa no serán respaldadas.
CAPITULO 7
Ajustes Avanzados
7.1 Vista General

.
Los Ajustes Avanzados contienen varios ajustes globales para un firewall en términos
de límites de tamaño de paquetes, tiempos de desconexión, parámetros de protocolo,
test de integridad estructural al que cada paquete debe ser sujeto, etc.
Generalmente, los valores predeterminados entregados en estas secciones son

apropiados para la mayoría de las instalaciones. Pero tales opciones entregan
posibilidades de instalaciones avanzadas para configurar casi todos los aspectos del
firewall.
WebUI
:
En la WebUI, hay una sección de Ajustes Avanzados localizada en:

System → Advanced Settings.
La mayoría de los ajustes configurables están disponibles aquí. Otros

Ajustes avanzados para adaptar funciones específicas del firewall pueden ser
encontrados en la página de configuración dentro de secciones pertinentes.
Un caso que requiere modificaciones en los ajustes avanzados es explicado

en 17.4, Ejemplo: Habilitando autentificación HTTP vía base de datos de usuario local.
Nótese que en este ejemplo, los ajustes avanzados en la sección de Administración
Remota del Firewall necesitan ser modificados para resolver una colisión de número de
Puerto TCP con un servicio de autentificación HTTP.
Parte V
Fundamentos
Desde una perspectiva tanto física como lógica, esta parte
introduce los componentes básicos de los firewalls D-Link, los
cuales son construcciones de bloqueo para políticas de seguridad
y funciones avanzadas.
Los tópicos en esta parte incluyen:
• Objetos Logicos
• Interfaces
• Ruteo
• Fecha & Tiempo
• DNS
• Ajustes de Registro
CAPITULO 8
Objetos Lógicos
Los objetos lógicos son elementos básicos de red definidos en el firewall, refiriendo
a las entidades que necesitan ser protegidas y también las fuentes inseguras y
aplicaciones que deben ser monitoreadas por las políticas de seguridad.
8.1 Libro de Direcciones

Como un libro de contactos que registra los nombres de personas junto con el
número telefónico y dirección email, el libro de direcciones en un Firewall es una
lista de nombres simbólicos asociados con varios tipos de direcciones, incluyendo
direcciones IP y direcciones MAC ethernet. Estos ítems son elementos
fundamentales fuertemente utilizados en la configuración del firewall, tal como
la especificación de campos de filtro para políticas de seguridad. Por lo tanto, elegir
un nombre descriptivo y fácil de recordar para cada ítem de dirección facilitará
enormemente el trabajo de administración. El administrador puede utilizar el
nombre en cada tarea de configuración en vez de llenar direcciones cada vez y en caso
de modificar una dirección, solo se necesita modificar un punto en el libro de direcciones.
8.1.1 Direcciones IP
Para habilitar que cada entidad reciba y envíe datos desde o hacia una red TCP/IP,
se necesita una dirección IP de capa de red (OSI capa 3) para asociar
con cada punto entre la entidad de red y el link físico, esta es una interfaz.
En otras palabras, cada interfaz tiene una dirección IP única en la red para indicar
39
40 Capítulo 8. Objetivos Lógicos.
su localización.
El libro de dirección en los firewalls D-Link permite al administrador nombrar

Direcciones IP tanto para un solo anfitrión, una red, un par maestro/esclavo utilizado
en Alta disponibilidad, o un grupo de computadores o interfaces. Una dirección
”0.0.0.0/0” denominada como ”all-nets” es utilizada para denotar todas las redes
posibles.
Ejemplos de ”IP4Host/Network” son mostrados a continuación.
La autentificación de usuario desde una dirección IP objetiva puede ser habilitada en

”IP4 Host/Network ” o ”IP4 Address Group” agregando nombres de usuarios ó
grupos de usuarios al objeto. Una vez que el firewall verifica el tráfico que fluye
desde una dirección objetiva y encuentra el nombre de usuario definido en éste,
avisará al usuario con solicitudes de autentificación de acuerdo a las Reglas de
Autentificación del Usuario (Ver 17 Autentificación del Usuario).
Ejemplo: Especificando un anfitrión IP4
La dirección IP ”192.168.0.1” es definida por la interfaz de red local denominada

como ”lan ip”.
WebUI
:
Objects → Address Book → InterfaceAddresses → Add → IP4

Host/Network → General:
Ingrese lo siguiente y luego haga click en OK:
Name: lan ip
IP Address: 192.168.0.1
(InterfaceAddresses es un Archivo de Dirección para agrupar las direcciones de
Interfaces IP)
Ejemplo: Especificando una Red IP4
La red local ”192.168.0.0/24” es definida como ”lannet”.
WebUI
:
Objects → Address Book → InterfaceAddresses → Add → IP4

Host/Network → General:
Name: lannet
IP Address: 192.168.0.0/24

8.2. Servicios 41
Ejemplo: Habilitando la Autentificación de Usuario de un IP Objetivo
Un grupo de usuarios ”users” es definido en la dirección de red local ”lannet” para

crear una dirección de autentificación objetiva ”lannet users”. Para información sobre
especificar el grupo usuario, refiérase a Escenario 17.4.
WebUI
:
1. Especificar una Red IP4 objetiva ”lannet” como se muestra en el ultimo ejemplo.
2. Objects → Address Book → Add → IP4 Address Group

→ General:
Ingrese lo siguiente:
Name: lannet users
Group members:
De la lista Available, seleccione ”lannet” object y colóquelo en la lista
Selected.
Comments: Auth. ”users” on lannet
→ User Authentication:
Ingrese el nombre del grupo usuario y luego haga click en OK:
Comma-separated list of user names and groups: users
8.1.2 Direccion Ethernet

Una dirección Ethernet, también conocida como dirección LAN, una dirección física, ó
dirección MAC (media access control), es una capa de datos única (capa 2 OSI)
identificador de la tarjeta de interfaz de red, ej. un adaptador ethernet, el cual es utilizado
para el envío de estructuras de datos. Los usuarios pueden asimismo
entregar un nombre específico a una dirección Ethernet o un grupo de dirección
como se explica en 8.1.1 arriba.
8.2 Servicios
Los Servicios son programas software que utilizan protocolo de definición para entregar
varias aplicaciones a los usuarios de red. La mayoría de las aplicaciones cuentan
con protocolos localizados en la capa 7 OSI – capa de Aplicación – para entregar
comunicación desde

42 Capítulo 8. Objetivos Lógicos
un programa de usuario a otros grupos en una red. En esta capa, otros grupos son
identificados y pueden ser alcanzados por tipos de protocolos de aplicación
específicos y parámetros correspondientes, tal como números de puerto. Por
ejemplo, el servicio HTTP de buscador en Web es definido como para utilizar el protocolo
TCP con puerto de destino 80. Alguno de los otros servicios populares en esta capa
incluyen FTP, POP3, SMTP, Telnet, y etc. Junto con estas aplicaciones oficialmente
definidas, los servicios a solicitud del usuario pueden ser creados en los
firewalls D-Link.
Los servicios son simples, en el sentido en el que éstos no pueden llevar a cabo
por sí mismos ninguna acción en el firewall. De este modo, una definición de
servicio no incluye ninguna información si el servicio debe ser permitido a través del
Firewall o no. Tal decisión es realizada por completo por las reglas IP del firewall, en las
cuales el servicio es utilizado como un parámetro de filtro. Para mayor información
acerca de cómo utilizar los servicios en reglas , véase 14 Reglas IP.
8.2.1 Tipos de servicio

En los firewalls D-Link, los servicios pueden ser configurados a través de tres
opciones: TCP/UDP, ICMP, y servicio de Protocolo IP. Un servicio es básicamente
definido por un nombre descriptivo, el tipo de protocolo, y parámetros de protocolo.
Los diferentes servicios pueden ser unidos en un Grupo de Servicio para simplificar las
políticas de configuración, de manera que los administradores no necesiten configurar
una regla para cada servicio.
Servicios basados en TCP y UDP
Los servicios de aplicación son corridos de manera más común en TCP o UDP, y son
a menudo asociados con un número de puerto bien conocido. En el firewall, están
definidos por el tipo de protocolo que la aplicación usa, y el número de puerto
asignado o rango de puerto. Para muchos servicios, un solo puerto de destino es
suficiente. El servicio HTTP, por ejemplo, utiliza un puerto de destino TCP 80,
Telnet utiliza TCP 23, y SMT utiliza TCP 25. En estos casos, todos los puertos
(0-65535) serán aceptados como puertos de fuente.
Los puertos múltiples o rangos de puerto pueden asimismo ser ajustados, por ejemplo, un
servicio puede ser definido para tener como puertos de fuente 1024-65535 y puertos de
destino 80-82, 90-92, 95. En este caso, un paquete TCP o UDP con puerto de destino
que es uno de 80, 81, 82, 90, 91, 92 o 95, y con un puerto de fuente en el rango
1024-65535, coincidirá con este servicio.
Guía de Usuario de los firewalls D-Link

8.2. Services 43
Ejemplo: Especificar un servicio TCP -- HTTP
En este ejemplo, es definido el servicio HTTP para la conexión de servidores web.

Como se ha explicado previamente, HTTP utiliza puerto de destino TCP 80.
WebUI
:
Objects → Services → Add → TCP/UDP:

General
Name: HTTP
Type: TCP
Source: 0-65535
Destination: 80
Servicios basados en ICMP
Internet Control Message Protocol (ICMP), es un protocolo integrado con IP

para el reporte de errores y transmisión de control de información. El servicio PING,
por ejemplo, utiliza ICMP para probar una conectividad Internet. El mensaje ICMP
repartido en paquetes IP, y cada mensaje es un protocolo separado poseedor de un
formato propio. Este contenido cambia dependiendo del Mensaje tipo y código.
El tipo de mensaje ICMP que puede ser configurado en los firewalls D-Link junto con
diversos códigos son enlistados a continuación:
• Echo Request – enviado por PING a un destino con el fin de verificar la

conectividad.
• Destination Unreachable – la fuente ha informado que un problema ha ocurrido

cuando se está entregando un paquete. Hay códigos de 0 a 5 para este tipo:
- Code 0. Net Inalcanzable

- Code 1. Host Inalcanzable
- Code 2. Protocolo Inalcanzable
- Code 3. Puerto Inalcanzable
- Code 4. No puede Fragmentar
- Code 5. Ruta de Fuente Fallida

44 Capítulo 8. Objetivos Lógicos.
• Redirect – la fuente avisa que existe una mejor ruta para un paquete
particular. Los códigos asignados son los siguientes:
- Código 0. Redirecciona datagramas para la red

- Código 1. Redirecciona datagramas para el anfitrión
- Código 2. Redirecciona datagramas para el Tipo de Servicio y la red
- Código 3. Redirecciona datagramas para el Tipo de Servicio y el anfitrión
• Parameter Problem – identifica un parámetro incorrecto en el datagrama.
• Echo Reply – es la respuesta del destino al cual se ha enviado como un resultado

de la Echo Request.
• Source Quenching – la fuente envía datos demasiado rápido para el receptor,

el buffer se ha llenado.
• Time Exceeded – el paquete es descartado cuando toma demasiado tiempo en

ser entregado.
Ejemplo: Agregando un servicio ICMP solicitado
Un servicio ICMP solicitado es adherido y puede ser utilizado en políticas de

seguridad.
WebUI :
Objects → Services → Add → ICMP Service

→ General:
Ingrese un Nombre para el nuevo servicio ICMP.
→ ICMP Parameters
Seleccione el tipo ICMP y especifique los códigos para el servicio.
(Si es seleccionada la opción All ICMP Message Types, este servicio coincidirá con
Todos los 256 posibles Tipos de Mensajes ICMP.)
Haga click en OK.

8.2. Servicios 45
Servicio de protocolo IP definido por usuario
Los servicios que corren sobre una IP y despliegan funciones de capa de

aplicación/transporte, pueden ser definidas por números de protocolo IP. IP puede
transportar datos para un número de protocolos diferentes. Éstos están cada uno
identificado por un número único de protocolo IP especificado en un campo del
encabezado IP, por ejemplo, ICMP, IGMP, y EGP tienen números de protocolo 1,
2, y 8 respectivamente. Los números de protocolo IP actualmente asignados y referencias
están publicadas en el sitio web del Internet Assigned Numbers Authority (IANA):
http://www.iana.org/assignments/protocol-numbers
Similar a los rangos de puerto TCP/UDP descritos previamente, un rango de números

de protocolo IP pueden ser utilizados para especificar aplicaciones múltiples para
un servicio.
Ejemplo: Adheriendo un servicio que coincide con el protocolo GRE
(Para mayor información acerca GRE, refiérase a 22.2 PPTP/L2TP )
WebUI
:
Objects → Services → Add → IP Protocol Service

General
Name: GRE
IP Protocol: 47

46 Capitulo 8. Objetivos Lógicos
Grupo de Servicio
Los servicios definidos en las opciones anteriores pueden ser agrupadas con el
fin de simplificar la configuración de políticas de seguridad. Considere un servidor web
utilizando HTTP estándar al igual que SSL encriptado HTTP (HTTPS, refiérase a 22.3
SSL/TLS(HTTPS) ). En lugar de tener que crear dos reglas por separado
permitiendo ambos tipos de servicios a través del firewall, un grupo de servicio llamado,
por ejemplo, ”Web”, puede ser creado, con el HTTP y los servicios HTTPS como
miembros de grupo (mostrado en el ejemplo a continuación).
Ejemplo: Especificando un grupo de servicio "Web"
WebUI
:
Siga los pasos resumidos a continuación:
1. Adhiera un servicio el objeto TCP ”HTTP” con puerto 80.
2. Adhiera un servicio el objeto TCP ”HTTPS” con puerto 443.
3. Objects → Services → Add → Service Group

General
Name: Web
Elija ”HTTP” y ”HTTPS” desde la Available list y colóquelos en la lista seleccionada
Haga click en OK.
8.2.2 Reporte de Error & Protección de Conexión

Mensaje de error ICMP
El mensaje de error ICMP entrega una retroalimentación acerca de los

problemas en el ambiente de comunicación, ej. cuando un paquete IP no puede
alcanzar su destino. Sin embargo, los mensajes de error ICMP y firewalls no son
usualmente una muy buena combinación; el mensaje de error ICMP es iniciado
en el host de destino (o un dispositivo dentro del recorrido al destino) y enviado al
host de origen. El resultado es que el mensaje de error ICMP será interpretado
por el firewall como una nueva conexión y desechada, si no es explícitamente
permitido por los ajustes de regla del firewall. El permitir que cualquier mensaje
ICMP entrante esté capacitado para tener estos mensajes de error remitidos no es por lo
general
8.2. Servicios 47
una buena idea, ya que puede causar que la red protegida sea vulnerable a muchos
tipos de ataques, ej. DoS (Denial of Service) en particular.
Para resolver este problema, los firewalls D-Link pueden ser configurados para pasar un
mensaje de error ICMP sólo si está relacionado con una conexión existente a un
servicio.
Protección de Flood SYN (SYN Relay)
Un mecanismo denominado como ”SYN Relay” puede ser habilitado en el firewall para
proteger las direcciones de destino utilizados por un servicio desde el flujo SYN.
El ataque SYN flood es lanzado por un envío de solicitudes de conexión TCP

más rápido de lo que un mecanismo puede procesar. El agresor envía solicitudes SYN a
un servidor con una dirección de fuente burlada, la cual jamás responderá al
SYN/ACK del servidor. Cada solicitud SYN llenará una nueva conexión TCP de
la tabla de conexión del servidor; cuando todas las conexiones en la tabla estén
esperando por confiar y la tabla esté llena, el servidor no aceptará ninguna nueva
solicitud entrante. Las solicitudes de usuarios legítimos son luego ignorados.
El mecanismo ”SYN Relay” cuenta los ataques escondiendo el servidor protegido

detrás del firewall. El firewall recibe solicitudes SYN y se asegura de que la
conexión sea válida (esto es, el SYN/ACK respondida desde la fuente)
antes de enviar un paquete SYN al servidor. Si luego de cierto tiempo, no es recibido
ACK por el firewall, la conexión es suspendida.
Application Layer Gateway (ALG)
Una application layer gateway puede ser especificada para manejar diferentes servicios.
Mayor información puede ser encontrada en 18 Application Layer Gateway (ALG).
Para un servicio habilitado ALG, puede ser definido el número máximo de sesiones
permitidas al utilizar este servicio.

48 Capítulo 8. Objetivos Lógicos
8.3 Programas
Programacion es un camino para crear limitaciones oportunas en las reglas del firewall.
Esto habilita al usuario para definir un cierto período de tiempo, en el formato de
año–fecha–tiempo, lo cual sólo activará las reglas en los tiempos designados.
Cualquier actividad fuera del espacio de tiempo programado no seguirá las reglas
y por lo tanto no le será permitido el paso a través del firewall. Los programas pueden
ser configurados para tener un tiempo de inicio y término, así como la creación de
diferentes períodos de tiempo en un día.
Ejemplo: Un programa en horario de oficina
Una organización puede desear que sólo los usuarios internos accedan a Internet
durante las horas de trabajo, y esperar que esta restricción sea válida por un año.
Por lo tanto, uno puede crear un programa para restringir al firewall para permitir
tráfico de Lunes-Viernes, 8AM-5PM solamente, comenzando desde cierta fecha y
hora, colocando 2005-04-01 00:00:00, para una fecha de término. Durante las horas
no laborales, el firewall no permitirá el acceso.
WebUI
:
Objects → Schedule Profiles → Add → Schedule Profile:
General
Name: Ingrese un nombre para este programa, e.j. ”office-hour”.
Defina un periodo de tiempo verificando los recuadros.
Start Date: Llene en el tiempo de inicio en un formato de ”aaaa-mm-dd hh:mm:ss”
ó haga click en el icono de calendario y elija la fecha de la ventana emergente.
End Date: (del mismo modo que ”Start Date” anterior)
Y luego haga click en OK.

8.4. Certificados X.509 49
8.4 Certificados X.509

Los firewalls D-Link soportan certificados que cumplen con el estándar internacional
ITU-T X.509. Esta tecnología utiliza una jerarquía de certificado X.509
con una criptografía de clave pública (Véase 20.2, Introducción a la Criptografía) para
conseguir la distribución de clave y autentificación de entidades.
8.4.1 Introducción a Certificados

Un certificado es una prueba digital de identidad. Éste enlaza una identidad a una clave
pública para establecer si una clave pública realmente pertenece al supuesto dueño.
De este modo, se previene una intercepción en la transferencia de datos por terceras
personas, las cuales pueden enviar una clave telefónica con el nombre e ID de
usuario de un receptor previsto. Un certificado consiste en lo siguiente:
- Una clave pública: La ”identity” del usuario, tal como nombre, ID del usuario, etc.
- Firmas digitales: Una declaración que informa que la información adjunta en el

Certificado ha sido respondida por una Certificate Authority (CA).
Colocando la información anterior junta, un certificado es una clave pública con

formas de identificación adjuntas, asociadas con un sello de aprobación por una
parte confiable.
Certification Authority
Una Certification Authority (CA) es una entidad confiable que dicta certificados
a otras entidades. El CA digitalmente firma todos los certificados que dicta. Una firma de
CA válida en un certificado verifica la identidad del titular, y garantiza que el certificado
no ha sido falsificado por terceros.
Una autoridad de certificación es responsable de asegurar que la información en cada

certificado que emite es correcta. Ésta también debe asegurar que la identidad del
certificado coincide con la identidad del titular del certificado.
Un CA puede también emitir certificados a otros CAs. Esto conduce a una jerarquía
de certificado ramificada. La CA más alta es denominada como CA de origen.
en ésta jerarquía, cada CA es firmada por el CA que está directamente sobre éste,
excepto para el CA de origen, el cual es típicamente firmado por él mismo.
Una trayectoria de certificado refiere al trayecto del certificado desde uno a otro. Cuando
se verifica la validez de un usuario certificado, el trayecto completo

50 Capitulo 8. Objetivos Lógicos
desde el usuario certificado hasta el certificado de origen debe ser examinado

antes de establecer la validez del usuario certificado.
El certificado CA es como cualquier otro certificado, excepto que éste permite

a la clave privada correspondiente firmar otros certificados. Debe ser comprometida
la clave privada del CA, por completo, incluyendo cada certificado que ésta ha firmado.
Tiempo de validez
Un certificado no es válido por siempre. Cada certificado contiene las fechas

dentro de las cuales es válido. Cuando este período de validez expira,
el certificado no puede seguir siendo utilizado, y se debe establecer un nuevo certificado.
Certificate Revocation Lists(CRL)
Una certificate revocation list (CRL) contiene una lista de todos los certificados que han
sido cancelados luego de su fecha de expiración. Esto puede suceder por distintas
razones. Una de éstas puede ser que la clave del certificado ha sido comprometida
de alguna manera, ó tal vez que el titular del certificado ha perdido los derechos de
autenticidad utilizando dicho certificado. Esto puede ocurrir, por ejemplo, si un
Empleado ha dejado la compañía desde donde el certificado ha sido establecido.
Una CRL es regularmente publicada en un servidor al cual todos los usuarios

Certificados tiene acceso, utilizando tanto los protocolos LDAP ó HTTP.
Los certificados a menudo contienen un campo de CRL Distribution Point (CDP), el

cual especifica la localización desde donde el CRL puede ser descargado. En algunos
casos los certificados no contienen este campo. En aquellos casos la localización del
CRL debe ser configurada manualmente. Véase 22.1.4, LDAP .
El CA actualiza su CRL a un intervalo asignado. La extensión de este intervalo

depende de cómo es configurado el CA. Usualmente, esto es entre una hora a varios
días.
Certificados confiables
Cuando se utilizan los certificados, el firewall confía en cualquiera cuyo certificado

esté firmado por un CA asignado. Antes de que un certificado sea aceptado, se siguen
los siguientes pasos para verificar la validez del certificado:
- La construcción de un trayecto de certificación hacia el CA de origen

confiable.
8.4. Certificados X.509 51
- La verificación de las firmas de todos los certificados en el trayecto de

certificación.
- Se trae el CRL de cada certificado para verificar que ninguno de los
certificados ha sido revocado.
Listas de Identificación
En adición a la verificación de las firmas de certificados, los firewalls D-Link también

emplean listas de identificación (Véase 22.1.4, Identification Lists(IDLists)). Una
lista de identificación es una lista que nombra todas las identidades remotas que tienen
acceso permitido a través de un túnel VPN específico, entregando el resultado de la
validación del procedimiento de certificación descrito anteriormente.
8.4.2 Certificados X.509 en el Firewall D-Link

El certificado X.509 puede ser cargado al Firewall D-Link para utilizar en la
Autentificación IKE/IPSec, webauth etc. Hay dos tipos de certificados que pueden ser
cargados, certificados auto-firmados y certificados remotos pertenecientes a un par
Remoto ó servidor CA.
Ejemplo: Cargando un Certificado a un Firewall D-Link
Este ejemplo describe cómo cargar un certificado X.509 a un Firewall D-Link.

El certificado puede ser tanto auto-firmado ó perteneciente a un par remoto ó
servidor CA.
WebUI
:
Carga de Certificado
Objects → X.509 Certificates → Add → X.509 Certificate:
Name: Name of the certificate.
Options
Seleccione uno de lo siguiente:
• Upload self-signed X.509 Certificate
• Upload a remote certificate
Luego haga click en OK y siga las instrucciones en pantalla.

CAPITULO 9
Interfaces
Las interfaces físicas son entradas de las conexiones de red. Éstas permiten
al tráfico de red ingresar o salir de las áreas de red con las cuales éstas conectan.
Con el fin de controlar el tráfico en ambas direcciones, entrantes y salientes, y proteger
la red local, las reglas de seguridad en el firewall están limitadas a todas
las interfaces relevantes.
9.1 Ethernet
Ethernet es una de las arquitecturas Local Area Network (LAN) que sirven como base
para el IEEE 802.3 estándard, la cual especifica las capas de software físicas y
mas bajas. Es una de las más ampliamente implementadas LAN estándar.
Esta sección presenta el concepto de interfaz Ethernet. Alguno de los protocolos más
comúnmente utilizados que corren en Ethernet son introducidos en las secciones
9.2 VLAN y 9.4 PPPoE en este capítulo, otros como IPsec, PPTP,
L2TP, y ARP son cubiertos luego en el documento.
9.1.1 Interfaces Ethernet

Una interfaz Ethernet representa un adaptador físico Ethernet utilizado en el firewall. La
configuración de una interfaz Ethernet involucra la función de una dirección IP y otros
parámetros, para hacer a la interfaz accesible a la capa de red.
Cuando se instala el firewall D-Link, todos los adaptadores Ethernet soportados en el
53
54 Capitulo 9. Interfaces
firewall serán enumerados y configurados durante el proceso de ajuste de consola

local. Cada adaptador físico Ethernet se volverá una interfaz Ethernet y se entregará un
nombre en la configuración del firewall. Los administradores pueden adaptar el
nombre descriptivo y modificar las direcciones IP de una interfaz luego de la instalación
primaria.
9.1.2 Interfaces Ethernet en los Firewalls D-Link

La configuración de una interfaz Ethernet principalmente incluyen la especificación
del nombre y direcciones. Una dirección IP esta limitada a cada interfaz que debe ser
utilizada para ping el firewall, controlarlo remotamente, y ser ajustado por el firewall
como fuente de dirección para conexiones dinámicamente traducidas. Una dirección
IP adicional puede ser publicada en una interfaz utilizando ARP para similar el efecto
de una interfaz que posee más de una IP (Véase 9.6 ARP). Además, los
administradores pueden aplicar funciones de dirección dinámica a la red habilitando
el cliente DHCP en la interfaz correspondiente (Véase 9.3 DHCP).
Como característica avanzada, Alta Disponibilidad(HA) & Transparencia pueden

ser implementadas en la base de las interfaces firewall.
El HA habilita a las interfaces para compartir una dirección IP común y cada una como
una dirección IP privada para únicamente identificar un nodo cluster. El IP privado es
derivado desde el Par de Dirección HA IP4 configurado en el Libro de Dirección
objeto (Véase XIII High Availability para mayor información sobre escenarios cluster
HA).
Cuando se ajusta una interfaz para utilizar el modo transparente, el firewall actuará como
un switch de capa 2 y mostrará el tráfico que pasa a través de esa interfaz sin
modificar la fuente o destino de la información de dirección. Ambos lados de la
comunicación serán inconscientes de la presencia del firewall.
Para la configuración del modo transparente en las interfaces, refiérase a 27
Transparencia.
Nota
En el firewall, hay dos interfaces lógicas denominadas como ”core” y

”any” respectivamente. ”core” se localiza en el corazón del firewall, todo el tráfico
desde las interfaces físicas son reemitidas a ”core” para ser controladas por
las políticas de seguridad. ”any” representa todas las interfaces posibles incluyendo
”core”.

9.1. Ethernet 55
Ejemplo: Una configuración de interfaz LAN
La interfaz conectada a LAN (o uno de los LANs) es configurada con

”lan ip”, ”lannet”, y la dirección de puerta de enlace predeterminada ”lan
gate”.
WebUI
:
1. Especificando el anfitrión IP4 – ”lan ip” y ”lan gate”, y una Red IP4
– ”lannet” en el Objects.
(Vea los ejemplos en 8.1 Address Book)
2. Interfaces → Ethernet:
Haga click en el item para interfaz LAN
→ General:
Name: Defina o modifique el nombre de la interfaz interface en el recuadro de editar.
IP Address: Seleccione ”lan ip” desde la lista desplegable.
Network: Seleccione ”lannet” desde la lista desplegable.
Default Gateway: Seleccione ”lan gate” desde la lista desplegable.
3. Optional settings:
→ General:
Habilite DHCP Client en el recuadro de verificación
Habilite Transparent Mode en el recuadro de verificación
→ Hardware Settings:
(Los ajustes de red del hardware del adaptador pueden ser ajustados aquí.)
Media – Especifique si la velocidad del vínculo debe ser auto-negociada o
bloqueada a una velocidad estática.
Duplex – Especifique si duplex (bidireccional) debe ser auto-negociada o
bloqueada por completo ó half duplex.
→ Advanced:
Recuadro de verificación de Automatic Route Creation
Route Metric edit box
(Verificando estas opciones y especificando el valor métrico, la interfaz configurada
Aquí será adherida a la Main Routing Table
Como rutas para la información de dirección de destino. El valor métrico
Predeterminado es 100.)
High Availability: Selección de dirección IP Privada.

9.2 LAN Virtual (VLAN)

La conexión de Redes Virtual es la habilidad que tienen los dispositivos de red para
manejar las topologías de red lógica en la parte superior de la conexión física actual,
permitiendo segmentos arbitrarios dentro de una red para ser combinado en un grupo
lógico. Desde que la flexibilidad y el fácil control de red entregado por las topologías
lógicas, la conexión de red virtual se ha vuelto una de las mayores áreas en el trabajo
internet
Los firewalls D-Link son por complete obedientes con las especificaciones IEEE
802.1Q para LANs virtuales, presentados por la definición de interfaces virtuales sobre
la interfaz física Ethernet. Cada interfaz virtual es interpretada como una interfaz
lógica por el firewall, con el mismo control de políticas de seguridad y capacidades
de configuración como interfaz regular.
9.2.1 Infraestructura VLAN

Una Local Area Network (LAN) es una emisión de dominio, que es, una sección de la red
Cuando el ambiente LAN se vuelve más grande, el soporte de

aplicaciones broadcast o multicast que inundan paquetes totalmente implican un
desperdicio considerable de banda ancha, debido a que los paquetes son a menudo
re-direccionados a nodos que no los requieren.
Los LAN virtuales (VLAN) permiten a un LAN físico ser dividido en varios
LANs lógicos más pequeños los cuales tienen diferentes emisores de dominio. Ésto
limita el tamaño del emisor de dominio para cada LAN lógico, salva los costos de
emision de la banda ancha para optimizar el rendimiento y asignación de recursos,
y además divide grandes LANs en varias zonas de seguridad independientes
Para adherir puntos de control de seguridad. Los dispositivos localizados en el mismo
LAN pueden comunicarse sin tener conciencia de los dispositivos en otros LANs
Virtuales. Esto es ideal para separar departamentos industriales desde topologías
físicas a diferentes segmentos de función.
Una infraestructura simple de VLAN es mostrada en la Figura 9.1. En este caso, un

Firewall D-Link es configurado para tener 2 interfaces VLAN. Ahora, aunque los clientes y
servidores se encuentren aún compartiendo el mismo medio físico, el Cliente A puede
comunicarse sólo con el servidor D y el firewall desde que éstos son configurados

9.2. LAN Virtual (VLAN) 57
A un mismo VLAN, y el Cliente B puede comunicarse sólo con el Servidor C

a través del firewall.
Figura 9.1: Una infraestructura VLAN.
9.2.2 VLAN 802.1Q Estándar
El IEEE 802.1Q estándar define la operación de dispositivos VLAN que

permiten la definición, operación y administración de topologías Virtuales LAN
dentro de infraestructuras LAN.
Las especificaciones 802.1Q establecen un método estándar para la etiquetación de

esquemas Ethernet con información de socios VLAN. Como es definido en el estándar,
una etiqueta de 4-byte es añadida al esquema Ethernet conteniendo una parte del
indicador del tipo de esquema VLAN (0x8100), un identificador VLAN(VID), y alguna
información de control (mostrado en la Tabla 9.1).
Hay 12 bits para VID dentro de cada etiqueta de 4-byte. Con estos 12 bits de
identificador, pueden existir por sobre 4096 VLANs en una red física.
Sin embargo, todas están reservadas y todos los ceros indican la no asociación VLAN.
Todos los otros identificadores pueden ser utilizados para indicar un VLAN
particular.
bytes
8 6 6 4 2 46 4
to
1500
Pre- Dest. Sou- Len- Data CRC
amble rce 32 bits gth
16 3 1 12
VLAN Pri- CFI VID
Type ority
Indicator
(0x8100)
VLAN Tag
Tabla 9.1: Esquema Ethernet 802.1Q Estándar.
9.2.3 Implementación VLAN

Cumpliendo con el 802.1Q estándar, el firewall D-Link implementa VLAN definiendo
una o más interfaces VLAN en éste utilizando un VID único para cada VLAN. Cuando
el esquema Ethernet es recibido por el firewall, éstos son examinados por el VID.
Y si el VID es encontrado, y coincide con la interfaz VID como ha sido definida, el firewall
estará capacitado para reconocer la membresía y destino de aquella comunicación
VLAN.
Los VLANs en los firewalls D-Link son útiles en varios escenarios diferentes, por
ejemplo, cuando se necesita un filtro firewall entre diferentes departamentos de una
organización, o cuando se necesita expandir el número de interfaces.

9.2. LAN Virtual (VLAN) 59
Ejemplo: Configurar una interfaz VLAN en un Firewall D-Link
Este ejemplo muestra cómo configurar una interfaz VLAN.
WebUI
:
1. Crear una interfaz VLAN.
Interfaces → VLAN → Add → VLAN:

General
Name: Digite un nombre para la interfaz VLAN.
Interface: Seleccione la interfaz Ethernet a utilizar.
VLAN ID: Seleccione una ID VLAN conveniente. Dos VLANs no pueden tener la misma
ID VLAN si están definidos en la misma interfaz Ethernet. ( La misma ID deberá ser
Utilizada en el lado de término.)
Ajustes de Dirección
IP Address: Seleccione la dirección IP que la interfaz VLAN debe utilizar. Si no es
configurado, se debe utilizar el IP de la interfaz Ethernet. (Opcional)
Network: Seleccione la red para esta interfaz VLAN. (Opcional)
Default Gateway: Seleccione la puerta de enlace predeterminada para esta interfaz VLAN.
(Opcional)
Luego haga click en OK
9.2.4 Utilizando LANs Virtuales para Expandir Interfaces Firewall
Los LANs virtuales son excelentes herramientas para expandir el número de interfaces
en los firewalls D-Link. Los Firewalls D-Link con interfaces Ethernet de gigabit
pueden fácilmente ser expandidas con 16 nuevas interfaces utilizando un switch Ethernet
de puerto-16 con puerto uplink gigabit y soporte de LAN Virtual.
El proceso trazado a continuación describe los pasos requeridos para ejecutar una
expansión de interfaz. Note que la configuración específica del switch y firewall es un
modelo altamente dependiente y fuera del alcance de esta documentación.
• Conectar el puerto gigabit uplink del switch a una de las interfaces gigabit del
firewall.
• Crear 16 LANs Virtuales en el firewall, nombrado, por ejemplo, de vlan01 a

vlan16, cada uno con una ID VLAN única
• En el switch, mapee cada ID VLAN a un puerto switch, y asegúrese de que el

puerto uplink esté configurado como un puerto trunk para todos los IDs VLAN.
• Cada puerto del switch sera visto ahora como una interfaz lógica en el firewall.
De este modo, el tráfico ingresando a través del switch, por ejemplo, puerto 12
sera recibido por la interfaz vlan 12 en el firewall.
En el ejemplo anterior, fue utilizado un puerto gigabit uplink en el switch y una interfaz
gigabit en el firewall. Las interfaces gigabit no son un requisito desde una perspectiva
de la funcionalidad;.
Sin embargo, desde una perspectiva de rendimiento, las interfaces gigabit son
recomendadas. Recuerde que un sólo link Ethernet es utilizado para llevar todo el
tráfico desde los puertos 16 switch, cada uno con una velocidad de link de interfaz de
100 Mbps.
9.3 DHCP
Es la abreviación para Dynamic Host Configuration Protocol, DHCP es el
protocolo de configuración de anfitrión de tercera generación para TCP/IP, el cual está
basado directamente en el BOOTP (Boot Protocol). Éste es utilizado para una asignación
automático de las direcciones de red y configuraciones para anfitriones recientemente
incluídos.
El propósito de utilizar DHCP es reducir el trabajo necesario para administrar una amplia
red IP. Existe un mecanismo software para mantener un seguimiento de las direcciones
IP más que la necesidad de que un administrador maneje las tareas. Esto significa que
un nuevo computador puede ser adherido a una red sin el problema de asignarle
manualmente una dirección IP única. El dispositivo Firewall D-Link puede actuar tanto
como un cliente DHCP, un servidor, o un transmisor a través de las interfaces.
Las funciones de servidor DHCP y de transmisión son cubiertas en 26, Servidor DHCP &
Transmisor.
9.3.1 Cliente DHCP

El cliente DHCP reenvía el mensaje a un servidor DHCP local(o servidores)
y recibe una dirección IP dinámicamente desde un servidor DHCP para su interfaz
física. Un cliente DHCP puede recibir ofertas desde múltiples servidores DHCP

9.4. PPPoE 61
Y usualmente acepta la primera oferta que recibe. Los clientes pueden renovar o liberar
su dirección IP asignada durante el período de contrato.
Ejemplo: Configurando el firewall como un cliente DHCP
Para permitir que el firewall actúe como un cliente DHCP y localiza un servidor (es)
DHCP externo y reciba información de dirección dinámicamente, siga los pasos a
continuación:
WebUI
:
Interfaces → Ethernet:
Haga click en la interfaz que es conectada a la red externa y será utilizada como
cliente DHCP.
→ General:
Ajuste el nombre y direcciones de la interfaz.
(Vea el ejemplo en 9.1 Ethernet)
Marque la caja de verificación Enable DHCP Client.

Y luego haga Click en OK.
9.4 PPPoE
Point-to-Point Protocol sobre Ethernet (PPPoE) depende de los dos estándares
extensamente aceptados: Point-to-Point protocol (PPP) y Ethernet. Este es utilizado
para conectar múltiples usuarios en una red Ethernet al Internet a través de una
interfaz común en serie, tal como una sola línea DSL, dispositivo inalámbrico o
cable Modem. Todos los usuarios sobre el Ethernet comparten una conexión común,
entre tanto, el control de acceso y servicio pueden ser realizados en base a cada
usuario.
Hoy en día, muchos proveedores de un gran servidor Internet (ISPs) requieren clientes
para conectarse a través de PPPoE a su servicio Banda ancha. Utilizando PPPoE, el
proveedor puede fácilmente ejecutar las siguientes funciones por cada usuario:
• Soporte de seguridad y control de acceso – se requiere autentificación

nombre de usuario/contraseña. El proveedor puede seguir la dirección IP a un
usuario específico.
• Asignación automtico de dirección IP para usuarios PC (similar a DHCP 9.3).

62 Capítulo 9. Interfaces
Las direcciones IP pueden ser suministradas por grupos de usuario.

IP addresses provisioning can be per user groups.
9.4.1 PPP
Point-to-Point Protocol (PPP), es un protocolo de comunicación entre dos computadores
utilizando una interfaz en serie, por ejemplo, una conexión por red telefónica donde
un computador personal es conectado vía telefónica a un servidor.
El ISP suministra al usuario con una conexión PPP de modo que el servidor del
proveedor pueda responder las solicitudes del usuario, pasándolas por el Internet, y
reenvía las respuestas Internet solicitadas de vuelta al usuario. En comparación al
modelo de referencia OSI, PPP entrega un servicio de Capa 2 (capa de data-
link).
Como Capa 2, PPP define un mecanismo de encapsulación para soportar que
paquetes de multi-protocolos se displacen a través de redes IP. Comienza con un Link
Control Protocol (LCP) para el establecimiento de vínculo, configuración y pruebas.
Una vez que el LCP es inicializado, uno o varios Network Control Protocols
(NCPs) pueden ser utilizados para transportar el tráfico para un protocolo particular,
de modo que multiples protocolos puedan interoperar en el mismo enlace, por ejemplo,
ambos tráficos IP e IPX pueden compartir un enlace PPP.
La Autentificación está disponible como una opción para comunicaciones PPP. Los
protocolos de autentificación que comúnmente soporta PPP incluyen:
• Password Authentication Protocol (PAP)
• Challenge Handshake Authentication Protocol (CHAP)
• Microsoft CHAP version 1
• Microsoft CHAP version 2
Si es utilizada la autentificación, al menos uno de los pares debe autentificarse a sí mismo

antes de que los parámetros de protocolo de capa de red puedan ser negociados utilizando
NCP. Durante la negociación LCP y NCP, pueden ser negociados parámetros
opcionales, tales como Encriptación. Cuando se ha realizado una negociación LCP y NCP,
pueden ser enviados datagramas IP sobre el vínculo. Más información sobre aplicación y
seguridad de PPP puede ser encontrada en la sección 22.2 PPTP/L2TP.
9.4.2 Configuración de Cliente PPPoE

Los firewalls D-Link permiten a los usuarios una conexión segura y de fácil manejo al
ISP.

9.4. PPPoE 63
Interfaz PPPoE
Puesto que el protocolo PPPoE corre PPP sobre Ethernet, el firewall necesita utilizar
una de las interfaces normales Ethernet para correr sobre el tunel PPPoE.
Cada Túnel PPPoE es interpretado como una interfaz lógica por el firewall, con la
Misma]/o filtro/filtración, la capacidades de formación y configuración de tráfico como
interfaces regulares.
El tráfico de red proveniente del tunel PPPoE será transferido a la regla de ajustes del
Firewall para evaluación. La interfaz de fuente del tráfico de red es remitido al
nombre del Tunel PPPoE asociado en el firewall. El mismo es confiable para el tráfico
proveniente de la dirección opuesta, eso es, yendo a un túnel PPPoE.
Además una Ruta debe ser definida, de modo que el firewall conozca qué direcciones IP
deben ser aceptadas y enviadas a través del túnel PPPoE. El PPPoE puede
utilizar un nombre de servicio para distinguir entre diferentes servidores en la misma
red Ethernet.
Información de dirección IP
PPPoE utiliza una asignación de dirección IP automatica la cual es similar a DHCP.

Cuando el firewall recibe esta información de dirección IP desde el ISP, éste necesita
almacenarla en una red objectiva con un nombre simbólico de anfitrión/red, con el fin de
establecer la conexión PPP.
Autentificación del Usuario
Si es requerida una autentificación de usuario por el ISP, se puede ajustar en el firewall

el nombre de usuario y contraseña para ingresar en el servidor PPPoE.
Conectar en demanda
Si se permite el conectar en demanda, la conexión PPPoE se realizará sólo cuando haya

tráfico en la interfaz PPPoE. Es posible configurar cómo el firewall debe detectar
actividad en la interfaz, tanto en tráfico saliente, tráfico entrante o ambos. Además es
configurable el tiempo de espera de inactividad antes de que el túnel sea
desconectado.

Ejemplo: Una configuración de Cliente PPPoE
Este ejemplo describe cómo configurar un cliente PPPoE. El cliente PPPoE

es configurado en la interfaz WAN y todo el tráfico debe ser dirigido sobre el túnel
PPPoE.
WebUI
:
Cliente PPPoE
Se configurará el cliente PPPoE en la interfaz WAN.

Interfaces → PPPoE Tunnels → Add → PPPoE Tunnel:
Name: PPPoEClient
Physical Interface: WAN
Remote Network: 0.0.0.0/0 (todas las nets, como será dirigido todo el tráfico en el
tunel)
Service Name: Si su proveedor de servicio le ha entregado un nombre de servicio,
Ingrese aquí el nombre de servicio.
Username: El nombre de usuario entregado por su proveedor de servicio.
Password: La contraseña estregada por su proveedor de servicio.
Confirm Password: Re-digite la contraseña.
Autentificación
Es posible especificar exactamente qué protocolos debe utilizar el cliente PPPoE
para autentificarse. Se mantienen los ajustes predeterminados para la
autentificaciónn.
Dial-on-demand
Enable Dial-on-demand: Disable
Advanced
Si está habilitado ”Add route for remote network”, una nueva ruta será adherida parar
Esta interfaz.

9.5. Grupos de Interfaz 65
9.5 Grupos de Interfaz

Similar al grupo objetivo lógico, las interfaces múltiples pueden ser agrupadas juntas en
el firewall para aplicar una política común. Un grupo de interfaz puede consistir en
interfaces Ethernet regulares, interfaces VLAN, o Túneles VPN (vea 22).
Todos los miembros de un grupo de interfaz no necesitan ser interfaces del mismo tipo.
esto significa que un grupo de interfaz puede ser construido, por ejemplo, por dos
interfaces Ethernet y cuatro interfaces VLAN.
Ejemplo: Ejemplo de un Grupo de Interfaz
Este ejemplo describe cómo configurar un grupo objetivo de interfaz.
WebUI
:
• Crear un Grupo de Interfaz
Interfaces → Interface Groups → Add → Interface Group:

Name: testifgroup
Security/Transport Equivalent: Si está habilitado, el grupo de interfaz puede ser
Utilizado como una interfaz de destino en reglas donde las conexiones pueden
Necesitar ser desplazadas entre las interfaces. Ejemplos de tal uso pueden ser
Route Fail-Over y OSPF (ver 10.3.3) escenarios.
Interfaces: Seleccione las interfaces que deben formar parte del grupo.
• Utilice el Grupo de Interfaz
Un grupo de interfaz puede ser utilizado en varias configuraciones objetivas.

Por ejemplo, las reglas IP y reglas de autentificación del usuario pueden utilizar
grupos de interfaz.

9.6 ARP
Address Resolution Protocol (ARP) es un protocolo de red, el cual mapea una dirección
de protocol de capa de red a una dirección hardware de capa de datos vinculados. Por
ejemplo, ARP es utilizado para determinar la dirección IP de la dirección Ethernet
correspondiente. Este trabaja en la OSI Data Link Layer (Capa 2) y es encapsulado por
headers Ethernet para transmission.
Un anfitrión en una red Ethernet puede comunicarse con otro anfitrión, sólo si éste
conoce la dirección Ethernet (dirección MAC) de ese anfitrión. Los protocolos de
mayor nivel tal como IP utilizan direcciones IP. Estos son diferentes del plan de
direccionamiento de un hardware de más bajo nivel tal como dirección MAC. El ARP
es utilizado para conseguir la dirección Ethernet de un anfitrión desde su dirección
IP.
Cuando un anfitrión necesita determinar una dirección IP para una dirección
Ethernet, éste transmite un paquete de solicitud ARP. El paquete de solicitud ARP
contiene la fuente de dirección MAC, la fuente de dirección IP y la dirección IP de
destino. Cada anfitrión en la red local recibe este paquete. El anfitrión con la dirección
IP de destino específico, envía un paquete de respuesta ARP al anfitrión de origen
con su dirección MAC.
9.6.1 Tabla ARP

La Tabla ARP es utilizada para definir entradas estáticas ARP
o publicar direcciones IP con una dirección de hardware específica.
Los items estáticos ARP pueden ayudar en situaciones donde un dispositivo está
reportando una dirección de hardware incorrecto en respuesta a las solicitudes. Algunos
puentes de terminal de trabajo, tales como módems radio, tienen tales problemas. Estos
pueden también ser utilizados para cerrar una dirección IP a un hardware específico
para incrementar la seguridad o evitar efectos de denial-of-service si hay usuarios
en una red. Notese sin embargo que tal protección sólo se aplica a paquetes que son
enviados a esa dirección IP, no se aplica a los paquetes que son enviados desde
esa dirección IP.
El publicar una dirección IP utilizando ARP puede server para dos propósitos:
• Asistir a los equipos cercanos de red respondiendo a ARP de una manera incorrecta.
Esta área de uso es la menos común.
• Entregar la impresión de que una interfaz del firewall tiene más de una dirección
IP.

9.6. ARP 67
Para cumplir lo anterior, el firewall entrega respuestas a solicitudes ARP

con respecto a las direcciones IP en los items ARP publicados. Este propósito es útil
si hay varios espacios separados IP en un solo LAN. Los computadores en cada
espacio IP pueden luego utilizar una puerta de enlace en su propio espacio span cuando
estas direcciones de puerta de enlace son publicadas en la interfaz del firewall.
Otra área de uso es publicar múltiples direcciones en una interfaz externa, habilitando
al firewall para que una dirección estáticamente traduzca la comunicación a estas
direcciones y las envíe a servidores internos con direcciones IP privadas.
La diferencia entre XPublish y Publish es que XPublish ”miente” acerca de la dirección

hardware del remitente en el Ethernet header; este es ajustado para ser la misma que
la dirección hardware publicada en preferencia a la dirección hardware actual del
adaptador de red.
Si una dirección de hardware publicada es la misma que la dirección hardware del

adaptador de red, no hará diferencia si usted selecciona Publish o XPublish;
el resultado de red será el mismo.
Nota
En la selección ARP, las direcciones pueden solo ser publicadas una a la vez. La
sección de Ruta por el otro lado, puede manejar redes publicadas por completo
utilizando 10.8 Proxy ARP.
Nota
Para que las direcciones IP publicadas trabajen correctamente podría ser necesario
agregar una nueva ruta. (Véase 10 Routing) Si es agregada una dirección adicional
para una interfaz, la interfaz central deberá probablemente ser especificada como la
interfaz cuando se configure la ruta.

Ejemplo: Ejemplo ARP
Este ejemplo describe cómo agregar una dirección IP extra a una interfaz Ethernet o
VLAN utilizando una ARP pública.
WebUI
:
• Crear una Tabla de entrada ARP
Interfaces → ARP Table → Add → ARP Entry:

Mode: Publish
Interface: Seleccione la interfaz que debe tener la dirección IP extra
IP Address: Especifique la dirección IP que se agregará a la interfaz anterior.
MAC: Determine como 00-00-00-00-00-00 para utilizar la dirección MAC de la
interfaz.
Guia de Usuario de los Firewalls D-Link

CAPITULO 10
Routing
10.1 Vista General

Routing es un rol mayor en la capa de red (capa 3 OSI), el cual determina
cómo transportar paquetes desde el anfitrión inicial al receptor deseado.
Los dispositivos que funcionan en la capa de red, tal como routers o firewalls,
ejecutan el ruteo para conseguir dos tareas ante todo, la
Determinación de Trayectoria y el Packet Switching.
Determinación de Trayectoria
Antes de que cualquier paquete pueda ser enviado desde el remitente al receptor
se necesita determinar una trayectoria por la cual el paquete deba pasar.
Localizada en el corazón de cualquier dispositivo capaz de routing, como un
Firewall o un router es la tabla de routing, un mapa que entrega toda las
selecciones de ruta. Cada entrada en esta tabla de mapeo describe una ruta
disponible.
La definición de una ruta aquí es la conexión que vincula dos extremos de
comunicación y asimismo todos los dispositivos intermediarios de routing.
La descripción de ruta dentro de la tabla de routing indica la dirección del
receptor, y donde se encuentra la siguiente detención a la que el paquete se
debe dirigir para estar un paso más cerca de su destino, ya que en la circunstancia
de la red, es común tener más de un dispositivo situado a lo largo del camino.
Estos contenidos están almacenados en la tabla como campos diferentes, tal
como Interfaz, Red, Puerta de enlace, Destino, etc.
69
70 Capitulo 10. Routing
Cuando un paquete llega al router, éste consulta a la tabla de routing para

hacer una determinación de trayectoria. El router compara la dirección de
destino del paquete con las entradas que tiene en la tabla de routing, y
averigua la interfaz asociada y el salto siguiente desde la ruta coincidente
para reenviar el paquete. Las trayectorias almacenadas en la tabla son
calculadas por ciertos algoritmos de routing definidos por el router, el cual
siempre tratará de hacer la “mejor” decisión. La “mejor” significa una selección
de trayectoria que tenga el “menor costo” de transporte. En la práctica, lo
concerniente a ”costo” es normalmente la banda ancha, longitud de
trayectoria (salto), el promedio de retraso, y etc., lo cual es introducido en
10.3.2 metricas de Routing.
El algoritmo de Routing es también responsable de mantener la tabla routing a la

fecha, de modo que el router pueda obtener información de trayectoria correcta
para cada decisión. Las dos clases más frecuentes de algoritmos routing son
cubiertos en la siguiente sección.
Packet switching
Luego de que es elegida una trayectoria, las funciones de packet switching toman
control sobre cómo el paquete es realmente movido. De acuerdo a la
información de la ruta seleccionada, el firewall/router reescribe la dirección
física del paquete a la dirección del siguiente hop, y reenvía el paquete al
siguiente hop con la dirección IP de destino sin modificar. En un escenario de la
vida real, muchos firewalls/routers pueden entrar a jugar durante el
proceso de reenvío del paquete, cada uno de estos reparte el paquete a su
vecino más cercano hasta que el paquete finalmente llegue al anfitrión receptor.
10.2 Jerarquía de Routing

En un ambiente complejo de red, cuando el número de routers se vuelve extenso,
el dominio de routing es a menudo dividido en diferentes áreas para proveer una mejor
escalabilidad. Los routers que residen bajo el mismo control administrativo son
agregados en una región denominada como ”autonomous system (AS)”.
Un AS puede ser, por ejemplo, todas las redes computacionales pertenecientes a una
universidad ó a la red privada de una compañía. La organización está capacitada
para correr y administrar sus redes con sus propias políticas y algoritmo de routing
preferible, mientras aún es capaz de conectarse al mundo ”exterior”

10.3. Algoritmos de Routing 71
Los routers dentro de un AS corren el mismo algoritmo routing y sólo necesitan conocer
la topología del área. Hay routers con puerta de enlace especial en el ASs que son
responsables de routing paquetes desde el área interna a varios ASs externos.
Los routers de puerta de enlace corren entre- el algoritmo de routing AS para determinar
las trayectorias hacia los destinos localizados en otros ASs. Los routers Intra-AS
mantienen todos relaciones con el router de puerta de enlace para dirigir los paquetes
hacia afuera. El algoritmo de routing intra-AS(Gateway interior) más frecuente es
es cubierto en la siguiente sección.
10.3 Algoritmos de Routing

Un algoritmo de routing es un operador de la tabla routing. En el ambiente de trabajo
Internet, hay usualmente varias trayectorias entre dos entidades de comunicación. La
tarea de los algoritmos de routing es que, dado un grupo de dispositivos de routing
Intermediarios con diferentes vínculos de conexión, el algoritmo calcula la “mejor”
trayectoria para que dos extremos se comuniquen y añadan la trayectoria en la
tabla.
En caso de que un dispositivo falle (un vínculo caído) en una trayectoria seleccionada u
otro problema puede hacer a la trayectoria inalcanzable, el algoritmo selecciona la
mejor ruta siguiente y actualiza la tabla de routing para mantener correcto el contenido de
la tabla.
Muchos algoritmos de routing han sido propuestos y cada uno muestra diferentes
diseños para diferentes metas. Los algoritmos más generalmente implementados pueden
ser clasificados en dos tipos:Ruteo Estatico y Ruteo dinamico
10.3.1 Routing Estático

Stactic Routing (Routing Estático) es un término utilizado para referir a la configuración manual de la
tabla routing. El administrador de red necesita planificar la tabla routing, y agregar
manualmente cada ruta necesaria e información relacionada en la tabla para un
reenvío exitoso del paquete. Cualquier modificación en una trayectoria podría
requerir que el administrador actualice la información en cada router afectado.
Como resultado, el trabajo administrativo en un ambiente de red a gran escala

puede ser engorroso y propenso a errores. En el caso en que el router no se encuentre
apropiadamente configurado en la tabla de routing, el router buscará en la tabla la
determinación de una trayectoria y al no encontrar una ruta adecuada, éste

simplemente desecha el paquete. Por lo tanto, el routing estático es a menudo utilizado

para realizar ajustes mínimos de rutas para alcanzar sólo redes conectadas
directamente.
10.3.2 Routing Dinámico

Complementando el algoritmo de routing estático, el Dinamic Routing (Routing Dinámico)
se adapta a las modificaciones de la topología de red ó cargas de tráfico automáticamente.
Éste se entera primero de todas las redes conectadas, y obtiene mayor información de
rutas desde otros routers que corren por el mismo algoritmo. El algoritmo luego organiza
las rutas que recolecta, selecciona la ruta más apropiada para el destino del que se ha
enterado, añade la ruta a su tabla de routing, y distribuye esta información a los otros
routers.
El routing Dinámico responde a las actualizaciones de routing en el recorrido y es

más susceptible a problemas como loops de routing. En el internet, se utilizan usualmente
dos tipos de algoritmos routing dinámicos: un Distance Vector(DV)
algoritmo & un Link State(LS) algoritmo. El cómo se decide la “mejor” ruta y el compartir
la información actualizada con otros routers depende del tipo de algoritmo aplicado.
Distance vector algorithm
El algoritmo de Distance vector (DV) es un algoritmo de routing descentralizado,

que calcula la “mejor” trayectoria en la forma de distribución. Cada router calcula los
costos de sus propios vínculos adjuntos, y comparte la información de ruta sólo con
sus routers vecinos. El router gradualmente aprende la trayectoria de menor costo
por un calculo iterativo e intercambio de conocimientos con sus vecinos.
El protocolo de información de Ruteo(RIP) es un algoritmo DV bien conocido.

El RIP envía mensajes de actualización regularmente, y refleja las modificaciones de
Routing en la tabla routing. Su determinación de trayectoria está basada en la longitud
del número de routers intermediarios en la trayectoria, o también llamados hops. Luego
de la actualización de su propia tabla routing, el router comienza inmediatamente a
transmitir su tabla de routing completa a sus routers vecinos para informar las
modificaciones.
Link state algorithm
De modo diferente a los algoritmos DV, el algoritmo Link state (LS) habilita a los routers
para mantener tablas de routing que reflejen la topología de la red completa,
una visión global de la información de routing. Como es definido en este algoritmo,
cada router transmite sus vínculos adjuntos y costos de vínculo a todos los demás
Routers en la red. Un router, una vez que recepciona las transmisiones del resto,

corre el algoritmo LS y puede calcular un grupo igual de trayectorias a bajo costo

como todos los demás routers. Cualquier modificación al estado del vínculo será enviado
donde sea en la red, de modo que todos los routers mantengan la misma información de
tabla routing.
Open Shortest Path First(OSPF) es un algoritmo LS comúnmente utilizado. Un router
habilitado OSPF identifica los routers y subnets que están conectados directamente a
a este primero. Luego, se transmite la información a todos los demás routers. Cada
Router utiliza la información que recibe para construir una tabla sobre como se ve la red completa.
Con una tabla de routing completa a mano, cada router puede identificar las subredes
y routers que conducen a cualquier destinación específica.
Los routers OSPF sólo transmiten información actualizada cuando hay cualquier
modificación en vez de la tabla completa.
OSPF depende de varias métricas para la determinación de trayectoria, incluyendo

Hops, banda ancha, carga, retraso, y etc. La adaptación de criterio según el usuario es además
permitido para definirse en el algoritmo, lo cual entrega a los administradores de la red
un mejor control sobre el proceso de routing. Más detalles acerca del algoritmo OSPF
es cubierto en 10.3.3 OSPF.
Comparación
Link state algorithm, debido a su estado de los enlaces globales de información mantenida en todos
Lados de la red, como un alto nivel de control de configuración y escalabilidad.
Este responde a modificaciones transmitiendo sólo la información actualizada
a todos los demás, y por lo tanto entrega una convergencia más rápida y una menor
posibilidad de loops de ruteo. OSPF puede además operar dentro de una
jerarquía, aunque RIP no tenga conocimiento del direccionamiento sub-red. Por otro
lado, OSPF exige un alto costo relativo, ej. un mayor poder CPU y memoria,
que un RIP, por consiguiente, puede ser más costoso de implementar.
Los firewalls D-Link utilizan OSPF como el algoritmo de routing dinámico.
Routing metrics
Routing metrics(los costos) son los criterios que un algoritmo de routing utiliza para
calcular la “mejor” ruta. Las principales consideraciones para un reenvío exitoso de
los paquetes incluyen lo siguiente:
• Longitud de la trayectoria
– La longitud de trayectoria es la suma de los costos asociados a cada vínculo.
Un valor comúnmente utilizado para esta métrica es denominada hop count, el
número de dispositivos routing, e.j. routers/firewalls, a través de los cuales
el paquete debe pasar en su trayectoria desde la fuente a su destino.

74 Capítulo 10. Routing
• Bandwidth
– Bandwidth es la capacidad de tráfico de una trayectoria, indicado por
”Mbps”.
• Load
– Load se refiere al uso de un router. El uso puede ser evaluado por la utilización
CPU y el rendimiento.
• Delay
– Delay es lo que se refiere al tiempo que toma mover un paquete desde la
fuente al destino. El tiempo depende de muchos factores, tales como la
amplitud de banda, carga, y la longitud de la trayectoria.
Diferentes protocolos de routing dependen de uno o varias métricas para examinar y

evaluar los vínculos en la red. Respecto a las metas del diseño, el algoritmo utiliza
sus métricas para decidir las trayectorias óptimas.
10.3.3 OSPF
OSPF es el algoritmo de routing dinámico incluído en los firewalls D-Link.
Desde la sección previa, se pueden observar las principales características del OSPF
como un Link state routing algorithm. A continuación observaremos la actual
operación de este algoritmo.
Areas & Routers
OSPF ofrece un routing jerárquico para entregar un mejor soporte a ambientes

complejos de red. En la actualidad las redes se han vuelto más y más sofisticadas,
el tamaño de la completa tabla de routing, el tiempo requerido para el cálculo de routing,
y el tráfico para el intercambio de información para una gran red se vuelve excesivo. El
OSPF habilita al administrador para dividir el AS (autonomous system) en varias
áreas más pequeñas, de modo que la carga del calculo de routing y mantención de
rutas en cada router sea reducido.
Un área OSPF es un grupo de anfitriones computacionales y routers dentro de un

AS, identificado por una área única de ID, y cada router OSPF posee un router
único ID con el formato de una dirección IP.
En la parte superior de la jerarquía OSPF se encuentra un área central denominada

backbone area a la cual debe conectarse todas la demás áreas en el AS. El backbone
area es responsable de la distribución de información routing entre todas las áreas
conectadas y posee el ID de área ID 0.0.0.0. En algunos casos en donde no es posible
conectarse físicamente al backbone area, un Virtual Link (VLink) puede ser

configurado para conectarse al backbone a través de una no-backbone area. VLink

pueden también ser utilizados para vincularse a través de áreas backbone
divididas.
Una área normal OSPF actúa como una red privada conectada al área
backbone a través de algún router denominado Area Border Router(ABR).
ABRs posee interfaces en más de un área, y mantiene por separado la base de
datos de información de routing para cada área a la cual se encuentran conectados
por una interfaz. Los routers que residen en la misma área OSPF sólo necesitan
aprender y sincronizar la información link-state con el ABR.
Algunos Routers que intercambian información de routing con routers en otros ASs
son llamados Autonomous System Boundary Routers(ASBRs).
ASBRs introducen rutas externamente aprendidas al AS y llena el routing externo
notificando por completo a todas las áreas normales OSPF.
Para reducir el tráfico excedente de notificaciones de rutas externas, se puede

configurar un área especial denominado ”stub area”. Cuando es configurado
el stub area, el ABR anunciará una ruta predeterminada automáticamente de modo
que los routers en el stub area puedan alcanzar los destinos fuera del área. La
ruta predeterminada se vuelve el único punto de salida del stub area, y el área no
aceptará transmisiones de rutas externas.
Proceso Operativo
Establishment – ”Hello”
En la fase de inicialización, cada router dentro de un área detecta sus redes

conectadas directamente, y envía paquetes de ”Hello” a todas sus interfaces
habilitadas OSPF para determinar quiénes son sus routers vecinos.
Los routers que poseen interfaces directamente conectadas y residen en la misma
área OSPF se vuelven vecinos.
Cuando un router envía y recibe paquetes ”Hello” y detecta múltiples

routers en un AS, éste seleccionará un Designated Router(DR) y además un
Backup Designated Router(BDR) para un intercambio de información
link-state adicional.
DR y BDR son elegidos automáticamente por el protocolo ”Hello” en cada red

transmitida OSPF. La Router Priority que es configurable en base a cada
interfaz, es el parámetro que controla la elección. El router con el mayor numero
de prioridad se vuelve DR y el siguiente más alto se vuelve BDR. Si el número

76 Capítulo 10. Routing
de prioridad 0 es especificado a un router, éste no será apto para la elección

DR/BDR.
Una vez que es seleccionado el DR y el BDR, todos los otros routers dentro de
la misma área OSPF establecen una relación con éstos para intercambios
de información routing adicionales. Ningún router encendido después
aceptará el DR/BDR existente en la red a pesar de su propia prioridad
router. Desde que existe una alta demanda en el control de información del estado
de vínculo central del DR, la Router Priority debe ser configurada para elegir el
router más confiable en una red como DR. BDR es elegido al mismo tiempo
que DR, y establece la misma relación con los demás routers en el área, con
el fin de de hacer la transición a un nuevo DR smoother si hubiese alguna
falla del DR primario.
En adición al establecimiento de relación, los paquetes ”Hello” actúan además

como mensajes Keepalive para mantener el trayecto de la reactividad de los
enlaces. Los paquetes ”Hello” son enviados periódicamente con un intervalo
predefinido para permitir a los routers conocer que los demás routers aun se
encuentran en funcionamiento.
Update – ”LSA”
Cada router mantiene información para routing ”state” y ”link”. Un “link” es

una interfaz en el router y el ”state” del vínculo es la información que incluye la
dirección de interfaz, red, routers vecinos, y etc. Esta información “link-state”
es almacenada en una estructura de datos de router denominada
”link-state database”.
Cuando un router determina el DR por el paquete ”Hello”, generará una

link-state advertisement (LSA) y la enviará a DR. El DR controla
y actualiza su base de datos de estado-link central y distribuye la información
de base de datos a todos los demás routers en la misma área OSPF.
Luego del intercambio inicial y la construcción de la base de datos, cada

Router dentro de la misma área OSPF contendrá una base de datos idéntica, la
cual es un mapa topológico completo del área incluyendo el costo de los
vínculos. Debido a cualquier cambio en la información routing, un router guardará
una nueva copia del estado de vínculo en su base de datos y enviará LSA a DR.
El DR luego excederá la actualización a todos los routers participantes en el
área para sincronizar la base de datos del link-state.
Path determination – ”SPF”

10.4. Failover de Ruta 77
Luego de que la base de datos de cada router es intercambiado y sincronizado por

completo, el router calculará un árbol de Shortest Path First(SPF) para todos los
destinos conocidos basados en la base de datos. Al correr el algoritmo SPF, cada
router estará capacitado para determinar la mejor (menor costo) trayectoria
para el reenvío de datos a cualquier destino en el área. El destino, costo
asociado, y el siguiente hop para alcanzar el destino será añadido a la tabla de
routing IP de cada router.
Sobre cualquier actualización al link-state database, un router recalculará el árbol

de trayectoria más corta y actualizará la tabla routing.
Autentificación OSPF
La autentificación está disponible como un método de seguridad opcional para

el ambiente OSPF. Un router puede validar la identidad de otro router durante
el intercambio de información de link-state. La autentificación OSPF puede ser
tanto ninguna, simple, o MD5. Con la autentificación simple, la frase de paso
se vuelve en blanco sobre el link, mientras que con el algoritmo
mensaje resumen MD5, la clave no pasará sobre el vínculo de
forma directa. De este modo, MD5 debe ser considerado como un medio más seguro
de autentificación. Mas información sobre encriptación, mensaje resumen,
y autentificación se puede encontrar en 20.2 Introducción a la
Criptografía.
10.4 Route Failover

La característica de Failover de ruta puede ser utilizada cuando hay dos
o más rutas a un destino. Por ejemplo en un escenario donde dos ISP se encuentran
disponibles para conectarse a Internet. Un ISP, el primario, es utilizado en un caso
normal, y un ISP de respaldo es utilizado cuando el ISP primario no funciona.
Las rutas pueden ser monitoreadas de dos formas. Una ruta monitoreada puede ser
considerada como caida” si el estado de vínculo en la interfaz se encuentra
caida o si la puerta de enlace predeterminada no responde a las solicitudes ARP.
Es posible utilizar ambos métodos de monitoreo al mismo tiempo.
Guía de usuario de los Firewalls D-Link

10.4.1 Escenario: Configuración de Failover de Ruta
Ejemplo: Dos ISPs
Figura 10.1: Escenario de Failover de Ruta
En este escenario mostrado en la figura 10.1, dos ISP:s (ISP A e ISP B) son utilizados
para conectar al Internet. ISP A es conectado a la interfaz WAN1 del firewall e ISP B
es conectado a la interfaz WAN2. Con el fin de configurar el firewall D-Link para
utilizar ISP A como ISP primario, e ISP B como ISP de respaldo, las rutas
monitoreadas deberán ser configuradas.
Se necesitará de dos rutas, una ruta predeterminada (0.0.0.0/0) con métrica 1, ésta
utiliza la puerta de enlace predeterminada de ISP A y una ruta predeterminada con
métrica 2 que utiliza la puerta de enlace predeterminada de ISP B.
WebUI
:
1. Apagar la auto configuración de rutas.
Primero que todo se necesita asegurar que no se agregan rutas automáticamente por
La interfaz WAN1 Y WAN2.
Interfaces → Ethernet → Edit (WAN1):
En la etiqueta de ”Advanced”, ingrese lo siguiente:
Agregar la ruta predeterminada si la puerta de enlace predeterminada es
especificada: Disable
Luego haga click OK
Interfaces → Ethernet → Edit (WAN2):
En la etiqueta ”Advanced”, ingrese lo siguiente:
Agregar la ruta predeterminada si la puerta de enlace predeterminada es
especificada: Disable

10.4. Failover de Ruta 79
2. Agregar una ruta predeterminada sobre la interfaz WAN1.
El siguiente paso es agregar una ruta predeterminada para la interfaz WAN1.

Routes → Main Routing Table → Add → Route:
General
Interface: WAN1
Network: 0.0.0.0/0
Gateway: Default gateway of ISP A.
Local IP Address: (None)
Metric: 1
Monitor
Monitor This Route: Enable
Monitor Interface Link Status: Enable
Monitor Gateway Using ARP Lookup: Enable
Nota
Es posible configurar manualmente el intervalo de búsqueda ARP a utilizar. El valor

elegido debe ser al menos 100 ms. Si rutas múltiples son monitoreadas en la misma
Interfaz, se deberá elegir el valor más alto para asegurar que la red no está excedida
con solicitudes ARP.
3. Agregar la ruta predeterminada sobre la interfaz WAN2.
El siguiente paso es agregar la ruta predeterminada para la interfaz WAN2.

Routes → Main Routing Table → Add → Route:
General
Interface: WAN2
Network: 0.0.0.0/0
Gateway: Default gateway of ISP B.
Metric: 2

4. Crear un grupo de interfaz y agregar reglas.
Para ser capaz de escribir reglas con interfaz de destino que puedan utilizar ambas
rutas, se debe crear un grupo de interfaz que utilice la característica de
seguridad/transporte Equivalente. Esto hace a las dos interfaces iguales en el sentido de
seguridad.
Creando el grupo de interfaz.
Name: Digite un nombre para el grupo de interfaz.
Security/Transport Equivalent: Enable
Interfaces: Seleccione la interfaz WAN1 y WAN2.
Agregar reglas.
Se agregan reglas utilizando el grupo de interfaz recientemente creado como interfaz
de destino.
Véa 14.3 IP Configuración de Reglas para detalles sobre cómo configurar las reglas.
Nota
La ruta predeterminada para la interfaz WAN2 no será monitoreada. La razón para esto
es que no se posee una ruta de respaldo para la ruta sobre la interfaz WAN2.

10.5. Implementación de Routing Dinámico 81
10.5 Implementación de Routing Dinámico

En los firewalls D-Link, la implementación de routing dinámico involucra dos tareas
primarias de configuración: OSPF process & dynamic routing policy.
10.5.1 Proceso OSPF

Los procesos OSPF configurados en el firewall agrupan firewalls OSPF participantes
y routers en areas OSPF. A Cada proceso habilitado en un router tiene una ID Router
única en un formato de dirección IP y se elige un método de autentificación.
Las áreas son definidas en base a las interfaces del firewall. Una interfaz que pertenece
a un area posee una Routing Priority a utilizar para la elección DR del área.
La interfaz puede ser utilizada tanto para transmitir, point-to-point, o comunicación
point-to-multipoint. La interfaz de transmisión se entera de los routers vecinos
automáticamente a través de la flooding de paquetes ”Hello”, mientras que para la
interfaz point-to-point o point-to-multipoint, se necesitan configurar por la interfaz
manualmente uno o más vecinos específicos. Las métricas de Routing utilizadas por
OSPF pueden también ser ajustadas o modificadas en una interfaz para interferir en
la determinación de trayectoria OSPF.
Una vez que el proceso OSPF es apropiadamente configurado por el firewall, éste puede
comenzar a dialogar con otros firewalls/routers utilizando algoritmo OSPF, enterándose
de la información link-state de la red.
10.5.2 Política de Routing Dinámico

Basado en la información de routing aprendida por el proceso OSPF, las políticas
de routing dinámico forman un filtro para la información y le indica al firewall qué hacer
con aquel conocimiento a través de acciones definidas.
Una regla de Políticas de Routing Dinámico filtra estáticamente configurada o las

rutas aprendidas OSPF de acuerdo a parámetros como el origen de las rutas,
destino, métrica, y etc. Las rutas coincidentes pueden ser controladas por las
acciones para ser tanto exportada a procesos OSPF o ser agregada a una o más tablas
routing.
Los usos más comunes para las Políticas de Routing Dinámico se encuentran
enlistados a continuación, ejemplos son entregados de manera consecutiva.
• Importación de rutas OSPF desde procesos OSPF a la tabla routing.

• Exportación de rutas desde la tabla routing a procesos OSPF.
• Exportación de rutas desde un proceso OSPF a otro proceso OSPF.
10.5.3 Escenarios: Configuración de Routing Dinámico

En esta sección, se ilustran escenarios básicos para la utilización de Procesos OSPF
y Políticas de Routing Dinámico.
Ejemplo: Ajustando procesos OSPF
Figura 10.2: Escenario de Proceso OSPF
Como se muestra en la Figura 10.2 , el firewall es adoptado para tener una interfaz
”lan3” conectada a una pareja de redes locales, en donde el firewall controlará el
único trayecto entre estas; y 2 interfaces, ”lan1” y ”lan2” adheridas a la red local más
larga. Algunas de las redes serán accesibles a través de ambas interfaces, de modo
que alguna redundancy puede ser lograda si una trayectoria se vuelve inalcanzable.
Esto se realiza localizando las dos interfaces ”lan1” y “lan2” en un grupo de interfaz
de seguridad equivalente.
Se crea un proceso OSPF denominado como ”ospf-proc1”, y sólo un área OSPF,

el área central ”area0” (0.0.0.0), es utilizado en este ejemplo. Las 3 interfaces
involucradas son agregadas al área para hacer al firewall participante del proceso
OSPF. Sin embargo, esto no agregará ninguna ruta ya enterada a la tabla routing, ni
informará a sus vecinos acerca de rutas estáticas en su tabla(s) routing (a excepción
de las rutas para las 3 interfaces participantes en este proceso OSPF). Para controlar
este intercambio de información, se necesita que las políticas de routing dinámico

entren a actuar (Vea los siguientes 2 escenarios para políticas de routing dinámico).
WebUI
:
1. Proceso OSPF:
– añadiendo un proceso OSPF denominado ”ospf-proc1”.
Routing → OSPF Processes → Add → OSPF Process: → General:

Name: ospf-proc1
→ Autentificación:
Seleccione uno de los tipos de autentificación que será utilizado en el proceso
,(ninguno, contraseña, ó MD5).

2. Area:
– especificando un área para el proceso ”ospf-proc1”.
En la página de configuración ”ospf-proc1”:

Add → Area:
General:
Name: ”area0”
Area ID: 0.0.0.0
Luego haga click en OK.

3. Interfaces:
– añadiendo las interfaces participantes en el proceso.
En la página de configuración ”area0”:

Interfaces → Add → Interface:
→ General:
Interfaz: seleccione ”lan1” desde la lista desplegable.
(”lan1” es adoptado para ser definido en las interfaces Ethernet)
Interface Type: select ”Auto”
Metric/Bandwidth:
Ajuste un valor métrico ó especifique una amplitud de banda, ej. 100Mbit.
→ Advanced:
Asegúrese de que los valores de configuración enlistados correspondan con los
valores utilizados por los otros vecinos OSPF en la red.
Repita este paso para añadir las interfaces ”lan2” y ”lan3”.
4. Grupo de Interfaz:
– localice el ”lan1” y ”lan2” en un grupo de interfaz con seguridad equivalente.

General:
Name: seleccione un nombre para el grupo, ej. ”ifgrp-ospf1”.
Marque el recuadro de Security/Transport Equivalent
Interfaces:
Seleccione ”lan1” y ”lan2” desde la lista Disponible y colóquelos en la lista
Seleccionada.
Nota
Asegúrese de que las reglas IP del firewall, las cuales permiten que el tráfico
pase a través de estas interfaces, utilicen este grupo de interfaz como
fuente de interfaz.
Guía de Usuario de los Firewall D-Link

Ejemplo: Importando rutas desde un AS OSPF a la table routing principal
Se asume que ya ha sido creado el previamente configurado proceso OSPF

denominado como ”ospf-proc1”.
En este escenario, todas las rutas recepcionadas desde ”ospf-proc1” serán añadidas en
la tabla routing principal, en la medida en que esto no es realizado automáticamente en el
firewall D-Link.
WebUI
:
1. Regla de Routing Dinámico:
Routing → Dynamic Routing Policy → Add → Dynamic Routing

Regla:
General
Name: e.j. ”importOSPFRoutes”.
Check From OSPF Process:
Seleccione ”ospf-proc1” desde la lista Disponible y colóquelo en la lista
Seleccionada.
Destination Network
...Or is within: all-nets
2. Routing Action:
En la página de configuración ”importOSPFRoutes”:

→ Routing Action → Add → Add Route:
General
Destination:
Seleccione la tabla routing principal desde la lista Available y colóquela en la lista
Selected.
El resultado de esta configuración es que toda la información routing aprendida será

añadida a la tabla routing principal en la medida que estas no invaliden ninguna ruta
estática ó rutas predeterminadas previamente insertadas.

Ejemplo: Exportando la ruta predeterminada dentro de un AS OSPF
Se asume que ya ha sido creado el previamente configurado proceso OSPF

denominado como ”ospf-proc1”.
En este escenario la ruta predeterminada (solamente) desde la tabla routing principal será
exportada dentro del proceso OSPF ”ospf-proc1”.
WebUI
:
1. Regla de Routing Dinámico:
Routing → Dynamic Routing Policy → Add → Dynamic Routing

Rule:
General
Name: e.j. ”exportDefRoute”
Check From Routing Table:
Seleccione la tabla routing principal desde la lista Available y colóquela en la lista
Selected.
Destination Network
Exactly Matches: all-nets
2. OSPF Actions:
En la página de configuración ”exportDefRoute”:

→ OSPF Actions → Add → Export OSPF:
General
Export to process: Seleccionar ”ospf-proc1” desde la lista desplegable.

10.6. Escenario: Configuración de Routing Estático 87
10.6 Escenario: Configuración de Routing

Estático
Ejemplo: Creando una Ruta Estática
Figura 10.3: Escenario de Routing Estático
En este ejemplo una red 192.168.2.0/24 ha sido ajustada para ser ruteada
a través de un router(192.168.1.10) en la red local, como se muestra en la
Figura 10.3. Para permitir que el firewall se comunique con esa red
(a través de la interfaz ”lan”), se debe configurar una ruta estática.
WebUI
:
Routing → Main Routing Table → Add → Route:
General:
Interface: Seleccione ”lan”.
Network: Seleccione la dirección de red objetiva (192.168.2.0/24).
Gateway: Seleccione la dirección de router objetivva (192.168.1.10).
Esto permitirá al firewall dirigir el tráfico destinado para la red 192.168.2.0/24

a través del router en 192.168.1.10.

Nota
Como un resultado a este ajuste el tráfico en retorno desde el router será dirigido
directamente sobre la red local con una regla de ajuste estándar ”Allow”. Para que
este escenario trabaje la regla de ajuste IP debe establecer que el tráfico para esta
Red sera NATed o que será reenviada sin estado de rastreo
10.7 Politica basada en Routing(PBR)

10.7.1 Vista General
Policy Based Routing(PBR) es una extensión al ruteo normal descrito previamente,
la cual ofrece al administrador de red una flexibilidad significante para implementar
sus propias políticas definidas en realizar decisiones de ruteo. Por PBR, los paquetes
pueden ir a través una ruta de usuario deseada aparte de la decidida por los
Algoritmos de ruteo.
Los routing normales reenvían paquetes de acuerdo a las direcciones de destino

IP derivadas de rutas estáticas ó protocolo de routing dinámico. Por ejemplo,
por OSPF, el router sólo tomará la trayectoria de menor-costo( la más corta) que
es obtenida desde un calculo OSPF para transportar paquetes. Complementando
a este destino direccion-, PBR entrega un mayor control sobre
routing habilitando al router para utilizar específicamente una trayectoria para cierto
flujo de tráfico basado en varios criterios, tales como las direcciones de fuente y
tipos de servicio.
Además, los firewalls D-Link extienden los beneficios de futuros PBR no sólo buscando
los paquetes uno por uno, sino también en información de estado, de modo que la política
pueda entregar control tanto en la dirección de reenvío como en la de retorno.
PBR puede ser aplicado en aplicaciones incluyendo:
• Fuente de routing sensible

– Cuando más de un IP es utilizado para proveer servicios Internet, PBR puede
dirigir el tráfico originado desde diferentes grupos de usuarios por diferentes
trayectorias a través del firewall.
• Servicio basado en routing

– PBR puede dirigir ciertos protocolos a través de proxies transparentes, tales
como Web caches y scanner anti-virus.

10.7. Policy Based Routing(PBR) 89
• Creación de áreas de red metropolitanas proveedor-independiente

– Todos los usuarios comparten un eje central activo común, pero pueden
utilizar diferentes ISPs, suscribiéndose a diferentes flujos de proveedores de
medios de comunicación.
La implementación PBR en los firewalls D-Link consiste en dos elementos:
• Una o más denominadas tablas PBR en adición a la tabla de routing normal.
• Una regla de ajuste PBR separada, la cual determina cual tabla routing nombrada
se debe utilizar.
10.7.2 Tablas routing basadas en políticas

La tablas routing basadas en políticas son tablas alternativas adicionales a la tabla de
Routing principal. Estas tablas contienen lo mismos campos para la descripción de
rutas como la tabla de routing principal, excepto que exista un parámetro de Ordenamiento
definido en cada uno de ellos. Este parámetro define cuándo la tabla PBR comienza a
actuar en las búsquedas de ruta del firewall, tanto antes o después que la tabla
principal.
10.7.3 Politica basada en Routing Policy

Las reglas definidas en las políticas PBR son selectores de diferentes tablas routing.
Cada regla PBR es provocada por los campos/recuadros de tipo de servicio e interfaz de
fuente & destino y red. Durante la búsqueda del firewall, la primera regla coincidente
es llevada a cabo, y las rutas pueden ser elegidas y priorizadas por el parámetro de orden
en base a cada estado aparte de la búsqueda paquete por paquete, lo cual significa
que las reglas PBR pueden especificar cuál tabla routing se utilizará tanto en dirección
de reenvío y retorno.
10.7.4 Ejecución PBR

La secuencia de ejecución PBR cooperadora con la tabla routing principal y los ajustes
de reglas del firewall pueden ser resumidas a continuación:
1. Verificador de tabla routing principal – busca la interfaz por las direcciones de

destino de los paquetes.
2. Consultador de reglas – busca en la lista de Reglas del firewall para determinar

La acción de los paquetes.
3. Consultador de políticas PBR – Si la búsqueda en el paso 2 resulta en la posibilidad

De que los paquetes pasen a través, el firewall desplegará una búsqueda en las

reglas PBR. La primera regla coincidente será la utilizada. De acuerdo a la

especificación en la regla, es seleccionada una tabla routing para utilizar. Si no
hay regla coincidente, las tablas PBR no serán utilizadas y ningún PBR será
ejecutado. El firewall reenviará los paquetes de acuerdo a la tabla routing
principal solamente.
4. Traducción de dirección – Si la regla SAT fue encontrada en la regla

consultada en el paso 2, la dirección de traducción será ejecutada.
5. Búsqueda de ruta final y reenvío de paquete – el firewall hace la búsqueda de

ruta final en la tabla routing decidida en el paso 3, y reenvíe el paquete.
La decisión de cuál tabla routing utilizar es realizada antes de llevar a cabo la

traducción de dirección. Sin embargo, la búsqueda actual de ruta es ejecutada en la
dirección modificada.
Ejemplo: Creando una tabla Ruteo Basada en políticas
En este ejemplo se creará una tabla routing basada en políticas denominada

”TestPBRTable”.
WebUI
:
Crear Tabla PBR
Routing → Policy-based Routing Tables → Add

→ Policy-based Routing Table:
Name: TestPBRTable
Orden:
First – significa que la table routing nombrada es consultada primero que todas. Si esta
Búsqueda falla, la búsqueda continuará en la tabla routing principal.
Default – significa que la tabla routing principal será consultada primero. Si la única
Coincidencia es la ruta predeterminada (0.0.0.0/0), la tabla routing nombrada será
consultada. Si la búsqueda en la tabla routing nombrada falla, la búsqueda por completo
es considerada como fallida.
Only – significa que la table routing nombrada es la única consultada. Si esta búsqueda
fracaza, la búsqueda no continuará en la tabla routing principal.
Remove Interface IP Routes: Si está habilitado, las rutas de interfaz predeterminada

Son removidas, ej. rutas a la interfaz central, las cuales son rutas al mismo firewall.

Ejemplo: Creando una Policy-Based Route
Luego de definir la tabla PBR ”TestPBRTable”, se adhieren rutas en la tabla de este

ejemplo.
WebUI
:
Create PBR Route

Routing → Policy-based Routing Tables → TestPBRTable → Add
→ Route:
Interface: La interfaz sobre la cual dirigir.
Network: La red para dirigir.
Gateway: La puerta de enlace hacia donde enviar los paquetes dirigidos.
Local IP Address: La dirección IP especificada aquí será automáticamente publicada
en la interfaz correspondiente. Esta dirección será además utilizada como la
dirección remitente en las consultas ARP. Si no es especificada ninguna dirección,
la dirección IP de la interfaz del firewall será utilizada.
Metric: Especifica la métrica para esta ruta. (Mayormente utilizada en escenarios de
Failover de ruta.
10.7.5 Escenario: Configuración PBR

El siguiente ejemplo ilustra un escenario ISP múltiple el cual es utilizado
comúnmente por policy based routing.
Ejemplo: Múltiples ISP
Este escenario asume lo siguiente:
• Cada ISP le entregará una red IP desde su alcance de red. Se asumirá un

escenario 2-ISP, con la red 1.2.3.0/24 perteneciente a ”ISP A” y ”2.3.4.0/24”
perteneciente a ”ISP B”. Las puertas de enlace ISP son 1.2.3.1 y 2.3.4.1,
respectivamente.
• Todas las direcciones en este escenario son direcciones públicas, para un facil entendimiento

• Este es un diseño ”drop-in”, donde no hay subnets de routing explícitas entre

la puerta de enlace ISP y el firewall.
En una red de área metropolitana proveedor-independiente, los clientes probablemente

tendrán una sola dirección IP, perteneciente tanto a uno u otro ISP. En un escenario
de una sola organización, serán configurados servidores accesibles públicamente con
dos direcciones IP separadas: una desde cada ISP. Sin embargo, esta diferencia no
importará para los ajustes de política de routing mismo.
Nótese que, para una sólo organización, la conectividad Internet a través de múltiples
ISP es normalmente mejor lograda a través de BGP, en donde no necesita preocuparse
en diferentes espacios IP ó políticas de routing. Desafortunadamente, esto no es siempre
posible, y aquí es donde la política basada en routing se vuelve una necesidad.
Se ajustará la tabla routing principal para utilizar ISP A, y adherir la tabla routing
nombrada, ”r2” que utiliza la puerta de enlace predeterminada de ISP.
Contenidos de la tabla routing:
Interface Network Gateway ProxyARP

LAN1 1.2.3.0/24 WAN1
LAN1 2.3.4.0/24 WAN1
WAN1 1.2.3.1/32 LAN1
WAN2 2.3.4.1/32 LAN1
WAN1 0.0.0.0/0 1.2.3.1
Contenidos de la named policy routing table r2:
Interface Network Gateway

WAN2 0.0.0.0/0 2.3.4.1
La tabla r2 tiene sus parámetros de Orden ajustados a Predeterminados, lo cual significa

que sólo sera consultado si la búsqueda de la tabla routing principal coincide la ruta
predeterminada(0.0.0.0/0)
.
Contenidos de Policy-based Routing Policy:
Source Source Dest. Dest. Service Forward Return

Interface Range Interface Range PBR PBR
LAN1 2.3.4.0/24 WAN2 0.0.0.0/0 ALL r2 <main>
WAN2 0.0.0.0/0 LAN1 2.3.4.0/24 ALL <main> r2

Nota
Se añaden rutas para conexiones entrantes así como salientes.
Completar los siguientes pasos para configurar este escenario ejemplo en el

firewall.
1. Añadir rutas a la tabla routing principal.

Añadir las rutas encontradas en la lista de rutas en la tabla routing principal, como se
ha mostrado anteriormente.
Ver sección 10.6 Creating a Static Route para mayor información sobre cómo añadir
rutas.
2. Crear una tabla PBR.

Ver sección 10.7.4 Creating a Policy-Based Routing Table para mayor información
sobre cómo crear una tabla PBR. Nombre la tabla ”r2” y asegúrese de que el orden
es ajustado a ”Default”.
3. Añadir la ruta predeterminada a la tabla PBR.

Añadir la ruta encontrada en la lista de rutas de la tabla de políticas routing nombrada
”r2”, como se mostró anteriormente.
Ver sección 10.7.4 Creating a Policy-Based Route para mayor información sobre
cómo añadir reglas a la tabla PBR.
4. Añadir políticas PBR.

Se necesita añadir dos políticas PBR de acuerdo a la lista de políticas mostradas
anteriormente.
Routing → Policy-based Routing Policy → Add → Policy-based

Routing Rule:
Ingrese la información encontrada en la lista de políticas desplegada con
anterioridad.
Repita este paso para añadir la segunda regla.

10.8 Proxy ARP

Proxy ARP es el proceso en el cual un sistema responde a las solicitudes ARP
de otro sistema. Por ejemplo, un anfitrión A envía una solicitud ARP para determinar
la dirección IP de un anfitrión B. En lugar del Anfitrión B, el firewall responde a esta
solicitud ARP.
En esencia, Proxy ARP tiene la misma funcionalidad que un ARP público (Ver 9.6
ARP)
La gran diferencia aquí es que usted puede, de manera simple, publicar redes
completas en una o más interfaces al mismo tiempo. Otra diferencia
de ligeramente menor significancia es que el firewall siempre publica las direcciones
como pertenecientes al firewall mismo; no es posible por lo tanto publicar direcciones
pertenecientes a otras direcciones de hardware.
Nota
Sólo es posible el Proxy ARP en interfaces Ethernet y VLAN.

CAPITULO 11
Fecha & Tiempo
El ajuste correcto de la fecha y hora es de gran importancia para que el producto

opere apropiadamente. Por ejemplo, las políticas de programación de tiempo y
auto-actualización de firmas IDS son dos características que requieren de una hora
correctamente ajustada. En adición, los mensajes de registro son etiquetados con
sellos de tiempo con el fin de señalar exactamente cuándo ocurre un evento específico.
El realizar ésto, no sólo asume un trabajo de reloj, sino que además el reloj es
sincronizado con otros dispositivos en la red.
Para mantener vigente la fecha y hora, el producto hace uso de un reloj construido a
tiempo real. El reloj es además equipado con una bacteria de respaldo para asegurar
la operación incluso si el producto pudiese perder la energía. En adición, el producto
soporta protocolos de sincronización de tiempo con el fin de ajustar automáticamente
el reloj basado en información de otros dispositivos.
95
96 Capitulo 11. Fecha & Tiempo
11.1 Ajustando la Fecha y Hora
11.1.1 Fecha y Tiempo en curso
Ejemplo:
Para ajustar la fecha y hora en curso, siga los pasos esbozados a continuación:
WebUI
:
System → Date and Time:

General
Haga click en el boton de Set Date and Time
En la ventana emergente,
Date: seleccione el año en curso, mes y día en las listas desplegables.
Time: Ingrese las horas en curso, minutes y segundos en el recuadro de editar.
Nota
La nueva fecha y hora en curso serán aplicadas

instantáneamente.
11.1.2 Zona Horaria

El ajuste de Zona Horaria debe ser determinada para reflejar la zona horaria donde
el producto se encuentra localizado físicamente.
Ejemplo:
Para modificar la zona horaria, siga los pasos esbozados a continuación:
WebUI
:

Time zone and daylight saving time settings
Time zone: seleccione la zona horaria apropiada en la lista desplegable.

11.1. Ajustando la Fecha y Tiempo 97
11.1.3 Daylight Saving Time(DST)

Muchas regiones cuentan con Daylight Saving Time (DST) (o tiempo de verano como es
denominado en muchos países). El horario de verano trabaja adelantando la hora
durante el verano para obtener mucho más de los días de verano. Desafortunadamente
los principios regulatorios del horario de verano varían según el país, y en algunos casos
hay incluso variantes dentro del mismo país. Por esta razón, el producto no conoce
automáticamente cuándo ajustar el DST. En cambio, esta información debe ser
manualmente entregada si el horario de verano es utilizado.
Hay básicamente dos parámetros determinantes del horario de verano; el

período DST y el offset DST. El período DST especifica entre qué fechas el horario
de verano debe comenzar y terminar, respectivamente. El DST offset indica el número
de minutos que se debe avanzar el reloj durante el período de horario de
Verano.
Ejemplo:
Para habilitar DST, siga los pasos esbozados a continuación:
WebUI
:

Time zone and daylight saving time settings
Marque Enable daylight saving time

Offset: ingrese el número de minutos que el reloj debe ser adelantado durante el
DST.
Start Date: seleccione la fecha de inicio del período DST en la lista desplegable.
End Date: seleccione la fecha de término.

98 Capítulo 11. Fecha & Hora
11.2 Sincronización de Tiempo

El reloj en el producto probablemente se vuelve más rápido o lento luego de un
período de operación. Esta es una conducta normal en la mayoría de las redes y
equipos computacionales y es comúnmente resuelto mediante la utilización de
un mecanismo de Sincronización de tiempo.
El producto es capaz de ajustar el reloj automáticamente basado en información

recibida desde uno o más servidores de tiempo en la red. La utilización de tiempo
de sincronización es altamente recomendada, ya que esto asegura que el producto
tendrá su fecha y hora alineada con otros productos en la red, o incluso con los
servidores de tiempo públicos entregando información de tiempo altamente certera
basada en relojes atómicos.
11.2.1 Protocolos de Sincronización de Tiempo

El producto soporta dos tipos de protocolos para ser utilizados en la
sincronización de tiempo:
• SNTP
– Definido por RFC 2030, The Simple Network Time Protocol (SNTP)
es una implementación ligera del Protocolo de Tiempo de Red (NTP)
descrito en RFC 1305.
• UDP/TIME
– El Protocolo de Tiempo (UDP/TIME) es un antiguo método para proveer un
servicio de sincronización de tiempo sobre el Internet. El protocolo entrega
un sitio independiente, fecha y tiempo legible por máquina. El servicio de tiempo
envía de vuelta a la fuente original el tiempo en segundos desde la
media noche del primero de enero de 1900.
Los servidores de tiempo más actuales utilizan en protocolo NTP.
11.2.2 Servidores de Tiempo

Se pueden configurar por sobre tres servidores de tiempo para preguntar por
información de tiempo. El utilizar más de un servidor, puede prevenir que situaciones
en donde un servidor inalcanzable cause que el proceso de sincronización de tiempo
fracase. Nótese que el producto siempre cuestiona todos los servidores de tiempo
configurados con el fin de calcular un promedio basado en respuestas de todos los
servidores. Motores de búsqueda en el internet pueden ser utilizados para encontrar listas
actualizadas de servidores de tiempo públicos disponibles.

11.2. Sincronización de Tiempo 99
11.2.3 Modificación Máxima

Para evitar situaciones donde un servidor de tiempo defectuoso causa que el producto
actualice su reloj con datos altamente erróneos de tiempo, se puede especificar un valor
de modificación máxima (en Segundos). Si la diferencia entre el tiempo vigente en el
producto y el tiempo recibido desde un servidor de tiempo es mayor que el valor de
modificación máxima, esa respuesta del servidor de tiempo será desechada.
Por ejemplo, se asume que el valor de modificación máxima es ajustado a 60
segundos, y que el tiempo vigente en el producto es 16:42:35. Si un servidor de
tiempo responde con el tiempo de 16:43:38, la diferencia es de 63 segundos,
lo cual no es aceptable de acuerdo a la modificación máxima. De este modo, no
se realizará ninguna actualización con esa respuesta. El valor predeterminado de
modificación máxima es 36,000 segundos.
11.2.4 Intervalo de Sincronización

El intervalo entre cada intento de sincronización puede ser ajustado si es necesario.
Por defecto, este valor es de 86,400 segundos (1 día), significando que el tiempo de
proceso de sincronización es ejecutado una vez al día.
Ejemplo: Habilitando el Tiempo de Sincronización utilizando SNTP
En este ejemplo, el tiempo de sincronización es ajustado utilizando el protocolo

SNTP y utilizando servidores NTP instalados en el laboratorio Sueco nacional
por tiempo y frecuencia.
WebUI
:

Automatic time synchronization
Marque Enable time synchronization.

Seleccione lo siguiente de las listas desplegables:
Time Server Type: SNTP
Primary Time Server: dns:ntp1.sp.se
Secondary Time Server: dns:ntp2.sp.se
Tertiary Time Server: (None)

100 Capítulo 11. Fecha & Tiempo
Nota
Este ejemplo utiliza nombre de dominio en vez de direcciones IP. Por lo tanto,
asegúrese de que los ajustes de cliente DNS del sistema se encuentran apropiadamente
configurados como se describe en 12 DNS.

CAPITULO 12
DNS
Domain Name System (DNS) puede ser considerado como una gran base de datos
distribuida que es utilizada para traducir desde nombres computacionales a sus
direcciones IP.
DNS es utilizado dentro del firewall siempre que sea necesario traducir un
nombre de dominio a una dirección IP. Además, el servidor DHCP dentro del firewall
puede distribuir los servidores DNS configurados en el firewall a todos los clientes que
soliciten un contrato IP. El ejemplo a continuación describe cómo configurar servidores
DNS en los firewalls D-Link. Los servidores configurados son utilizados por los clientes
DNS internos así como otros subsistemas tales como el servidor DHCP.
Ejemplo: Configurando servidor(es) DNS
WebUI
:
System → DNS:
Primary Server: Ingrese la dirección IP del servidor DNS primario o seleccione
la dirección objetiva desde la lista desplegable (si la dirección del servidor ha sido
definida en el Libro de Direcciones).
Secondary Server: (Optional)
Tertiary Server: (Optional)
101
CAPITULO 13
Ajustes de Registro
En la parte de Administración, se han introducido los conceptos generales del

registro y diseño de los firewalls D-Link para poder con los eventos significativos
(refiérase a 5, Registro).En este capítulo, se presentarán algunos ejemplos de
configuración para habilitar las funciones de registro.
A excepción de algunos eventos de registro predeterminados que serán generados

automáticamente, por ejemplo, el arranque del firewall y cierre, el registro necesita
ser habilitado manualmente en secciones específicas de la configuración del
firewall.
Para ajustar el registro en los firewalls D-Link, se requieren de los siguientes dos pasos:
1. Definir uno o varios destinatarios de registro.
2. Habilitar las funciones de registro en ciertas secciones.
13.1 Implementación
13.1.1 Definiendo Receptor Syslog
Como se ha explicado en la sección 5.2.1, Los receptores Syslog son administradores
externos de registro utilizados para recibir y almacenar datos de registro generados por
el firewall. Los datos de registro son enviados al receptor(es) Syslog a través de mensajes,
que son definidos por Facility and Severity.
Facility define cómo son enviados los mensajes a un receptor Syslog especificando
identificadores de fuente en los mensajes. El receptor puede típicamente clasificar
mensajes
103
104 Capítulo 13. Ajustes de Registro
desde diferentes fuentes basadas en el identificador. El alcance válido es 0 a 7,

representando facilidades Syslog de ”local0” a ”local7”.
Severity es el grado de emergencia adjunto al mensaje de evento registrado por

eliminación de fallos. Los firewalls D-Link pueden ser ajustados para enviar mensajes
a diferentes niveles de intensidad. Clasificados desde una mayor importancia a una
menor; estos niveles son: Emergency, Alert, Critical, Error, Warning, Notice, Info,
and Debug.
Ejemplo: Definiendo un receptor de Syslog
Para definir un receptor Syslog en el firewall, siga los pasos a continuación:
WebUI
:
System → Log and Event Receivers → Add → Syslog Receiver:

General
Name: Ingrese un nombre para el receptor.
IP Address: Seleccione la dirección objetiva desde la lista desplegable (si la dirección
del receptor ha sido definido en el Libro de Direcciones), o ingrese la dirección IP
directamente en el recuadro de editar.
Facility: Elija una de las facilidades desde la lista desplegable.
Port: 514 (por defecto)
13.1.2 Habilitando Registro

Luego de ajustar uno o más receptores, el registro necesita ser habilitado para
funcionar. En WebUI, todos los ítems de configuración que pueden generar eventos
de registro poseen una página llamada Log Settings en su ventana de propiedades.
Esta página contiene opciones para habilitar registro, y para especificar ciertos receptores
de registro e intensidad para el evento.
Ejemplo: Habilitando Syslog
En este ejemplo, se asume que una regla IP ha sido definida previamente, y ha

sido habilitado el registro en esta regla para monitorear esta acción al
tráfico.

13.1. Implementación 105
WebUI
:
Rules → IP Rules: Click the IP rule item → Log Settings:

General
Marque Enable logging
Severity: Elija uno de los niveles de intensidad desde la lista desplegable.
Log Receivers
Log to: Marque tanto All receivers o Specific receiver(s)
(Si es marcado Specific receiver(s), seleccione el receptor Syslog que ha sido definido
previamente desde Available list a Selected list.)
Ejemplo: Habilitando Memoria de Registro
El receptor de registro construído en memoria del firewall puede ser habilitado de una
manera similar a la explicada en el Ejemplo: Habilitando Syslog.
Para marcar los contenidos de archivo de registro almacenados por la memoria del
receptor de registro, siga los pasos a continuación:
WebUI
:
Menu Bar: Status → Logging:
Pueden ser desplegados 100 ítems de eventos nuevamente generados por página.
Para ver eventos previos, presione next.

Parte VI
Políticas de Seguridad
Las políticas de seguridad regulan las formas en que las aplicaciones
de red protegen del abuso y uso inapropiado. Los firewalls D-Link
ofrecen varios mecanismos para ayudar a los administradores
en la construcción de políticas de seguridad para la prevención
de ataques, protección de privacidad, identificación, y control de
acceso.
• Reglas IP
• Acceso (Anti-spoofing)
• DMZ & Port Forwarding
• Autentificación de Usuario
CAPITULO 14
Reglas IP
14.1 Vista General

La lista de reglas definidas en base a redes objetivas – direcciones,
protocolos, servicios – es el corazón de cualquier firewall. Las reglas determinan las
funciones de filtro básico del firewall, lo cual es esencial. Seguido a las reglas de
configuración, el firewall regula qué es permitido o rechazado para pasar a través,
y cómo la traducción de dirección, administración de amplitud de banda, y determinación
de tráfico, es aplicada al flujo de tráfico. Cualquier regla ambigua o defectuosa puede
perder el control de seguridad o hacer inútil al firewall.
Básicamente, hay dos posturas del firewall que describen una filosofía fundamental
de seguridad:
The default deny stance:

√
Todo es denegado a menos que sea específicamente permitido.
The default permit stance:

Todo es permitido a menos que sea específicamente denegado.
Con el fin de entregar el mayor nivel de seguridad posible, default deny es la política
predeterminada en los firewalls D-Link. El default deny es logrado sin una regla
visible en la lista. Sin embargo, para propósitos de registro, la lista de regla
comúnmente tiene una regla DropAll al pie con el registro habilitado.
Cuando una nueva conexión es establecida a través del firewall, la lista de reglas son
evaluadas, de arriba a abajo, hasta que se encuentre una regla que coincide con la
nueva conexión. La acción de la regla es entonces llevada a cabo. Si la acción es
109
110 Capitulo14. Reglas IP
Allow, la conexión será establecida y un estado representante de la conexión es

añadido a la tabla de estado interna del firewall. Si la acción es Drop, la nueva
conexión será rechazada.
Primer principio de coincidencia – Si hay varias reglas coincidentes, la primera
coincidente decide qué pasará con la conexión. (A excepción de las reglas SAT,
mostradas en el Ejemplo.)
Los paquetes consecutivos pertenecientes a una conexión existente no necesitan ser

evaluados nuevamente. En cambio, un algoritmo de búsqueda de estado altamente
optimizada buscará la tabla de estado interno para un estado ya existente
Representante de la conexión. Esta metodología es aplicada no sólo en las conexiones
TCP, sino también en UDP y tráfico ICMP. De este modo, el tamaño del ajuste de reglas
del firewall no afectará el rendimiento del firewall.
Una regla es expresada en una forma definitiva, consistente en dos partes lógicas: los
campos y la acción. Las sub-secciones a continuación explican los parámetros de una
regla que está disponibles en los firewalls D-Link.
14.1.1 Campos
Los campos son algunos objetos de red predefinidos y reutilizables, tales como
direcciones y servicios, los cuales son utilizados en cada regla con propósitos de
coincidencia. Los siguientes campos en la lista de regla son utilizados por el firewall para
verificar un paquete en el flujo de tráfico. Todos estos campos de filtro deben coincidir
los contenidos de un paquete para que cualquier regla se desencadene.
◦ Servicio: el tipo de protocolo que el paquete debe coincidir.

(Los Servicios son definidos como objetos lógicos antes de configurar las reglas,
vea 8.2 Servicios )
◦ Interfaz de Fuente: uno o un grupo de interfaces donde un paquete es recibido en

el firewall.
◦ Red de Fuente: la red a la que coincide la dirección IP de fuente del paquete.
◦ Interfaz de Destino: uno o un grupo de interfaces hacia donde el paquete es

dirigido.
◦ Red de Destino: la red a la que coincide la dirección IP de destino de los

paquetes.

14.1. Vista General 111
14.1.2 Tipos de Acción

Cuando todos los campos enlistados en la sección anterior son coincididos por un
paquete, una regla es desencadenada, una cierta acción especificada por la regla
coincidente será llevada a cabo. Los tipos de acción incluyen:
◦ Allow:
Deja a los paquetes pasar a través del firewall. El firewall ajustará además un
’state’ para recordar la conexión, y pasará el resto de los paquetes en esta conexión
a través de su motor de inspección dinámica.
◦ NAT:
Trabaja como las reglas Allow, pero con una traducción de dirección dinámica
habilitada. (Ver 14.2.2 NAT)
◦ FwdFast:
Deja al paquete pasar a través del firewall sin ajustar un estado para éste.
Generalmente hablando, es más rápido para un paquete individual, pero es
menos seguro que una regla Allow o NAT, y además más lento que reglas Allow
para la completa conexión establecida, como cada paquete subsecuente también
necesita ser verificado contra la sección de regla.
◦ SAT:
Le indica al firewall que ejecute la traducción de dirección estática. (Ver 14.2.3
Traducción de Dirección Estática) Esta regla requiere además una regla coincidente
Allow,NAT o FwdFast más abajo. (Ver Ejemplo)
◦ Drop:
Le indica al firewall que deseche inmediatamente el paquete.
◦ Reject:
Actúa como Drop, pero devuelve un mensaje TCP–RST o ICMP–Unreachable,
indicándole al remitente que el paquete ha sido deshabilitado.

14.2 Traducción de Dirección

14.2.1 Vista General
Por consideraciones de funcionalidad y seguridad, la traducción de Direcciones
de red(NAT) es generalmente aplicada para el actual uso en oficina y hogar. Los
firewalls D-Link entregan soporte tanto para NAT Dinámico como para Estático. Estos
dos tipos son representados por las reglas de ajuste NAT y SAT respectivamente.
Esta sección explica cómo trabaja NAT y qué es lo que puede y no puede hacer.
14.2.2 NAT
¿Qué es NAT?
Cuando se comunica con el Internet, cada nodo necesita registrar una dirección de
Red única para ser alcanzable. Pero las únicas direcciones disponibles del
Rango de IPv4 son muy limitadas mientras actualmente las redes se vuelven más y más
grandes. La traducción de dirección de Red (NAT) habilita a los computadores en
redes privadas para utilizar un grupo de direcciones no registradas internamente, y
comparte uno o un grupo de direcciones públicas IP para conexiones externas a
recursos Internet. Normalmente un router o un firewall localizado donde el LAN
encuentra el Internet hace todo lo necesario para las traducciones de
direcciones IP.
Para cada red NATed, los espacios de dirección IP privada (10.0.0.0/8,
172.16.0.0/12, 192.168.0.0/16) son reutilizadas. Esto significa que interfaces
múltiples conectadas a diferentes redes pueden tener la misma dirección, mitigando
la presión de tener que utilizar direcciones públicas IPv4 para cada nodo.
¿Por qué NAT es generalmente utilizado?
En adición a la resolución del problema de escasez IP, NAT es desarrollado para

atender muchos otros propósitos:
• Funcionalidad – Utilizando NAT, no hay necesidad de registrar una dirección IP para
cada computador en una red local. Una compañía puede utilizar muchas
direcciones IP internas y una IP pública registrada para entregar servicios
internet. Ya que esta dirección es utilizada solo de manera interna, no hay
posibilidad de colisión de direcciones con otras compañías. Esto permite a una
compañía combinar conexiones de acceso múltiple a una sola conexión Internet.
• Seguridad – Los computadores localizados en la red local y que utilizan un rango

de direcciones privadas no son directamente accesibles desde el Internet. Para

14.2. Traducción de Dirección 113
el mundo externo, toda la red privada es como un nodo que utiliza una dirección
IP pública, y la estructura interior y direcciones de la red se encuentran ocultas.
NAT depende de una máquina en la red local para iniciar cualquier conexión a
anfitriones del otro lado del firewall ó del router, esto previene actividades
malintencionadas iniciadas por anfitriones externos para alcanzar a estos
anfitriones locales. NAT-habilita firewalls, por ejemplo, los firewalls D-Link,
manejan todo el trabajo de traducción y redireccionamiento para pasar el tráfico
y pueden entregar caminos para restringir acceso a Internet al mismo tiempo.
• Flexibilidad de administración – NAT puede ser utilizado para dividir una gran
Red en varias más pequeñas. Las partes más pequeñas exponen sólo una
dirección IP al exterior, lo cual significa que los computadores pueden ser añadidos
o removidos sin causar impacto en las redes externas. Los firewalls D-Link
contienen servidor DHCP, el cual permite a los clientes ser configurados
automáticamente. El administrador no necesita aplicar ningún cambio a cada
computador en la red interna, por ejemplo, si la dirección de servidor DNS es
modificada, todos los clientes comenzarán automáticamente a utilizar la nueva
dirección la siguiente vez que se contacte con el servidor DHCP.
Cómo trabaja NAT
En la red de comunicación TCP/IP, cada paquete IP contiene un encabezado con las

direcciones de fuente y destino y los números prot (Dirección de fuente: puerto de
fuente — Dirección de Destino: puerto de destino). Esta combinación definirá por
completo una sola conexión. Las direcciones especifican los dos computadores finales
del vínculo, y los dos números de puerto garantizando que cada conexión
perteneciente a ciertos servicios es únicamente identificado. Cada conexión
es originada desde un número único de puerto de fuente en un extremo, y todos los
paquetes respondidos desde el otro extremo contienen el mismo número que su
puerto de destino, de modo que el iniciador puede referirlos de vuelta a su conexión
correcta.
Un firewall NAT-habilitado debe modificar la dirección de fuente en cada paquete saliente

para que sea su dirección pública. Este por lo tanto re-enumera además el puerto de
número de fuente para ser único, de modo que este pueda mantener el rastro de cada conexión.
El firewall utiliza una tabla de mapeo para relacionar la dirección local real y puerto de
fuente más su número de puerto de fuente traducida a una dirección de destino y
puerto. Cuando éste recibe cualquier paquete de retorno, este puede por lo tanto
revertir la traducción para dirigirlos de vuelta a los clientes correctos.
Porque las tablas de mapeo relatan una completa información de conexión -

114 Capítulo 14. Reglas IP
Dirección de fuente y destino y números de puerto – es posible validar

alguna o toda esta información antes de pasar el tráfico. Estas verificaciones ayudan
al firewall a proteger un LAN privado contra ataques desde el exterior.
El mecanismo NAT se deshace de todo el trafico que no coincide en el entry de tabla

De mapeo, por lo tanto es considerado además como un dispositivo de seguridad. Sin
embargo NAT no es un sustituto para las reglas firewall. Hay puertos abiertos TCP y
UDP correspondientes a las aplicaciones y servicios que corren en el NAT. Si el dispositivo
NAT es un computador, más que un firewall dedicado, el computador se vuelve entonces
vulnerable a ataque. Por lo tanto, la recomendación es utilizar un firewall habilitado-NAT
con reglas de ajuste especificadas para el tráfico.
14.2.3 Traducción de dirección en los Firewalls D-Link

Los firewalls D-Link soportan dos tipos de traducción de dirección: dinámico (NAT
oculto), y estático (SAT).
Traducción de Dirección de Red Dinámica
El proceso de traducción de dirección dinámica involucra la traducción de direcciones

de remitente múltiples en una o más direcciones de remitente, tal como direcciones IP
privadas son mapeadas para un grupo de direcciones IP públicas.
Ejemplo: NAT Dinámico
Sender Server
192.168.1.5 : 1038 → 195.55.66.77 : 80
FW tran 195.11.22.33: 32789 195.55.66.77 : 80
reply 195.11.22.33: 32789 195.55.66.77 : 80
FW rest 192.168.1.5 : 1038 ← 195.55.66.77 : 80
Tabla 14.1: NAT Dinámico.
La Tabla 14.1 muestra un ejemplo de NAT dinámico, El remitente, ej. 192.168.1.5,

envía paquetes desde un puerto dinámicamente asignado, por ejemplo, puerto 1038, a
un servidor, ej. 195.55.66.77 puerto 80.
Usualmente, el firewall traduce la dirección del remitente a la dirección de interfaz más

cercana a la dirección de destino. En este ejemplo, utilizamos 195.11.22.33 como la
Dirección pública. En adición, el firewall modifica el puerto de fuente a un puerto libre,

14.2. Traducción de Dirección 115
usualmente es utilizado uno sobre 32768, 32789. El paquete es luego enviado a su

destino.
El servidor del destinatario considera la dirección NATed del firewall como el origen
del paquete, procesa el paquete y envía su respuesta de vuelta a la dirección
NATed.
El firewall recibe el paquete y lo compara con su lista de conexiones abiertas. Una vez
que encuentra la conexión en cuestión, éste restaura la dirección original y
reenvía el paquete al remitente real.
Traducción de Dirección Estática (SAT)
SAT es un tipo de traducción de dirección en la cual una dirección IP pública es

mapeada estáticamente para una dirección IP privada. El NAT Dinámico es normalmente
utilizado para el tráfico saliente, mientras SAT es utilizado para el tráfico entrante. Por
ejemplo, el utilizar SAT permite un anfitrión interno, tal como un servidor Web, para tener
una dirección IP (privada) no registrada y aún así será alcanzable sobre el Internet.
La dirección IP privada del servidor es mapeada a una dirección IP estática pública, la
cual puede ser vista desde el Internet.
En los firewalls D-Link, SAT es implementado para entregar muchas funciones importantes,
Por ejemplo:
- DMZ & Port Forwarding: SAT soporta el uso de red DMZ para entregar servicios
públicos al Internet, mientras tanto protegiendo la red privada de una
revelación innecesaria para el mundo externo.
(ver 16, DMZ & Reenvío de Puerto)
- Server Load Balancing: SAT puede re-direccionar las conexiones señaladas como
algún servidor para alternar servidores seleccionados. (ver 24, Balance de Carga
de Servidor)

14.3 Escenarios: Configuración de Reglas IP

Esta sección le muestra ejemplos de configuración de reglas IP, incluyendo:
• Regla NAT
• Regla SAT
– Publica un Servidor accesible con una Dirección Privada en un DMZ
Otras características de ajuste cooperadoras con NAT pueden ser encontradas en

16, DMZ & Port Forwarding, y 24, Server Load Balancing.
Ejemplo: Habilitando Ping en la dirección IP externa del firewall
En este ejemplo, se configura una regla IP para permitir paquetes ICMP (Ping) para ser
recibidos por la interfaz externa del firewall.
1. Define un servicio ICMP objetivo y lo denomina ”ping-inbound”. (Note

que el Firewall D-Link es repartido con un servicio ”ping-inbound” configurado
como predeterminado el cual puede ser utilizado)
2. Crea una Regla nueva con nombre ”Ping to Ext”, y permite el servicio desde
cualquier interfaz en todas las nets para la interfaz central del firewall en la red
ip ext .
WebUI
:
1. Crear un Servicio Ping-Entrante
Si no es definido un servicio ping-entrante, necesitamos crear un nuevo servicio.
Objects → Services → Add → ICMP Service:

Name: ping-inbound
ICMP Parameters
ICMP Message Types: Echo Request (Codes 0-255)

14.3. Escenarios: Configuración de Reglas IP. 117
2. Crear Regla
El paso final es crear la regla que permitirá paquetes ICMP(Ping) ser recibidos
por la interfaz externa del firewall.
Rules → IP Rules → Add → IP Rule:
Name: Ping to Ext
Action: Allow
Service: ping-inbound
Source Interface: any
Source Network: all-nets
Destination Interface: core
Destination Network: ip ext
Ejemplo: Regla NAT
En este caso, se ajusta una regla NAT en el firewall que permitirá buscar el Internet
desde direcciones IP privadas detrás del firewall. Las direcciones IP privadas serán
traducidas a la dirección IP externa del firewall.
1. Agregar un servicio objetivo ”HTTP” que utiliza puerto 80 TCP.
2. Agregar un servicio objetivo ”DNS” que utilizará puerto 53 TCP/UDP para habilitar
el nombre de servicio determinado.
3. Crear dos reglas que apliquen NAT a los servicios anteriores desde la interfaz interna en
La red interna para cualquier interfaz de destino en cualquier red.
WebUI
:
1. Crear Servicio HTTP

Si ningún servicio http es definido, se necesita crear un nuevo servicio.
Objects → Services → Add → TCP/UDP Service:
Name: http
Type: TCP
Source: 0-65535
Destination: 80

118 Capitulo 14. Reglas IP
2. Crear un DNS Todo Servicio
Si no hay un dns-todo servicio definido, se necesita crear un nuevo servicio.

Name: dns-all
Type: TCPUDP
Source: 0-65535
Destination: 53
3. Crear una Regla HTTP
El siguiente paso es crear la regla que llevará el tráfico NAT HTTP desde interfaces
Internas por sobre interfaces externas.
Name: HTTP from LAN
Action: NAT
Service: http
Source Interface: LAN
Source Network: lan-net
Destination Interface: any
Destination Network: all-nets
4. Crear una Regla DNS
El paso final es crear la regla que NAT(eará) tráfico DNS desde interfaces internas
por sobre interfaces externas.
Name: DNS from LAN
Action: NAT
Service: dns-all

14.3. Escenarios: Configuración de Reglas IP. 119
Nota
Para reglas NAT es posible especificar la dirección IP que deben traducir las
direcciones IP internas. Esto puede ser realizado en la etiqueta ”NAT” cuando se
configure la regla. Por defecto, la dirección de la interfaz de destino es utilizada.
Ejemplo: Regla SAT
Servidor Públicamente Accesible con una Dirección Privada en un DMZ.
Figura 14.1: Ejemplo SAT.
Este ejemplo ofrece un servidor web con una dirección privada localizada en un
DMZ, y máquinas internas localizadas en una red local que desean buscar el
Internet. Con el fin de habilitar usuarios externos para acceder al servidor web, el
servidor debe ser alcanzable desde una dirección pública. De este modo, se traslada el
puerto 80 en la dirección externa del firewall al puerto 80 en el servidor web:
1. Añadir un servicio ”HTTP” objetivo que utilice el puerto 80 TCP.

2. Regla 1: Crear una nueva regla que SAT el tráfico HTTP direccionado a la
dirección pública IP externa ip ext, a la dirección IP privada del servidor web.
∗ Regla 2: Crear una regla NAT que permita el tráfico SAT:ed por la regla
anterior.
∗ Regla 3: Crear una regla NAT que permita a las máquinas internas en la red local
acceder el Internet vía HTTP.
WebUI
:
1. Crear un Servicio HTTP
Si no hay un servicio http definido, se necesita crear un nuevo servicio.

Name: http
Type: TCP
Source: 0-65535
Destination: 80
2. Crear una Regla SAT HTTP
El siguiente paso es crear la regla que SAT(eará) el tráfico HTTP direccionado a la

IP pública externa ip ext, a la dirección IP privada del servidor web.

Name: SAT to WebServer
Action: SAT
Service: http
SAT
Translate the: Destination IP Address
To New IP Address: ip webserver

14.3. Escenarios: Configuración de Reglas IP 121
3. Crear una Regla SAT/NAT HTTP
El siguiente paso es crear una regla NAT que permita el tráfico SAT:ed por la regla
anterior.
Name: SATNAT to WebServer
Action: NAT
Service: http
4. Crear una Regla NAT HTTP
El paso final es crear una regla NAT que permita a las máquinas internas en la red
local para acceder al Internet vía HTTP.
Name: HTTP from LAN
Action: NAT
Service: http
Nota
SAT necesita una segunda regla

La regla SAT necesita una segunda regla alineada para pasar el tráfico a través
(mostrado como la regla ”Allow” anterior). La segunda regla puede ser un Allow,
FwdFast, o NAT, y esta segunda regla alineada debe ser ubicada bajo la regla
SAT iniciada.
La regla SAT iniciada no le hace nada a los datos actuales. Si hay una coincidencia
con el paquete recibido y una regla SAT, el firewall continuará pasando los paquetes

a través de la lista de regla hasta que una segunda regla coincida. Cuando
los paquetes abandonan la lista de regla, esta regla las redirecciona al
destino.
Problemas con la regla de ajuste vigente

Esta regla de ajuste hace las direcciones internas visible a los aparatos en el
DMZ (ver 16, DMZ & Por Forwarding). Cuando los aparatos internos se
conectan a la interfaz externa del firewall ip ext, estarán habilitados para
proceder por la Regla 2 sin NAT (el primer principio coincidente).
Desde la perspectiva de la seguridad, todos los aparatos en el DMZ que
entregan servicios públicos deben ser considerados como cualquier otro
Servidore Internet conectado a redes no confiables.
Soluciones Alternativas
1. Mantener la Regla 1 y revertir la secuencia de la Regla 2 y 3, de modo que

la regla NAT sea llevada a cabo para el tráfico interno antes de que la
regla Allow coincida.
2. Mantener la Regla 1 y 3, modificar la Regla 2 de modo que sólo se aplique al
tráfico externo (el tráfico más probable desde la interfaz WAN) – una regla
”Allow” para permitir la Regla 1 desde conexiones externas (la interfaz WAN
más probable) en todas las nets para la dirección pública externa del firewall
ip ext.
Dato
La determinación del mejor curso de acción y el orden secuencial de las reglas

debe ser realizada en base a caso a caso, tomando todas las circunstancias en cuenta.

CAPITULO 15
Acceso (Anti-spoofing)
15.1 Vista General

La función primaria de cualquier firewall es controlar el acceso a recursos de datos
protegidos, de modo que la única conexión autorizada sea permitida. El control de
acceso es básicamente direccionado en las reglas IP del firewall (introducidas en 14. Reglas
IP). De acuerdo a las reglas, el firewall considera un rango de direcciones LAN
protegidas como anfitriones confiables, y restringe el tráfico que fluye desde el
Internet no confiable en dirección al área confiable, y además el otro camino
cercano.
Un error esencial de este control basado en confianza es que, tiende a descuidar el

potencial peligro causado por la mascarada. Un atacante inteligente realiza trucos
para engañar al firewall pretendiendo la identidad de un anfitrión confiable, lo cual es
la llamada técnica Spoofing.
15.1.1 IP Spoofing
El spoofing IP es uno de los ataques enmascarados más comunes, en donde el
atacante utiliza direcciones IP de confianza del firewall para evitar el filtro de
tráfico. En el proceso de spoofing, el encabezado de un IP indicador de la dirección de
fuente de un paquete entregado puede ser fácilmente modificado a una dirección de
anfitrión local, de modo que el firewall confiará en la solicitud proveniente de una
fuente confiable. Aunque el paquete no pueda ser respondido por la fuente inicial,
hay una posibilidad de congestión de red innecesaria y ataques de negación de
123
124 Capítulo 15. Acceso (Anti-spoofing)
Servicios (DoS). Incluso si el firewall está capacitado para detectar los ataques DoS, es
difícil localizarlos o detenerlos debido al spoofing.
15.1.2 Anti-spoofing
Para equipar el firewall con la habilidad Anti-spoofing, se necesita un filtro extra contra
la verificación de dirección de fuente. Los firewalls D-Link entregan al administrador
de red elecciones a para hacer el filtrado basado en IP por Reglas de Acceso.
Otra característica entregada por los firewalls D-Link, tal como Autentificación de Usuario
y Encriptación, aseguran que exista una apropiada medida de autentificación
y la comunicación sea llevada a cabo sobre canales seguros, los cuales pueden además
reducir la amenaza de spoofing.(Ver 17 Autentificación del Usuario, VIII VPN)
15.2 Reglas de Acceso

15.2.1 Función
La regla de Acceso es capaz de monitorear el tráfico para verificar que los paquetes
que llegan a una interfaz del firewall no tienen una dirección de fuente que pueda ser
asociada con la red de otra interfaz. En otras palabras, el principio de las reglas
puede ser descrito de la siguiente manera:
• Cualquier tráfico entrante con una dirección de fuente IP perteneciente a un
anfitrión local confiable NO es permitido.
• Cualquier tráfico saliente con una dirección de fuente IP perteneciente a una

red exterior no confiable NO es permitido.
El primero previene que un intruso utilice la dirección de anfitrión local como dirección
de fuente, y el segundo previene que cualquier anfitrión local lance el spoofing.
El ajuste de regla de Acceso actúa como un filtro complementario a la lista de reglas

del firewall, y asegura que las direcciones de fuente de paquetes recibidos en una
Interfaz específica estén siempre dentro de la red correcta, procurando que la regla
de Acceso sea correctamente configurada. Si la sección de búsqueda de Acceso no
tiene éxito, el firewall ejecutará una búsqueda inversa en su tabla routing.
15.2.2 Ajustes
La configuración de una regla de acceso es similar a las reglas normales,
contenedoras de los Campos de Filtro y la Acción a tomar. Si el tráfico coincide todos

15.2. Regla de Acceso 125
Los campos, la regla es desencadenada, y la acción especificada será llevada a cabo

por el firewall.
Campos de Filtro
◦ Interfaz:
La interfaz a la cual llega el paquete.
◦ Red:
El span IP al cual debe pertenecer la dirección del remitente.
Acción
◦ Drop:
Descarta los paquetes que coinciden con los campos definidos.
◦ Aceptar:
Acepta los paquetes que coinciden con los campos definidos para una
mayor inspección en los ajustes de Regla.
◦ Expect:
Si la dirección del remitente del paquete coincide la Red especificada por esta
regla, la interfaz receptora es comparada con la interfaz específica.
Si la interfaz coincide, el paquete es aceptado de la misma manera que por la acción
de Accept. Si la interfaz no coincide, el paquete es desechado de la misma
manera que la acción de Drop.
El Registro puede ser habilitado en demanda para estas Acciones.

(Refiérase a 5 Registro)

126 Capítulo 15. Acceso (Anti-spoofing)
15.3 Escenario: Ajustando la Regla de Acceso
Ejemplo: Permitiendo el Tráfico desde una Red Específica
Este ejemplo mostrará cómo asegurar que el tráfico recibido en la interfaz LAN siempre
posea la dirección de fuente correcta, dentro de la red lan-net.
WebUI
:
1. Crear Regla de Acceso
La siguiente regla asegurará que ningún tráfico con una dirección de fuente que no
esté dentro de la red lan-net será recibida en la interfaz LAN.
Rules → Access → Add → Access Rule:
Name: LAN Access
Action: Expect
Interface: LAN
Network: lan-net

CAPITULO 16
DMZ & Port Forwarding
16.1 General
16.1.1 Conceptos
DMZ – ”Demilitarized Zone” – Se mantiene para un área que no es parte de una red
Interna confiable ni es parte directa de Internet público.
Típicamente, DMZ es una subred distinta entre el firewall protegido, el LAN privado y
la red pública. Contiene uno o más computadores que son accesibles al tráfico
Internet y actúan como servidores proxy para servicios públicos, tal como
Web (HTTP), FTP, SMTP(Email), y servidores DNS.
En una configuración DMZ, los computadores (servidores) asentados fuera del LAN
Privado, responden a ó reenvían las solicitudes de servicio. El firewall es configurado
para prevenir a los computadores en el DMZ de solicitudes entrantes iniciales, y
reenvía el tráfico desde el Internet a computadores DMZ sin contacto directo con el
LAN interno. Obviamente, esta propuesta añade una capa extra de protección a la
infraestructura Intranet–firewall–Internet.
Los firewalls D-Link ofrecen soporte al planeamiento DMZ y protección a través de la

Interfaz de red objetiva y configuración de Reglas.
127
128 Capitulo16. DMZ & Port Forwarding
Ejemplo: Servidor Web de una corporación
Se observará un simple ejemplo, mostrando una utilización de DMZ con un

Firewall D-Link.
El servicio disponible públicamente más común que toda corporación necesita tener
es el buscador de Web(HTTP). Sin embargo, es inseguro ubicar un servidor Web
dentro de la red interna junto con otros computadores privados, debido a que tal
servidor puede fácilmente ser explotado de manera perjudicial por intrusos. Cuando
el servidor cae bajo control de manos erróneas, otros computadores privados se
volverán vulnerables a ataques. Por lo tanto, tal servicio debe ser localizado en un
área de red distinta – DMZ.
Figura 16.1: Un Servidor Web en DMZ
En este ejemplo, se observa un firewall D-Link conectando un LAN privado, una

subred DMZ, y el Internet, mostrado en la Figura 16.1. El firewall se encarga de:
a) Todas las conexiones desde el Internet al DMZ;
b) Conexiones necesarias desde el DMZ al LAN privado. El servidor Web es ubicado
en el DMZ. Las solicitudes al servicio de buscador Web van a través del firewall,
y son reenviadas al servidor Web.
Se pueden definir Reglas que permitan al servidor en el DMZ aceptar sólo cierto tipo
de Solicitudes de servicio, las solicitudes basadas en HTTP en este caso, para proteger

16.1. General 129
el servidor. Por ejemplo, suponiendo que nuestro servidor web está corriendo en NT eso
podría ser vulnerable a un número de ataques de negación-de-servicio contra servicios
tales como RPC, NetBIOS y SMB. Estos servicios no son requeridos para la
operación de HTTP. De modo que se pueden ajustar reglas para bloquear conexiones
TCP relevantes para puertos 135, 137, 138, y 139 en ese servidor para reducir la
exposición a ataques de negación-de-servicio.
Resumen:
Esta solución significa que, con un despliegue DMZ, no hay acceso directo desde el
Internet a la red interna, y nadie tratando de acceder a recursos en DMZ desde el
Internet podrá pasar las reglas del firewall.
Los ajustes de las reglas del firewall siguen un principio importante de seguridad,
esto es, limitar las conexiones a un número mínimo necesario para soportar los
servicios.
16.1.2 Planificación DMZ

La utilización de DMZ es un trabajo a gran escala, involucrando la segmentación de la
estructura de red y las configuraciones de regla del firewall. Por lo tanto, este requiere
un planeamiento cuidadoso para conseguir los propósitos de protección y
escalabilidad.
Se utiliza un pequeño grupo de componentes para ilustrar las diferentes propuestas del
planeamiento DMZ:
• Un firewall D-Link con 3 interfaces: Int net, DMZ net, y Ext net
• Un computador privado: Cliente A
• Un Archivo de Servidor contenedor de los datos de LAN privado
• Un Servidor de Base de datos conteniendo recursos para servicios públicos de

web.
• Un Servidor Web para conexiones públicas.
Propuesta 1 – Archivo de Servidor, Servidor de Base de datos, un Cliente A en Int net;

Servidor Web en DMZ net.
Desventaja: El servidor Web en net DMZ necesita abrir algunos puertos en

Int net para acceder al servidor de Base de datos. Si el Servidor Web asume el
cargo por intrusión, el Servidor de Base de datos y otros componentes en Int
Net pueden exponerse a ataques.

130 Capitulo16. DMZ & Port Forwarding
Propuesta 2 – Mover el Servidor de Base de datos fuera de la red DMZ.
Desventaja: Aunque todos los datos públicos accesibles están ahora en la red
DMZ, la protección al Servidor de Base de datos es debilitada. Si un hacker
toma control sobre el Servidor Web, él o ella puede ir directo a la Base de datos.
√
Propuesta 3 – Dividir DMZ en diferentes zonas.
Solución: La mejor propuesta para este escenario es dividir la net DMZ

en diferentes subredes de acuerdo a diferentes servicios y niveles de
seguridad de los componentes. Se coloca el Servidor de Base de datos y el
Servidor Web en interfaces separadas del firewall, y se configura las reglas de
acceso para cada interfaz. Si el hacker toma el control del Servidor Web,
él o ella aún tendrán acceso muy limitado al Servidor de Base de datos.
16.1.3 Beneficios
Como se ha ilustrado en la sección previa, el hacer buen uso de una red DMZ entrega
varias ventajas tanto en seguridad de red como en perspectivas de administración:
• Repartir servicios no sólo por anfitriones, sino que con los limites de red en
Nivel de confianza entre componentes de red. Esta propuesta puede reducir mucho
la probabilidad de penetración en un componente utilizado para interrumpir en los
otros.
• Dividir DMZ en diferentes zonas ayuda a restringir políticas de seguridad sobre

componentes que tienen diferentes funciones y niveles de seguridad.
• La escalabilidad de la arquitectura de red es incrementada ubicando

components en diferentes subredes.

CAPITULO 17
Autentificación del Usuario
17.1 Vista General de Autentificación

Antes de que cualquier solicitud de servicio de usuario sea autorizada de acuerdo a
las políticas de seguridad del firewall, éste necesita verificar la identidad del usuario,
para asegurar que el usuario corresponda es quien dice ser.
Autentificación es el proceso para direccionar tal asunto. Este forma un filtro al frente
del control de acceso del firewall, filtro de paquete, y túnel de seguridad.
En este capítulo, importa la validad del usuario, en términos de persona; los mismos
principios aplicados a los dispositivos en la red además.
17.1.1 Métodos de Autentificación

Generalmente, los procesos de autentificación provocan que el usuario muestre
su credencial con gran cuidado ya que este secreto no debe ser poseído por nadie más.
las soluciones y tecnologías de habilitación pueden ser categorizadas sobre las bases
de:
a) Algo que el usuario es

El único atributo del usuario es que son diferentes en cada persona –
características fisiológicas – tal como la huella digital, retina, o voz.
b) Algo que el usuario tiene

La clave ”tool” que un usuario posee, tal como un Certificado Digital, una
tarjeta, o Claves Públicas & Privadas.
131
132 Capítulo 17. Autentificación del Usuario
c) Algo que el usuario conoce

La información secreta que sólo el usuario involucrado conoce y mantiene,
tal como la Contraseña más comúnmente utilizada ó una Frase secreta Compartida.
La dificultad de utilizar método a) es que requiere algunos dispositivos especiales para

escanear y leer la característica presentada, lo cual es relativamente caro.
Otro riesgo que puede causar que esto falle es que las características son casi imposible
de sustituir; en caso de que el usuario pierda la característica por accidente,
nada puede ser utilizado para reemplazarlo.
Por lo tanto, los métodos más comúnmente utilizados para servicios de red son (b)
y (c). Hay además riesgos potenciales utilizando cualquiera de estos dos métodos, por
ejemplo, las claves pueden ser interceptadas, la tarjeta puede ser robada, las personas
tienden a utilizar contraseñas débiles que son fáciles de adivinar, y pueden ser malos
para guardar cualquier secreto, etc. Por lo tanto, estas dos propuestas son a
menudo combinadas para tener añadidas unos niveles de seguridad y factores. Por
ejemplo una tarjeta es a menudo otorgada a una persona con una contraseña.
La autentificación de Usuario es frecuentemente utilizada en servicios, tales como HTTP,

y VPN. Los firewalls D-Link utilizan Nombre de Usuario/Contraseña como el método
primario de autentificación, fortalecido por algoritmos de encriptación. El
concepto básico de Encriptación es cubierto por 20.2 Introducción a Criptografía. Medios
más avanzados de seguridad y autentificación, tales como el Sistema de Clave Pública-
Privada, Certificado X.509, IPsec& IKE, IKE XAuth, y Lista ID es introducida en:
20.2.2 Autentificación & Integridad, and 22 Protocolos VPN & Túneles.
17.1.2 Criterio de Contraseña

En el acoplamiento Nombre de Usuario/Contraseña, el nombre de usuario(nombre
de cuenta), como un identificador indica de quien se trata, y los servidores de contraseña
como un autentificador para probar que esto es verdad. Para penetrar ciertos sistemas y
obtener los privilegios de usuario y administrador, la contraseña es a menudo
sujeta a ataques.
Ataques
Hay principalmente tres formas diferentes de atacar una contraseña:
• Adivinar:
Intente casos posibles. Las contraseñas que son elegidas desde un diccionario, ó
información personal del usuario, tal como nombre, número telefónico, y
fecha de cumpleaños son vulnerables a estos ataques.
• Descubrir:

17.1. Vista General de Autentificación 133
Encontrar las notas que recuerdan la contraseña, o preguntar al usuario

directamente. Mucha gente tiende a escribir las contraseñas en papeles, y
le pueden decir la contraseña a alguien de confianza, lo cual es
potencialmente un escape.
• Crack:
Búsqueda exhaustiva por algunos crackers de software. Contraseñas de corta
longitud o menos caracteres aleatorios son fácilmente fracturados.
Contramedidas
Para prevenir los ataques ”Guess” y ”Crack”, una BUENA contraseña debería ser:
• contener más de 8 caracteres sin repetición
• alternar caracteres las cuales no son frases comúnmente utilizadas
• contener caracteres pequeños y capitales
• contener números y caracteres especiales
Para el mantenimiento de contraseña, algunas pautas están disponibles como un

listado a continuación:
• la contraseña no debe ser documentada en ningún lado – en papel o en un
archivo de computación.
• jamás revele su contraseña a nadie
• las contraseñas deben ser regularmente modificadas para contrarrestar

cualquier compromiso no detectado.
• elegir las contraseñas que pueden ser digitadas rápidamente para prevenir que
alguien cercano observe.
Aunque las condiciones anteriores pueden parecer estrictas e inconvenientes, estas tienen
la intensión de asegurar tanto los derechos del usuario y propiedades, como el
sistema de red protegida. Una nueva selección de contraseña además ayuda en
proteger los túneles de Capa 2, los cuales aplican Encriptación en base a contraseñas
introducidas por usuario (Ver 22.2 PPTP/L2TP).
17.1.3 Tipos de Usuario

Los firewalls D-Link y proyectos de autentificación entregan soporte a diversos usuarios.
los tipos de usuario pueden ser:
• administradores

134 Capítulo 17. Autentificación del Usuario.
• usuarios normales accediendo a la red
• usuarios PPPoE/PPTP/L2TP
– utilizando métodos de autentificación PPP
• usuarios IPsec & IKE

– las entidades de autentificación durante las fases de negociación IKE
(Implementadas por Claves Pre-Compartidas o Certificados. Refiérase a 22.1.4
IKE integridad & Autentificación.)
• usuarios IKE XAuth

– extensión a la autentificación IKE, ocurrida entre la fase 1 y fase 2 de
negociación
• grupos de usuario
– grupo de usuarios que están sujetos al mismo criterio de regulación
17.2 Componentes de Autentificación

Los firewalls D-Link pueden ser utilizados tanto como una base de datos almacenada
localmente, o una base de datos en un servidor externo para entregar autentificación
de usuario.
17.2.1 Base de Datos de Usuario Local (UserDB)

La Base de Datos de Usuario Local es un registro construido dentro de los
Firewalls D-Link, contenedora de los perfiles de usuarios legales y grupos de usuario.
Los nombres de Usuario y contraseñas pueden ser configurados dentro de esta base de
datos, y los usuarios que poseen los mismos privilegios pueden ser agrupados para
facilitar la administración.
Un usuario puede ser almacenado como miembro de más de un grupo, cualquier
modificación a cada grupo se propagará a cada miembro del grupo. Las contraseñas son
almacenadas en la configuración usando criptografía reversible. Esto es con el fin de
ser compatible con varios métodos de autentificación cuestionamiento-respuesta tales
como CHAP, y así sucesivamente.
Cuando la base de datos local es habilitada, el firewall consulta sus perfiles de usuario
interno para autentificar al usuario antes de aprobar cualquier solicitud de usuario.
17.2.2 Servidor de Autentificación Externo

En una gran topología de red, es preferible tener una base de datos central dentro
de un servidor dedicado o un cluster de servidores para manejar toda la

17.2. Componentes de Autentificación 135
Información de autentificación. Cuando hay más de un firewall en la red y miles de

usuarios añadidos o removidos constantemente, el administrador no tendrá que
configurar y mantener base de datos separadas de perfiles de usuario autorizados en
cada firewall. En lugar de eso, el servidor externo puede validar el nombre de usuario/
Contraseña contra su base de datos central, lo cual es fácilmente administrado. Los
Firewalls D-Link soportan el uso de Servidor RADIUS (Remote Authentication
Dial-in User Service) para ofrecer el rasgo de autentificación externa.
RADIUS es actualmente el estándar más frecuente para autentificación remota.

Como el protocolo define, este utiliza PPP para transferir el mensaje nombre de
Usuario/contraseña entre clientes RADIUS y el servidor, y por lo tanto, aplica los mismos
planes de autentificación que PPP, tal como PAP y CHAP. Originalmente
desarrollado para acceso remoto dial-up, RADIUS es ahora soportado por VPN,
puntos de acceso inalámbrico, y otros tipos de acceso de red.
Un cliente RADIUS, ej. firewall D-Link, envía credenciales de usuario e

información de parámetro de conexión en la forma de mensaje RADIUS a un servidor
RADIUS. El servidor RADIUS mantiene todos los perfiles de usuarios y grupo de
usuario. Este autentifica y autoriza las solicitudes de clientes RADIUS, y envía de vuelta
un mensaje RADIUS de respuesta. Los mensajes de autentificación RADIUS son
enviados como mensajes UDP vía puerto 1812. Pueden ser definidos uno o
más servidores externos en el firewall para perfeccionar la disponibilidad del
sistema RADIUS.
Para entregar seguridad a los mensajes RADIUS, una común confidencialidad

compartida es Configurada tanto en el cliente Radius como en el servidor. La
confidencialidad compartida habilita la Encriptación básica de la contraseña del usuario
cuando es transmitido el mensaje RADIUS desde el cliente RADIUS al servidor, y es
comúnmente configurado como una sucesión de texto relativamente larga. Este
puede contener por sobre 100 caracteres y es sensible a minúscula y mayúscula.
17.2.3 Agentes de Autentificación

Pueden ser utilizados cuatro agentes construidos en el firewall para ejecutar
la autentificación nombre de usuario/contraseña. Estas son:
• HTTP
– Autentificación vía buscador web. Usuarios navegan en el firewall y se
registran tanto en forma HTML ó un diálogo de Autentificación Requerida 401.

• HTTPS
– Autentificación vía buscador web seguro. Similar al agente HTTP a excepción
de que los Certificados Host & Root son utilizados para establecer conexión SSL
con el firewall.
(refiérase a 22.3 SSL/TLS (HTTPS))
• XAUTH
– Autentificación durante negociación IKE en VPN IPsec (si el túnel IPSec
ha sido configurado para requerir autentificación XAUTH).
(refiérase a 22.1.4 IKE XAuth)
• PPP
– Autentificación cuando los túneles PPTP/L2TP son ajustados (si el túnel
PPTP/L2TP ha sido configurado para requerir autentificación del
usuario).
(refiérase a 9.4.1 PPP, y 22.2 PPTP/ L2TP)
17.2.4 Reglas de Autentificación

Una regla de autentificación de usuario especifica:
• Desde dónde (ej. interfaz receptora, fuente de red) los usuarios están habilitados
para autentificar al firewall;
• Cuál agente será utilizado por el firewall para provocar a los usuarios a
solicitar autentificación.
• Cuál es la localización de la base de datos a la que el firewall consulta para

desplegar la autentificación, tanto en un registro local como desde el
servidor externo;
• Diferentes restricciones de tiempo de desconexión para desconectar

automáticamente a los usuarios autentificados.
Nota
Cuando se utiliza un agente XAUTH, no hay necesidad de especificar la

Interfaz receptora, o fuente de red, como esta información no está disponible en la
fase XAUTH. Por la misma razón, sólo una regla de autentificación de usuario XAUTH
puede ser definido. XAUTH es sólo utilizado para ajustar túneles VPN IPsec.

17.3. Proceso de Autentificación 137
17.3 Proceso de Autentificación

Un firewall D-Link continúa con la autentificación del usuario de acuerdo a lo siguiente:
• Un usuario se conecta al firewall para iniciar la autentificación.
• El firewall recibe las solicitudes del usuario desde su interfaz, y registra en la regla de
ajuste IP que este tráfico es permitido para alcanzar su agente central de
autentificación.
• De acuerdo al agente de autentificación especificado en la regla de autentificación,

el firewall impulsa al usuario con la solicitud de autentificación.
• El usuario responde ingresando su información de autentificación –

Nombre de usuario/contraseña.
• El firewall valida la información w.r.t la fuente de autentificación especificada en la

regla de autentificación, serán tomadas tanto la base de datos local ó una base
de datos externa en un servidor RADIUS.
• Si es encontrada una entrada coincidente en la base de datos, el firewall responde

al usuario con un mensaje de aprobación, por otro lado de rechazo.
• Luego el firewall reenvía las futuras solicitudes de servicio del usuario aprobadas
a los destinos deseados, si el servicio es permitido por una regla IP explícitamente,
y el usuario es un miembro de el(los) grupo(s) de usuario(s) definidos en la
dirección objetiva de esa regla. Las solicitudes de aquellas fallas en los pasos
de autentificación son desechados.
• Luego de cierto periodo de tiempo, el usuario autentificado será automáticamente

desconectado de acuerdo a las restricciones de tiempo de conexión definidas en
la regla de autentificación.
17.4 Escenarios: Configuración de Autentificación

del Usuario
En esta sección, son cubiertas pauta y ejemplos para autentificación a través de agente
HTTP/HTTPS. Para más ejemplos sobre PPP y XAuth,
Por favor refiérase a 9.4.2, el Cliente de Configuración PPPoE, y 22, Protocolos VPN
& y Túneles, respectivamente.

Ejemplo: Configurando la base de datos de usuario local
En el ejemplo de dirección objetiva de autentificación en 8.1 Libro de Dirección,un grupo

de usuario ”users” es utilizado para habilitar la autentificación de usuario en ”lannet”.
Este ejemplo muestra cómo configurar un grupo de usuario en la base de datos
construída en el firewall.
WebUI :
1. User Authentication → Local User Databases → Add → Lo-

calUserDatabase:
General
Ingrese un nombre para el nuevo archivo de grupo de usuario ”lannet”:
Name: lannet auth users
Comments: folder for ”lannet” authentication user group – ”users”
2. lannet auth users → Add → User:

General
Username: Ingrese el nombre de cuenta de usuario aquí, e.j. ”user1”.
Password: Ingrese la contraseña del usuario.
Confirm Password: Repita la contraseña encima para evitar cualquier
equivocación de tipeo.
Groups: Un usuario puede ser especificado en más de un grupo. Ingrese los
nombres de grupo separados por coma, ej. ”users” para este ejemplo.
3. Repita el paso 2 para añadir todos los usuarios ”lannet” teniendo la membresía
del grupo ”users” en el archivo de usuario lannet auth.
Nota
Hay dos grupos predeterminados de usuario, el grupo administrador y el grupo
auditor. Los usuarios que son miembros del grupo administrador son permitidos para
cambiar la configuración del firewall, mientras los usuarios que pertenecen al grupo
auditores están sólo autorizados para ver la configuración del firewall. Presione los
botones bajo el recuadro de editar de los Grupos para garantizar la membresía de estos
grupos a un usuario.

17.4. Escenarios: Configuración de Autentificación del Usuario 139
Ejemplo: Configurando un servidor RADIUS
Un servidor de autentificación de usuario externo puede ser configurado siguiendo los

pasos a continuación:
WebUI
:
User Authentication → External User Databases→ Add → External

User Database:
General
Name: Ingrese un nombre para el servidor aquí.
Type: El único tipo soportado es comúnmente Radius.
IP Address: Ingrese la dirección IP del servidor, o ingrese el nombre simbólico si la
dirección del servidor ha sido previamente definida en el Libro de Direcciones.
Port: 1812 (el servicio RADIUS utiliza puerto registrado UDP 1812 por defecto.)
Retry Timeout: 2 (El firewall re-enviará solicitudes de autentificación al servidor si no
hay respuesta luego del tiempo de descanso, ej. cada 2 segundos. El firewall lo
reintentará tres veces como máximo.)
Shared Secret: Ingrese una serie de textos para la Encriptación básica de los
mensajes RADIUS.
Confirm Secret: Redigite la secuencia para confirmar lo tipeado anteriormente.
Y luego haga click en OK
Ejemplo: Habilitando autentificación HTTP vía base de datos de usuario

local.
Para habilitar la autentificación de usuario vía página Web, primero, necesitamos

añadir una regla Allow en las reglas IP del firewall para dejar que el firewall acepte el
buscador de Web del usuario a su agente HTTP(TCP puerto 80): segundo, se
especifica una regla de autentificación del usuario para decirle al firewall cómo ejecutar
la autentificación, tal como cuál base de datos elegir para la búsqueda de perfil del
usuario, y además las restricciones de tiempo de espera; Tercero, otra regla IP para
tratar las solicitudes de servicio de usuarios autentificados debe ser añadida bajo la
regla Allow de este primer paso. Como es explicado en 14 Reglas IP, todos lo otros
tráficos que no son explícitamente permitidos por la regla IP, por ejemplo, el
tráfico no autentificado proveniente desde la interfaz donde la autentificación es

definida, será desechada por el firewall.
Las configuraciones siguientes mostrarán cómo habilitar la autentificación de usuario

HTTP para el grupo de usuario ”users” en ”lannet”. Sólo los usuarios que pertenecen al
grupo ”users” pueden tener el servicio de buscador Web luego de la autentificación, como
es definido en la regla IP.
Se asume que ”lannet”, ”users”, ”lan ip”, archivo de base de datos local –
”lannet auth users”, y una dirección objetiva de autentificación ”lannet users”
es especificada (Refiérase a 8.1 Ejemplo: Habilitando Autentificación de Usuario para
una IP Objetiva).
WebUI
:
1. Rules → IP Rules → Add → IP rule:

General
Name: http2fw
Action: Allow
Service: HTTP
(Ver 8.2.1 Ejemplo: Especificando un servicio TCP – HTTP)
Filtro de Dirección
Elija lo siguiente desde las listas desplegables:
Source Destination
Interface: lan core
Network: lannet lan ip
Comentarios:
Permitir las conexiones HTTP al agente de autentificación del firewall.
Haga click en OK.

2. User Authentication → User Authentication Rules → Add →

User Authentication Rule
→ General
Name: HTTPLogin
Agent: HTTP
Authentication Source: Local
Interface: lan
Originator IP: lannet
Comments: autentificación HTTP para lannet vía base de datos de usuario local.
→ Authentication Options
General
Local User DB: lannet auth users
→ HTTP(s) Agent Options

General
Login Type: HTMLForm.
Haga click en OK.
3. Rules → IP Rules → Add → IP rule:

General
Name: Allow http auth
Action: NAT
Service: HTTP
Filtro de Dirección
Source Destination
Interface: lan any
Network: lannet users all-nets
(Note que la fuente de red es aquí una dirección objetiva contenedora de información
de autentificación de usuario.)
Comments: Permitir ”users” autentificados desde ”lannet” al buscador Web en

Internet.
Haga click en OK.

Nota
1. La autentificación HTTP colisionará con el servicio de administración remota WebUI

el cual también utiliza puerto 80 TCP. Para evitar esto, por favor modifique el
puerto WebUI en Ajustes Avanzados para la Administración Remota antes de
proceder con la configuración de autentificación, por ejemplo, utilizando puerto 81
en su lugar.
2. En las Opciones de Agente HTTP, hay dos tipos de registro disponibles,

HTMLForm y BasicAuth. El problema con BasicAUTH es que los buscadores
Web cache el nombre de usuario y contraseña ingresados en el diálogo de
Autentificación Requerida - 401. Esto normalmente no es un problema si el
buscador se encuentra cerrado, como es luego limpiado el cache; pero para
sistemas con el buscador incrustado en el sistema operativo, el cache es
difícil de limpiar. Por lo tanto, se recomienda HTMLForm. Un Realm String
puede ser definido para ser mostrado en el diálogo de Autentificación Requerida -
401 para opción BasicAUTH.
3. El tiempo de inactividad puede ser ajustado en User Authentication → User

Authentication Rules → Restrictions. Las opciones son Idle
Timeout and Session Timeout.
• Idle Timeout: Si un usuario ha sido exitosamente autentificado, y no se ha

visto tráfico desde su dirección IP por este número de segundos, el/ella
será automáticamente desconectado. El valor es por defecto 1800.
• Session Timeout: Si un usuario ha sido autentificado exitosamente,

el/ella serán automáticamente desconectados luego de esta cantidad de segundos,
a pesar de si el firewall ha visto actividad del usuario o no.
• Utilice Tiempos de inactividad recibidos desde el recuadro de verificación del
servidor de autentificación: Algunos servidores RADIUS pueden ser configurados
para retornar los valores de idle-timeout y session. Si este recuadro de
verificación es seleccionado, el firewall tratará de usar estos tiempos de
inactividad, antes de los valores de Tiempo de inactividad especificados
anteriormente. Si no se ha recibido tiempos de inactividad desde el servidor de
autenticación, serán utilizados los valores de inactividad especificados
anteriormente.
4. Otras restricciones de configuración son los Registros Múltiples de Nombre de
Usuario. Son disponibles tres opciones como se explico anteriormente:

• Permitir registros múltiples por nombre de usuario– Si es seleccionado ésto,

el firewall permitirá usuarios desde diferentes direcciones de fuente IP,
pero con el mismo nombre de usuario, para ser registrados simultáneamente.
• Permitir un registro por nombre de usuario, rechaza el resto– Si esto es
seleccionado, el firewall sólo permitirá un nombre de usuario simultáneo para
ser registrado. Esto es, si un usuario desde otra dirección IP trata de
autentificar con el mismo nombre de usuario que el de un usuario ya
autentificado, el firewall desechará este registro.
• Permitir un registro por nombre de usuario– Si este es seleccionado, el firewall
sólo permitirá un nombre de usuario simultáneo ser registrado. Si un usuario
desde otra dirección IP trata de autentificar con el mismo nombre de usuario
que un usuario ya autentificado, el firewall verificará si el usuario
autentificado ha sido ocupada por un período de tiempo. Si es así, el antiguo
será removido, y este nuevo usuario será registrado. Sino, la nueva solicitud
de registro sera rechazada. El periodo de tiempo para esta opción puede ser
definido en el recuadro de editar.

Parte VII
Inspección de Contenido
En adición a la inspección de paquetes en la capa de red (OSI
capa 3), los firewalls D-Link son capaces de examinar el contenido de
cada paquete para entregar una protección más poderosa y flexible
en capas superiores.
Los Tópicos de esta parte incluyen:
• Application Layer Gateway (ALG)
• Intrusion Detection System (IDS)

CAPITULO 18
Application Layer Gateway (ALG)
18.1 Vista General

Para complementar las limitaciones de filtrado de paquete, el cual sólo inspecciona en
los paquetes headers, tales como IP, TCP, UDP, y ICMP headers, los firewalls D-Link
incrustan una Application Layer Gateway (ALG) para soportar protocolos de alto
nivel que tienen información de dirección dentro de la carga explosiva.
El ALG actúa como el representante del usuario para obtener las aplicaciones Internet
más comúnmente utilizadas fuera de la red protegida, ej. acceso Web, transferencia de
archivo, y multimedia. Tales agentes conscientes de aplicación entregan una mayor
seguridad que los firewalls que sólo filtran paquetes, ya que son capaces de
inspeccionar todo el tráfico para que los protocolos específicos de servicio entreguen
protección en el nivel superior de la pila TCP/IP.
En este capítulo, se describen las siguientes aplicaciones estándar soportadas por

ALG D-Link.
• FTP
• HTTP
• H.323
147
148 Capitulo 18. Application Layer Gateway (ALG)
18.2 FTP
El File Transfer Protocol (FTP) es un protocolo basado en TCP/IP para el intercambio de
archivos entre cliente y servidor. El cliente inicia la conexión al conectarse al servidor
FTP. Normalmente el cliente necesita autentificarse a sí mismo entregando un
registro y contraseña predefinidos. Luego de ganar acceso, el servidor proveerá al
cliente con un listado de archivo/directorio desde el cual puede descargar/cargar
archivos (dependiendo de los derechos de acceso). El FTP ALG es utilizado para
administrar conexiones FTP a través del firewall.
18.2.1 Conexiones FTP

FTP utiliza dos canales de comunicación, uno para comandos de control y uno para
que los archivos actuales sean transferidos.
Cuando una sesión FTP es abierta, el cliente FTP establece una conexión TCP
(el canal de control) al puerto 21( por defecto) en el servidor FTP.
Lo que sucede luego de este punto depende del modo en que es utilizado el FTP.
Modos
Existen dos modos, activo y pasivo, describiendo el rol del servidor con respecto a los
canales de datos abiertos
En el modo activo, el cliente FTP envía un comando al servidor FTP indicando a qué
dirección IP y puerto el servidor debe conectarse. El servidor FTP establece el canal
de datos de vuelta al cliente FTP utilizando la información de dirección recibida.
En el modo pasivo, el canal de datos es abierto por el cliente FTP del servidor FTP,
tal como el canal comando. Este es el modo recomendado por defecto para
Clientes FTP, de acuerdo a el ”firewall-friendly FTP”
RFC.
Asuntos de Seguridad
Ambos modos de operación FTP presentan problemas para firewalls. Considere un

escenario donde un cliente FTP en la red interna se conecta a través del firewall a un
Servidor FTP en el Internet. La regla IP en el firewall es entonces configurada para permitir
tráfico de red desde el cliente FTP al puerto 21 en el servidor FTP.

18.2. FTP 149
Cuando el modo activo es utilizado, el firewall no es consciente de que el servidor

FTP establecerá una nueva conexión de vuelta al cliente FTP. Por lo tanto, la
conexión para el canal de datos será desechada por el firewall. Como el número de
puerto utilizado para el canal de datos es dinámico, el único camino para resolver esto es
permitir el tráfico desde todos los puertos en el servidor FTP a todos los puertos en el
Cliente FTP. Obviamente, esta no es una buena decisión.
Cuando el modo pasivo es utilizado, el firewall no necesita permitir desde el servidor

FTP. Por otro lado, el firewall aún no conoce qué puerto tratará de utilizar el cliente
FTP para el canal de datos. Esto significa que el firewall deberá permitir el tráfico desde
Todos los puertos en el cliente FTP a todos los puertos en el servidor FTP.
Aunque esto no es tan inseguro como en el caso de modo activo,
aún presenta una potencial amenaza de seguridad. Además, no todos los clientes FTP
son capaces de utilizar el modo pasivo.
Solución
El ALG FTP soluciona este problema reuniendo completamente la corriente TCP

del canal de comando y examinando sus contenidos. De este modo, el firewall
conoce qué puerto se abre para el canal de datos. Además, el ALG FTP también
entrega funcionalidad para filtrar ciertos comandos de control y entrega una
protección básica a invasión buffer.
La característica más importante del ALG FTP es la capacidad única de ejecutar una
“conversión en el camino” entre el modo activo y pasivo. La conversión puede ser
descrita como:
• El cliente FTP puede ser configurado para utilizar el modo pasivo, el cual es el modo
recomendado para los clientes.
• El servidor FTP puede ser configurado para utilizar el modo activo, el cual es el
modo más seguro para los servidores.
• Cuando es establecida una sesión FTP, el firewall automática y transparentemente

recibirá el canal pasivo de datos desde el cliente FTP y el canal activo de datos
desde el servidor, y los atará juntos.
Esta implementación resulta en que tanto, el cliente FTP y el servidor FTP trabajan
en su modo más seguro. Naturalmente, la conversión también trabaja el otro camino,
este es, con el cliente FTP utilizando modo activo y el servidor
FTP utilizando modo pasivo.
Guía de Usuario del Firewall D-Link

150 Capítulo 18. Application Layer Gateway (ALG)
18.2.2 Escenarios: Configuración ALG FTP
Ejemplo: Protegiendo un Servidor FTP
Figura 18.1: ALG FTP Escenario 1
En este ejemplo, un Servidor FTP es conectado al firewall D-Link en un DMZ con

direcciones IP privadas, mostrado en Figura 18.1. Para hacer posible el conectarse
a este servidor desde el Internet utilizando el ALG FTP, el ALG FTP y las reglas del
firewall deben ser configuradas como lo siguiente:
WebUI :
1. ALG
Objects → Application Layer Gateways → Add → FTP ALG:
General:
Name: ftp-inbound
Marque cliente Allow para utilizar el modo activo (inseguro para cliente).
Desmarque Allow servidor para utilizar el modo pasivo (inseguro para el servidor)

18.2. FTP 151
2. Services
General:
Name: ftp-inbound
Type: seleccione TCP desde la lista desplegable.
Destination: 21 (el puerto donde reside el servidor FTP).
Application Layer Gateway:

ALG: seleccione ”ftp-inbound” que debe ser creado.
3. Rules
– Permita conexiones al IP público en el puerto 21 y reenvíelo al servidor
FTP interno.
General:
Name: SAT-ftp-inbound
Action: SAT
Service: ftp-inbound
Address Filter:
Source Destination
Interface: any core
Network: all-nets ip-ext
(se asume que la interfaz externa ha sido definida como ”ip-ext”)
SAT:
Marque Translate the Destination IP Address
A:
New IP Address: ftp-internal.
(Se asume que esta dirección IP interna del servidor FTP ha sido definida en el
Libro de Direccion objetiva.)
New Port: 21.

– El tráfico desde la interfaz interna necesita ser NATed:
General:
Name: NAT-ftp
Action: NAT
Address Filter:
Source Destination
Interface: dmz core
Network: dmz-net ip-ext
NAT:
Marque Use Interface Address
– Permitir las conexiones entrantes (SAT necesita una segunda regla Allow):
General:
Name: Allow-ftp
Action: Allow
Address Filter:
Source Destination
Interface: any core
Network: all-nets ip-ext

18.2. FTP 153
Ejemplo: Protegiendo Clientes FTP
Figura 18.2: FTP ALG Escenario 2
En este escenario, mostrado en la Figura 18.2, un firewall D-Link está protegiendo

una estación de trabajo que conectará servidores FTP en el Internet. Para hacer
posible la conexión a estos servidores desde la red interna utilizando el ALG FTP,
éste y las reglas de firewall deberán ser configuradas como sigue:
WebUI
:
1. ALG
Objects → Application Layer Gateways → Add → FTP ALG:
General:
Ingrese un nombre descriptivo para el ALG.
Name: ftp-outbound
Desmarque Allow client para utilizar el modo activo (inseguro para el cliente).
Marque Allow server para utilizar el modo pasivo (inseguro para el servidor)

2. Services
General:
Name: ftp-outbound
Type: seleccione TCP desde la lista desplegable.
Destination: 21 (el puerto donde reside el servidor FTP).
Application Layer Gateway

ALG: select ”ftp-outbound” that has been created.
3. Rules (Using Public IPs)

La siguiente regla necesita ser añadida a las reglas IP en el firewall si éste está
utilizando IP público; asegúrese de que no hay reglas rechazando o permitiendo
el mismo tipo de puertos/tráficos antes de estas reglas. El servicio en uso es el
”ftp-outbound”, el cual debe estar utilizando la definición ALG
”ftp-outbound” como se describe previamente.
– Permita las conexiones a servidores-FTP en el exterior:
General:
Name: Allow-ftp-outbound
Action: Allow
Service: ftp-outbound
Address Filter:
Source Destination
Interface: lan wan
Network: lannet all-nets

18.3. HTTP 155
4. Rules (Using Private IPs)

Si el firewall está utilizando un IP privado, debe ser en cambio añadida la siguiente
regla NAT.
General:
Name: NAT-ftp-outbound
Action: NAT
Service: ftp-outbound
Address Filter:
Source Destination
Interface: lan wan
Network: lannet all-nets
NAT:
Check Use Interface Address
18.3 HTTP
Hyper Text Transfer Protocol (HTTP), es el protocolo primario utilizado para
acceder al World Wide Web (WWW). Es un protocolo de capa de aplicación dinámica
(OSI layer 7), orientado a conexión, el cual está basado en la
arquitectura de solicitud/respuesta. El cliente, tal como un buscador Web, típicamente
envía una solicitud estableciendo una conexión TCP/IP a un puerto particular
(usualmente puerto 80) en un servidor remoto. El servidor contesta con una sucesión
de respuesta, seguido por un mensaje de su propiedad, por ejemplo, un archivo HTML
para ser mostrado en el buscador Web, un componente activo-x para ser ejecutado en
el cliente, o un mensaje de error.
18.3.1 Componentes & Asuntos de Seguridad
Para habilitar funciones más avanzadas y extensiones a los servicios HTTP, algunos
componentes añadidos, conocidos como ”active contents”, son usualmente acompañados
con la respuesta HTTP al computador del cliente.
Guía de Usuario del Firewall D-Link

Complementos ActiveX
Un complemento ActiveX es un componente HTTP, el cual es ejecutado en el

computador del cliente. Debido a que es ejecutado en el cliente, existen
ciertas tareas de seguridad, lo cual puede causar daño al sistema del computador
local.
JavaScript/VBScript
Con el fin de visualizar páginas HTML más avanzadas y dinámicas, los scripts pueden
ser utilizados. Un script es ejecutado por el buscador web, y puede ser utilizado
para controlar la funcionalidad del buscador, validar la entrada del usuario, ó un
número de otras características. Puede ser potencialmente utilizado por un agresor en
un intento de causar un daño al sistema computacional, o causar varias molestias, tales
como pop-up windows.
Java Applets
Un java applet es escrito en lenguaje de programación JAVA, y un buscador java-habilitado

puede descargar y ejecutar este código en el computador del cliente. Un applet puede
contener códigos maliciosos, los cuales conducen a problemas de seguridad.
Cookies
Un cookie es un archive de texto pequeño, almacenado localmente en el computador

del cliente. Su objetivo es hacer que un servidor web recuerde cierta información sobre
un usuario, el cual ha sido ingresado previamente. Esto puede además contener
información confidencial.
18.3.2 Solucion
El firewall D-Link direcciona las ultimas areas de seguridad mostradas en la sección previa
por Stripping Contents and URL Filtering.
Stripping Contents
En la configuración D-Link HTTP ALG, algunos o todos los contenidos activos

Mencionados previamente pueden ser apartados desde el tráfico HTTP sobre
Solicitudes del administrador.

18.3. HTTP 157
Filtro URL
Un Uniform Resource Locator (URL) es una dirección a un recurso en el WWW. Este

puede por ejemplo ser una página HTML, ó un recurso de archivo. Como una parte de
una política de seguridad, puede ser útil restringir el acceso a ciertos sitios, o incluso
bloquear que ciertos tipos de archives sean descargados. El requisito opuesto puede
además ser verdad – puede ser favorable permitir el acceso completo (ej. No remover
los objetos anteriormente mencionados) a ciertas Fuentes confiables.
Un URL puede quedar en lista negra (blacklist) con el fin de prevenir el acceso a éste,
mientras un URL, whitelisted permite acceso complete a la fuente específica.
Ejemplo: Configurando HTTP ALG
En este ejemplo, un HTTP ALG en un firewall D-Link es creado. Este es configurado para
deshacer complementos ActiveX, lo cual bloqueará visualizaciones tales como
Macromedia flash y shockwave. Una dirección no deseada es añadida a la blacklist.
Las restricciones a otros contenidos actives, ó whitelists por direcciones confiables
pueden ser configuradas en un modo similar. Se asume que el servicio objetivo HTTP
y una regla IP que permitan el tráfico HTTP hayan sido definidas en el firewall.
WebUI
:
1. ALG
Objects → Application Layer Gateways → Add

→ HTTP ALG:
General:
Ingrese un nombre descriptive para el ALG.
Name: http-activex
Active Content Handling

Marque Strip ActiveX objects (incluyendo Flash)

Luego de hacer click en ok, la página de configuración va hacia URL Filtering list.
Add → HTTP URL:
General
Action: seleccione Blacklist desde la lista desplegable.
URL: Ingrese una dirección no deseada en el recuadro de edit.
2. Service
– Adding the HTTP ALG into the corresponding service object.
Objects → Services → HTTP:

Application Layer Gateway
ALG: seleccione ”http-activex” que ha sido creado.
18.4 H.323
18.4.1 Vista General Estándar H.323
H.323 es un estándar que es utilizado para audio a tiempo-real, video y comunicación
de datos sobre redes basadas en paquetes (ej. IP). Éste especifica los componentes,
protocolos y procedimientos entregando comunicación multimedia.
H.323 es un estándar aprobado por la Unión Internacional de Telecomunicación

para promover compatibilidad en las transmisiones de video conferencia sobre redes
IP.
H.323 es considerado para ser el estándar de interoperabilidad en audio, video

y transmisiones de datos así como un teléfono Internet y voice-over-IP (VoIP).
18.4.2 Componentes H.323

El H.323 estándar consiste en estos cuatro componentes principales:
• Terminals
• Gateways
• Gatekeepers

18.4. H.323 159
• MCUs (Multipoint Control Units)
Terminals
Una terminal H.323 es un dispositivo que es utilizado para audio y video como opción ó
comunicación de datos. Por ejemplo teléfonos, unidades de conferencia, ó teléfonos
software (por ejemploe: NetMeeting) corriendo en PCs estándar.
Gateways
Un gateway conecta dos redes similares y traduce el tráfico entre ellos. Un H.323
gateway entrega conectividad entre redes H.323 y redes no-H.323 tales como
public switched telephone networks (PSTN). El gateway se preocupa de traducir
protocolos y convertir media entre redes diferentes. Un Gateway no es requerido
para la comunicación entre dos terminales H.323.
Gatekeepers
El Gatekeeper es un componente en el sistema H.323 el cual es utilizado para

direccionar, autorizar y autentificar de terminales y gateways. Este puede además
preocuparse de tales cosas como administración de amplitud de banda pago de cuenta
y cargos. El gatekeeper puede permitir llamadas directamente entre puntos
de término, ó puede dirigir la señal de llamado a través de sí mismo para ejecutar
funciones tales como sigame-encuentreme, direccionar si esta ocupado, etc.
Un gatekeeper es
necesitado cuando hay más de una terminal H.323 detrás de un firewall
NAT con sólo una IP pública.

MCUs (Multipoint Control Units)
MCUs entrega soporte para conferencias de tres ó más terminals H.323. Todas las
terminales H.323 participantes en la llamada de conferencia deben establecer una
conexión con el MCU. El MCU luego administra los llamados, recursos, codecs de
video y audio utilizados en la llamada.
18.4.3 Protocolos H.323

Los diferentes protocolos utilizados en H.323 son descritos en resumen a
continuación:
H.225 RAS Signaling and Call Control (Setup) Signaling
El protocolo H.225 es utilizado para la señal de llamado, esto significa que es utilizado
Para establecer una conexión entre dos puntos de término(terminales) H.323. Este

canal de señal de llamada es abierto entre dos puntos de término H.323 ó entre un
punto de término H.323 y gatekeeper. Para la comunicación entre dos puntos de
término H.323, es utilizado TCP 1720. Cuando se conecta al gatekeeper, es utilizado el
puerto UDP 1719 (H.225 RAS mensajes).
H.245 Media Control and Transport
El protocolo H.245 entrega control a sesiones multimedia establecidas entre dos

puntos de término H.323. La tarea más importante para este protocolo es negociar la
apertura y cierre de canales lógicos. Un canal lógico es, por ejemplo, un canal de audio
utilizado para comunicación de voz. Los canales de video y T.120 son además
llamados canales lógicos durante la negociación.
T.120
El T.120 estándar es construido de un juego de comunicación y protocolos de

aplicación. Dependiendo del tipo de producto H.323, el protocolo T.120 puede ser
utilizado para el intercambio de aplicación, transferencia de archivo y características
de conferencia tales como whiteboards.
18.4.4 Vista General H.323 ALG

El H.323 ALG es una application layer gateway flexible que permite dispositivos H.323
tales como teléfonos H.323 y aplicaciones para realizar y recibir llamadas entre ellos
mismos mientras están conectados a redes privadas aseguradas por los Firewalls
D-Link.
La especificación H.323 no fue designada para manejar NAT, cuando direcciones IP

y puertos son enviados en el servidor de mensajes H.323. El H.323 ALG
modifica y traduce mensaje H.323 para asegurar de que el mensaje H.323 será
dirigido al destino correcto y permitido a través del firewall.
El H.323 ALG tiene las siguientes características:
• H.323 version 5 (H.225.0 v5, H.245 v10)
• Application sharing (T.120)
• Gatekeeper support
• NAT, SAT

18.4. H.323 161
El H.323 ALG soporta versión 5 de la especificación H.323. Esta especificación

es construída sobre H.225.0 v5 y H.245 v10. En adición a soportar llamadas de
voz y video, el H.323 ALG soporta el intercambio de aplicación sobre el protocolo
T.120. T.120 utiliza TCP para transportar datos mientras la voz y video es transportado
sobre UDP.
Para soportar gatekeepers, el ALG se asegura de monitorear tráfico RAS entre

puntos de término H.323 y el gatekeeper, con el fin de configurar al firewall para
dejar llamadas pasar.
Son soportadas reglas NAT y SAT, permitiendo a los clientes y gatekeepers utilizar
direcciones IP privadas en una red detrás del firewall.
18.4.5 Escenario: Configuración H.323 ALG

El H.323 ALG puede ser configurado para seguir diferentes escenarios de uso.
Es posible configurar si los canales de datos TCP deben ser permitidos para
atravesar el firewall o no. Los canales de datos TCP son utilizados por el protocolo
T.120 (ver 18.4.3), por ejemplo. Además, el número máximo de canales de datos TCP
pueden ser limitados a un valor fijo.
El registro de tiempo de vida del gatekeeper puede ser controlado por el firewall con
el fin de forzar el re-registro de clientes dentro de un marco de tiempo especificado por
el administrador.
Presentados aquí hay algunos escenarios de red, visualizados en diagramas de red.

Los escenarios son ejemplos de ajustes de red en donde el H.323 ALG es apropiado para
utilizar. Para cada escenario es presentada un ejemplo de configuración de tanto el ALG
como de las reglas.
Las tres definiciones de servicio utilizadas en estos escenarios son:
• Gatekeeper (UDP ALL → 1719)
• H323 (H.323 ALG, TCP ALL → 1720)
• H323-Gatekeeper (H.323 ALG, UDP → 1719)

Ejemplo: Protegiendo un Teléfono detrás de un Firewall D-Link
Figura 18.3: H.323 Escenario 1.
Utilizando Direcciones IP públicas

En el primer escenario un teléfono H.323 es conectado a un Firewall D-Link en una red
(lan-net) con direcciones IP públicas. Para hacer posible ubicar una llamada desde este
teléfono a otro teléfono H.323 en el Internet, y para permitir teléfonos H.323 en el internet
para llamar a este teléfono, se necesita configurar las reglas del firewall.
Las siguientes reglas necesitan ser añadidas al listado de regla en el firewall, asegúrese
de que no hay reglas rechazando ó permitiendo el mismo tipo de puertos/tráfico ante
estas reglas.

18.4. H.323 163
WebUI
:
1. Outgoing Rule

Name: H323AllowOut
Action: Allow
Service: H323
Destination Network: 0.0.0.0/0 (all-nets)
Comment: Allow outgoing calls.
2. Incoming Rule

Name: H323AllowIn
Action: Allow
Service: H323
Destination Interface: LAN
Source Network: 0.0.0.0/0 (all-nets)
Destination Network: lan-net
Comment: Allow incoming calls.
Utilizando direcciones Privadas IP

En este teléfono un teléfono H.323 es conectado a un Firewall D-Link en una red
con direcciones IP privadas. Para hacer posible ubicar una llamada desde este teléfono
a otro teléfono H.323 en el internet, y permitir teléfonos H.323 en el Internet para llamar
a este teléfono, se necesita configurar reglas firewall.

164 Capítulo18. Application Layer Gateway (ALG)
Las siguientes reglas necesitan ser añadidas al listado de reglas en el firewall,

asegúrese de que no hay reglas rechazando ó permitiendo el mismo tipo de
puertos/tráfico ante estas reglas. Cuando se utiliza IPs privadas en el teléfono, el
tráfico entrante necesita ser SATed como en el ejemplo a continuación. El ip-phone
objetivo a continuación debe ser el IP interno del teléfono H.323.
WebUI
:
1. Outgoing Rule

Name: H323Out
Action: NAT
Service: H323
Comment: Permitir llamadas salientes.

18.4. H.323 165
2. Incoming Rules

Name: H323In
Action: SAT
Service: H323
Destination Network: ip-wan (IP externo del firewall)
Comment:Permitir llamadas entrantes al teléfono H.323 en ip-phone.
SAT
Translate Destination IP Address: To New IP Address: ip-phone (dirección IP
del teléfono)

Name: H323In
Action: Allow
Service: H323
Destination Network: ip-wan (external IP of the firewall)
Comment: Permitir llamadas entrantes a teléfono H.323 en ip-phone.
Para ubicar una llamada al teléfono detrás del Firewall D-Link, haga una llamada a la
dirección IP externa en el firewall. Si teléfonos H.323 múltiples son ubicados detrás del
firewall, una regla SAT debe ser configurada para cada teléfono. Esto significa que
direcciones externas múltiples deben ser utilizadas. Sin embargo, es preferible
utilizar un gatekeeper H.323 gatekeeper como en el escenario ”H.323 con Gatekeeper”
(ver 18.4.5), como esto sólo requiere una dirección externa.

Ejemplo: Dos Teléfonos Detrás de Diferentes Firewalls D-Link
Utilizando Direcciones IP Públicas

Este escenario consiste en dos teléfonos H.323, cada uno conectado detrás de un
Firewall D-Link en una red con direcciones IP públicas. Con el fin de hacer llamadas
en estos teléfonos sobre el Internet, las siguientes reglas necesitan ser añadidas al
listado de regla en ambos firewalls. Asegúrese de que no hay reglas rechazando
ó permitiendo el mismo tipo de puertos/tráfico ante estas reglas.

18.4. H.323 167
WebUI
:
1. Outgoing Rule

Name: H323AllowOut
Action: Allow
Service: H323
2. Incoming Rule

Name: H323AllowIn
Action: Allow
Service: H323
Comment: Permitir llamadas entrantes.
Utilizar Direcciones IP Privadas

Este escenario consiste en dos teléfonos H.323, cada uno conectado detrás de un
Firewall D-Link en una red con direcciones IP privadas. Con el fin de hacer llamadas
en estos teléfonos sobre el Internet, las siguientes reglas necesitan ser añadidas al
listado de reglas en el firewall, asegúrese de que no hay reglas rechazando ó
o permitiendo el mismo tipo de puertos/tráfico ante estas reglas. Como se está

168 Capitulo18. Application Layer Gateway (ALG)
Utilizando IPs privado en los teléfonos, el tráfico entrante necesita ser SATed como en
el ejemplo a continuación. El ip-phone objetivo a continuación debe ser el IP interno del
teléfono H.323 detrás de cada firewall.
WebUI
:
1. Outgoing Rule

Name: H323Out
Action: NAT
Service: H323
2. Incoming Rules

Name: H323In
Action: SAT
Service: H323
Comment: Permitir llamadas entrantes a teléfonos H.323 en ip-phone.
SAT
Translate Destination IP Address: To New IP Address: ip-phone (dirección IP
del teléfono)

18.4. H.323 169

Name: H323In
Action: Allow
Service: H323
Destination Network: ip-wan (external IP of the firewall)
Comment: Permitir llamadas entrantes al teléfono H.323 en ip-phone.
Then click OK
Para hacer llamadas al teléfono detrás del Firewall D-Link, haga una llamada a la
dirección IP externa en el firewall. Si múltiples teléfonos H.323 son ubicados detrás del
firewall, una regla SAT debe ser configurada para cada teléfono. Esto significa que
direcciones múltiples externas deben ser utilizadas. Sin embargo, es preferible
utilizar un gatekeeper H.323 como en el escenario ”H.323 con Gatekeeper”
(ver 18.4.5), cuando esto sólo requiere una dirección externa.
Ejemplo: H.323 con Gatekeeper
En este escenario, un gatekeeper H.323 es ubicado en el DMZ del Firewall D-Link.

Una regla es configurada en el firewall para permitir el tráfico entre la red privada

Donde están conectados los teléfonos H.323 en la red interna y al Gatekeeper en el

DMZ. El Gatekeeper en el DMZ es configurado con una dirección privada.
Se necesitan añadir las siguientes reglas al listado de reglas en ambos firewalls,

asegúrese de que no hay reglas rechazando o permitiendo el mismo tipo de
puertos/tráfico ante estas reglas.
WebUI
:
1. Incoming Gatekeeper Rules

Name: H323In
Action: SAT
Service: H323-Gatekeeper
Comment: una regla SAT para comunicación entrante con el Gatekeeper localizado
en ip-gatekeeper.
SAT
Translate Destination IP Address: To New IP Address: ip-gatekeeper
(dirección IP del gatekeeper)

18.4. H.323 171

Name: H323In
Action: Allow
Destination Network: ip-wan (IP externa del Firewall)
Comment: Permitir comunicación con el Gatekeeper.

Name: H323In
Action: Allow
Service: Gatekeeper
Destination Interface: DMZ
Destination Network: ip-gatekeeper (IP address of gatekeeper)
Comment: Permitir comunicación entrante con el Gatekeeper.
Nota
No hay necesidad de especificar una regla específica para llamadas salientes. El

Firewall D-Link monitorea la comunicación entre teléfonos ”external” y el Gatekeeper
para asegurar que es posible para los teléfonos internos llamar a los teléfonos externos
que son registrados con el gatekeeper.

Ejemplo: H.323 con Gatekeeper y dos Firewalls D-Link
Este escenario es muy similar al escenario 3, con la diferencia de un Firewall D-Link

protegiendo los teléfonos ”external”. El Firewall D-Link con el Gatekeeper conectado
al DMZ debe ser configurado exactamente como en el escenario 3
(ver 18.4.5). El otro Firewall D-Link debe ser configurado como a continuación.
Las siguientes reglas necesitan ser añadidas al listado de reglas en el firewall,

asegúrese de que no hay reglas rechazando ó permitiendo el mismo tipo de
puertos/tráfico ante estas reglas.

18.4. H.323 173
WebUI
:
1. Outgoing Gatekeeper Rule

Name: H323Out
Action: NAT
Comment: Permitir comunicación saliente con un gatekeeper.
Nota

para asegurar que es posible para teléfonos internos llamar a los teléfonos
externos que son registrados con el gatekeeper.
Ejemplo: Utilizando el H.323 ALG en un Ambiente Corporativo
Este escenario es un ejemplo de una red más compleja que muestra cómo el
H.323 ALG puede ser desplegado en un ambiente corporativo. En la oficina central
DMZ un H.323 Gatekeeper es ubicado de modo que pueda manejar todos los clientes
H.323 en la central-, sucursal- y oficinas remotas. Esto puede permitir a la corporación
completa utilizar la red para ambas comunicaciones de voz e intercambio de aplicación. Es
asumido que los túneles VPN son correctamente configurados y que todas las oficinas
utilizan rangos IP privados en sus redes locales. Todas las llamadas salientes son realizadas

Sobre la red telefónica existente utilizando el gateway (ip-gateway)

conectado a la red telefónica ordinaria.
Configuración del Firewall de la Oficina Central

La oficina central ha ubicado el Gatekeeper H.323 en el DMZ del Firewall D-Link
corporativo. Este Firewall D-Link debe ser configurado como a continuación.

18.4. H.323 175
WebUI
:
1. Rules → IP Rules → Add → IP Rule:

Name: LanToGK
Action: Allow
Service: Gatekeeper
Destination Network: ip-gatekeeper
Comment: Permitir entidades H.323 en lan-net conectarse al Gatekeeper.

Name: LanToGK
Action: Allow
Service: H323
Destination Network: ip-gateway
Comment: Permitir entidades H.323 en lan-net llamar a los teléfonos conectados al
Gateway H.323 en el DMZ. Recuerde utilizar el servicio correcto.


Name: GWToLan
Action: Allow
Service: H323
Source Interface: DMZ
Source Network: ip-gateway
Comment: Permitir comunicación desde la Gateway a teléfonos H.323 en int-net.
Recuerde utilizar el servicio correcto.

Name: BranchToGW
Action: Allow
Source Interface: vpn-branch
Source Network: branch-net
Destination Network: ip-gatekeeper, ip-gateway
Comment: Permitir comunicación con el Gatekeeper en DMZ desde la red
Sucursal

18.4. H.323 177

Name: BranchToGW
Action: Allow
Source Interface: vpn-remote
Source Network: remote-net
Destination Network: ip-gatekeeper
Comment: Permitir comunicación con el Gatekeeper en DMZ desde la red
Remota
Firewall de Sucursal y Oficina Remota

Los teléfonos de sucursal y oficina remota H.323 y aplicaciones serán configuradas
para utilizar el Gatekeeper H.323 en la oficina central. Los Firewalls D-Link en las
oficinas remotas y sucursales deben ser configuradas como a continuación.
La siguiente regla debe estar en ambos Firewalls, el de la Oficina Central y la

Remota.

WebUI
:

Name: ToGK
Action: Allow
Destination Interface: vpn-hq
Destination Network: hq-net
Comment: Permitir comunicación con el Gatekeeper conectado al DMZ de la
Oficina Central.
La sucursal del Firewall D-Link tiene un Gateway H.323 conectado a su DMZ. Con el
fin de permitir al Gateway registrarse dentro del H.323 Gatekeeper en la Oficina Central,
la siguiente regla debe ser configurada.

18.4. H.323 179
WebUI
:

Name: GWToGK
Action: Allow
Source Interface: DMZ
Destination Interface: vpn-hq
Source Network: ip-branchgw
Destination Network: hq-net
Comment: Permitir al Gateway comunicarse con el Gatekeeper conectado a
la Oficina Central.
Nota

para asegurarse de que es posible para los teléfonos internos llamar a los teléfonos
externos que están registrados con el gatekeeper.

CAPITULO 19
Sistema de Detección de Intrusos
(IDS)
19.1 Vista General

La Detección de Intrusos es una tecnología que monitorea el tráfico de red, buscando
indicios de violaciones de seguridad, o intrusiones. Una Intrusión puede ser definida como
un intento de comprometer ciertas partes de un sistema computacional, ó evitar sus
mecanismos de seguridad. Como estas formas de ataques son un acontecimiento
común en el Internet, y pueden a menudo ser fácilmente automatizados por un
agresor, la Detección de Intrusos es una tecnología importante para identificar y
prevenir estas amenazas.
Con el fin de hacer un IDS efectivo y confiable, el IDS D-Link va a través de tres niveles
de procesamiento y dirige las siguientes preguntas:
• Qué tráfico analizar
• Qué buscar (ej. qué es un “ataque”)
• Qué acción llevar a cabo
Como un ejemplo, imagine un sistema que está monitoreando FTP. Podría sólo
preocuparse del tráfico relacionado a FTP, mientras que el tráfico relacionado con, por ejemplo
POP3, no tendría interés en cualquiera. Además, sólo los ataques que aluden al
protocolo FTP serían de interés.
181
182 Capítulo 19. Sistema de Detección de Intrusos (IDS)
El IDS D-Link utiliza una combinación de Reglas de Detección de Intrusos, Patrón de

Coincidencias, y Acciones, con el fin de responder las tres interrogantes mencionadas
con anterioridad.
19.1.1 Reglas de Detección de Intrusos

Una Regla de Detección de Intrusos define el tipo de tráfico-servicio que debe ser
analizado. Además es definido aquí el filtro de campos con respecto a fuente y
destino, interfaces, redes, puertos y protocolos. Sólo el tráfico coincidente con esta
regla es pasado al siguiente nivel de procesamiento de IDS, donde el análisis actual
toma lugar.
19.1.2 Patrón de Coincidencia

Con el fin de que el IDS identifique correctamente un ataque, este debe saber qué es un
Ataque. Para conseguir esto, patrones pre-definidos, denominados ”signatures”, son
creados para describir ciertos ataques. El tráfico de red es luego analizado por el IDS,
buscando por estas coincidencias. Esto es conocido además como ”misuse
detection” o ”signature detection”.
Considere el siguiente ejemplo. Un usuario intenta recuperar el archive de contraseña

”passwd” desde un sistema, utilizando FTP:
RETR passwd
Una signature buscando por el texto ASCII ”RETR” y ”passwd” puede causar una
coincidencia en este caso, señalando que se ha encontrado un ataque.
Con el fin de hacer este ejemplo fácil de seguir, se utilizarán patrones contenedores de
Texto ASCII. Esto no es necesario; los patrones pueden de todas formas contener
datos binarios.
Si es encontrado un ataque, se llevará a cabo el siguiente nivel de procesamiento del

IDS- causa de acción.
19.1.3 Acción
Luego de que ha sido detectada una intromisión, una acción ó respuesta debe ser tomada.
Dependiendo de la gravedad del ataque, el tráfico puede tanto ser desechado,
Registrado, ambos, o simplemente ignorado.

19.2. Cadena de Eventos 183
19.2 Cadena de Eventos

Lo siguiente es una imagen simplificada de la cadena de eventos cuando un paquete
llega al firewall, con enfoque en el IDS (note que no es considerado otro
Sub-sistema) son posibles dos escenarios, uno donde la regla de ajuste del firewall debe
aceptar el paquete antes de pasarlo en el IDS, y otro donde el IDS puede procesar el
tráfico incluso si la regla de ajuste decide que el paquete debe serdesechada.
19.2.1 Escenario 1
El tráfico es solamente pasado en el IDS si la regla de ajuste IP del firewall decide
que es válido, mostrado en la Figura 19.1.
Figura 19.1: Cadena de Eventos IDS Escenario 1

1. Un paquete llega al firewall y son ejecutadas verificaciones iniciales con

respecto a las direcciones IP de fuente/destino y puertos de fuente/destino.
Si este paquete es aceptado por las reglas de ajuste del firewall IP, será
establecida una conexión entre la fuente y el destino, antes de pasar el
paquete al sub-sistema IDS. Si el paquete es parte de una conexión ya existente,
es además pasado en el sub-sistema IDS. Si el paquete es denegado por la regla
de ajuste IP, este sera desechada
2. La información de fuente y destino del paquete es comparada con la Regla de

Detección de Intrusos. Si es encontrada una coincidencia, esta es pasada al
siguiente nivel de procesamiento IDS- patrón de coincidencia. Si no, será
aceptado, con acciones futuras posibles, como es definido por la regla de ajuste
(por ejemplo traducción de dirección, registro, etc).
3. La ingeniería de patrón de coincidencia registra el payload

del paquete por signatures pre-definidas. Si es encontrada alguna coincidencia
el nivel final de procesamiento IDS es llevado a cabo – la acción. Si no, el
paquete es aceptado, con posibles acciones futuras, como lo define la regla de
ajuste (por ejemplo traducción de dirección, registro, etc).
4. Dependiendo de las acciones definidas en la Regla de Detección de Intrusos, el

paquete puede ser desechado, registrado, ambos, o ignorado.
19.2.2 Escenario 2
Éste es similar al primer escenario, pero con una gran diferencia. El tráfico sera siempre
pasado en el IDS a pesar de la acción elegida por la regla de ajuste del firewall IP.
Esto significa que el tráfico que el firewall deseche será también analizado.
La Figura 19.2 muestra la secuencia de eventos cuando la regla de ajuste IP del firewall
decide que el tráfico no es válido y deberá ser desechado y el tráfico es pasado al IDS
para futuros análisis.
1. Un paquete llega al firewall y son desplegadas verificaciones concernientes a

la fuente/destino de direcciones IP y puertos de fuente/destino. La regla de
ajuste del firewall IP decide que este paquete deberá ser desechado, pero antes
de eso, el tráfico es pasado por el sub-sistema IDS para futuros
análisis.
2. La información de fuente y destino del nuevo paquete es comparado con la Regla

de Detección de Intrusos. Si es encontrada una coincidencia, esta será pasada al
siguiente nivel del procesamiento IDS – patrón de coincidencia. Si no, el paquete
es desechado.

19.2. Cadena de Eventos 185
Figura 19.2: Cadena de Eventos IDS Escenario 2

3. La ingeniería de patrón de coincidencia registra el payload de el paquete por

firmas pre-definidas. Si es encontrada alguna coincidencia, se lleva a
cabo el nivel final de procesamiento IDS – la acción. Si no, el paquete es
desechado
4. Como este paquete no será aceptado por el firewall, la única acción
de interés es registrar el intento de intrusión.
19.3 Grupos de Firmas

Usualmente, existen varios ataques para un protocolo específico, y puede ser más
favorable buscar por todos ellos al mismo tiempo cuando se analiza el tráfico de red.
Para realizar esto, las firmas que refieren al mismo protocolo son agrupadas juntas.
Por ejemplo, todas las firmas que refieren al protocolo FTP son localizadas en un
Grupo, mientras que las firmas que refieren al POP3 son localizadas en otro
grupo. En adición a esto, las firmas que se originan desde la misma fuente
son también agrupadas juntas. Esto significa que las firmas que son sólo válidas
cuando se originan desde la red externa son agrupadas juntas, mientras que las
firmas que son válidas cuando se originan desde la red interna son localizadas
en otro grupo. Esto es realizado con el fin de permitir un procesamiento más efectivo
para el IDS.
19.4 Actualización Automática de Base de Datos

de Firmas
El descubrimiento de nuevos ataques es un proceso en curso. Los nuevos ataques son
algunas veces descubiertos diariamente, de modo que es importante tener una base de
datos de firma actualizada con el fin de proteger la red desde la última
amenaza. La base de datos de la firma contiene todas las firmas y grupos de
firmas comúnmente reconocido por el IDS.
Una nueva, base de datos de firma actualizada puede ser descargada automáticamente
por el firewall, a un intervalo configurable. Esto es realizado a través de una
conexión HTTP a un servidor D-Link, albergando el ultimo archivo de base de datos de
firma. Si este archivo de base de datos de firma tiene una versión más nueva que la
actual la nueva base de datos de firma será descargada, de este modo reemplazando la
antigua version. Esto asegurará que la base de datos de la firma estará siempre
actualizada.
Figura 19.3 es una imagen simplificada que describe el flujo de comunicación cuando
un nuevo archivo de base de datos de firma es descargado:

19.5. Receptor de Registro para Eventos IDS 187
Figura 19.3: Actualización de Base de datos de signature
19.5 Recepción de Registro SMTP para Eventos IDS

Con el fin de recibir notificaciones vía e-mail de eventos IDS, un receptor de registro
SMTP puede ser configurado. Este e-mail contiene una suma de eventos IDS
que han ocurrido en un periodo de tiempo usuario-configurable.
Cuando se ha producido un evento IDS, el firewall D-Link esperará por segundos de

Tiempo en espera antes de enviar el e-mail de notificación. Sin embargo, el e-mail sólo
será enviado si el número de eventos ocurridos en este período de tiempo es igual a,
o mayor, que el Log Threshold . Cuando este e-mail ha sido enviado, el firewall esperará
por un Tiempo Mínimo de Repetición antes de enviar un nuevo e-mail.
Ejemplo: Configurando un Receptor de Registro SMTP
En este ejemplo, una Regla de Detección de Intrusos es configurada con un Receptor

de Registro SMTP y los siguientes valores:
Minimum Repeat Time: 600 seconds

Hold Time: 120 seconds
Log Threshold: 2 events

Una vez que un evento IDS ocurre, la Regla de Detección de Intrusos es gatillada. Al
menos un nuevo evento ha ocurrido dentro del Hold Time, 120 segundos, de este
modo alcanzando el nivel de log threshold (al menos 2 eventos han ocurrido). Esto
resulta en un e-mail a ser enviado, conteniendo una suma de eventos IDS.
Varios eventos IDS pueden ocurrir después de esto, pero para prevenir un exceso de
servidores mail, el firewall esperará por 600 segundos (10 minutos) antes de enviar
un nuevo e-mail, conteniendo información sobre los nuevos eventos. Un servidor
SMTP es asumido para ser configurado en el libro de dirección, con un nombre de
dirección IP objetiva ”smtp-server”.
WebUI
:
1. SMTP log receiver:

– adding a SMTP log receiver
System → Log and Event Receivers → Add

→ SMTP Event Receiver:
General
Name: smtp4IDS
SMTP Server: smtp-server
Server Port: 25 (estándar para Internet)
Llene en las direcciones e-mail alternativas en los recuadros de editar ( se pueden
configurar por sobre 3 direcciones).
Sender: hostmaster
Subject: Log event from D-Link Firewall
Minimum Repeat Delay: 600
Hold Time: 120
Log Threshold: 2
2. Reglas IDS.
– Habilitar el registro en la página de configuración ”Log Settings” para una regla
específica IDS y utilizando Todos los receptores ó receptor específico ”smtp4IDS”
configurado antes como receptor de registro.

19.6. Escenario: Ajustando IDS 189
19.6 Escenario: Configurando IDS
El siguiente ejemplo ilustra los pasos necesarios para ajustar IDS para un simple
escenario donde un servidor mail es expuesto al Internet en la red DMZ, con una
dirección IP pública, y debe ser protegida por el IDS, como se muestra en la Figura
19.4. El Internet puede ser alcanzado a través del firewall en la interfaz WAN.
Figura 19.4: Un Escenario IDS
WebUI
:
1. Configurando Objetos y Servicios:

Se asume que un objeto definiendo el servidor mail ha sido creado y que la interfaz y
red objetiva existen para la red interna y externa.
En caso de que el servicio para SMTP no exista realmente, este debe ser creado, lo
Cual es realizado en Objects → Services. El tipo es TCP, y puerto de destino es 25.
2. Crear Regla IDS:

Esta regla IDS será llamada IDSMailSrvRule, y el servicio a utilizar es el previamente
creado servicio SMTP. La interfaz de Fuente y Red de Fuente define desde donde
proviene el tráfico, en este ejemplo la red externa.
La Interfaz de Destino y Red de Destino definen dónde es direccionado el tráfico,
en este caso el servidor mail. La Red de Destino debe por lo tanto ser ajustada al
Objeto definiendo el servidor mail.

IDS/IDP → IDS Rules → Add → IDS/IDP Rule:

Name: IDSMailSrvRule
Service: smtp
Also inspect dropped packets: En caso de que todo el tráfico coincide esta regla
debe ser escaneado (esto también significa que el tráfico que la regla-ajuste principal
podría desechar),el ”Also inspect dropped packets” recuadro de verificación debe ser
marcado lo cual es el caso en este ejemplo.
Source Interface: WAN
Source Network: wan-net
Destination Network: ip mailserver
Si es deseado un registro de intentos de intrusión, esto puede ser configurado en la

etiqueta de Registro, donde un receptor de registro puede ser elegido.
3. Crear Acción IDS
Cuando esta Regla IDS ha sido creada, una acción debe ser creada además,
especificando qué firma debe utilizar el IDS cuando datos escaneados coinciden
la Regla IDS, y qué debe hacer el firewall en caso de que una intrusión sea descubierta.
Los intentos de intromisión deben causar que la conexión sea desechada, de modo que
”Action” es ajustado para Proteger. La intensidad es ajustada a All, con el fin de
hacer coincidir todas las firmas posibles. ”Signatures” es ajustado a FROM EXT MAIL
SMTP con el fin de utilizar las firmas que describen ataques desde la red externa
tratando con el protocolo SMTP.
IDS/IDP → IDS Rules → IDSMailSrvRule → Add → IDS Rule

Action:
Action: Protect
Severity: All
Signatures: FROM EXT MAIL SMTP
Para resumir, debe ocurrir lo siguiente: Si es descubierto el tráfico desde la red externa,
al servidor mail, el IDS será activado. En caso de que el tráfico coincida con cualquiera
de las firmas en el FROM EXT MAIL SMTP grupo de firma, la conexión
será desechada, de este modo se protege el servidor mail. Si un receptor de registro
ha sido configurado, el intento de intrusión será además registrado.

Parte VIII
Red Privada Virtual
(VPN)
VPNs, Redes Virtuales Privadas, entregan medios para establecer
Links seguros a grupos. Es extendido sobre redes públicas vía la
Aplicación de Encriptación y Autentificación, ofreciendo buena
flexibilidad, protección efectiva, y eficiencia de costo en las
conexiones sobre el Internet.
Tópicos en esta parte incluyen:
• Introducción a VPN
• Introducción a Criptografía
• VPN en Firewalls
• Protocolos & Túneles VPN
• Planeamiento VPN
CAPITULO 20
VPN Básico
20.1 Introducción a VPN

Hace un tiempo las redes corporativas eran islas separadas de conectividad
local. Hoy en día la mayoría de las redes son conectadas entre sí por el Internet.
Temas de protección de redes locales desde crimen basado en Internet e intrusión
son resueltos por firewalls, sistemas de detección de intrusos, software anti-virus y
otras inversiones de seguridad. Sin embargo, los negocios están incrementando a
menudo su utilización de Internet como un medio de comunicación
eficiente y económica.
Como se ha aprendido de una manera difícil, no todas las partes del Internet pueden
ser confiadas en nuestro tiempo. Intereses privados así como requisitos de comunicación
corporativa necesita un medio para que los datos sean capaces de viajar a través de
Internet a su receptor previsto sin permitir que nadie más lo lea o altere. Esto es
tan importante como que el receptor pueda verificar que nadie está falsificando
Información, ej. pretendiendo ser alguien más.
VPNs, Virtual Private Networks, entregan un significado apropiado de costo-eficiencia

para el establecimiento de links seguros a grupos que desean intercambiar información
en un medio digno de confianza.
20.1.1 VPNs vs Conexiones Fijas

El utilizar líneas arrendadas u otros canales no públicos para intercambiar datos entre
organizaciones no es un nuevo concepto. Se ha realizado desde que los
193
194 Capítulo 20. VPN Básico
primeros computadores comenzaron a comunicarse entre sí. En un comienzo, la

comunicación estaba limitada a enlaces de comunicación de área local, pero con
el tiempo, las personas encontraron razones para tener que intercambiar información
con sus computadores a través de grandes distancias.
Las conexiones fijas son usualmente muy confiables en la medida que el tiempo de
funcionamiento y amplitud de banda disponible sea afectado. Estos son
bastante seguros, mientras que nadie ataque la infraestructura telefónica o arranque
sus fibras ópticas del suelo y adhiera su propio equipo en éstas. Conexiones fijas
de larga distancia, que entregan las apropiadas medidas de seguridad que serán tomadas,
pueden considerarse ”Private Networks”.
Sin embargo, los canales fijos de comunicación son sólo eso: fijos. Si usted contrata una
conexión fija entre compañía A y B, usted sólo permitirá la comunicación entre esas
compañías. Si varias organizaciones desearan comunicarse entre ellas en todas
direcciones, se necesitarían conexiones fijas por separado entre todas las
organizaciones. Tales situaciones rápidamente escalan más allá de todo
manejo y costo-eficiencia:
- Dos organizaciones requieren sólo 1 conexión.
- Tres organizaciones requieren 3 conexiones.
- Cinco organizaciones requieren 10 conexiones.
- Siete organizaciones requieren 21 conexiones.
- Diez organizaciones requieren 45 conexiones.
- 100 organizaciones requieren 4950 conexiones.
Se puede argumentar que tal vez alguna comunicación se puede realizar por medio
de intermediarios. Si se desea hablar con la compañía B, ¿Se pueden enviar mis datos tal
vez a la compañía C que tiene un enlace con la compañía B? De esta manera ¿No se
tendría un vínculo a la compañía B de mi propiedad ?
En algunos casos, en pequeña escala, esto puede resultar. Por otro lado, esto no puede
resultar en todos incluso si está en una escala manejable. Considere una compañía que
vende un producto a diez clientes que compiten entre ellos.
- Podría alguno de ellos aceptar que sus confirmaciones de pedidos y

entregas viajen a través de las manos de uno de sus competidores?
- Difícilmente.

20.2. Introducción a la Criptografía 195
Se requiere de otra solución.
Desde la perspectiva de conectividad y seguridad, Virtual Private Networks

pueden aún ser vistas como ”fixed connections” ya que estas entregan
conectividad entre dos o más organizaciones. Este es un hecho que no cambia
aunque la Criptografía es desplegada para implementar el lado “Virtual” de la
”Private Network”.
20.2 Introducción a la Criptografía

Criptografía entrega un medio para crear ”Virtual Private Networks” a través de
internet con una inversión no adicional en cables, líneas arrendadas, u otra conectividad.
Es una expresión umbrella cubriendo tres técnicas básicas y beneficios:
Confidenciabilidad
Nadie salvo los receptores previstos son capaces de interceptar y comprender la
comunicación. La Confidenciabilidad es lograda por encriptación.
Autentificación & Integridad

Una prueba para el receptor de que la comunicación fue en realidad enviada por
el remitente esperado, y que los datos no han sido modificados en el tránsito.
Esto es logrado por la autentificación, a menudo por el uso de
Claves Criptograficas(cryptographic
keyed hashes)
No-rechazo
Una prueba de que el remitente en realidad ha enviado los datos; el remitente no
puede negarlo después de haberlo enviado. No-rechazo es usualmente un efecto
secundario benigno de autentificación.
20.2.1 Encriptación
Encriptación es un proceso de codificación de información sensible desde un texto sin
formato de texto cifrado ilegible a través de algún algoritmo matemático. La operación
de los algoritmos es variada y usualmente parametrizada por un gran número aleatorio,
conocido como clave. El texto cifrado es encriptado por la clave y necesita la misma
clave o una clave relacionada para ejecutar el procedimiento contrario –decriptación,
para volver a el texto sin formato original.
Los algoritmos de Encriptación pueden ser clasificados en tres tipos –

simétrico, asimétrico, Encriptación híbrida.

Encriptación Simétrica
En la Encriptación Simétrica, la misma clave es utilizada para tanto la encriptación

como la decriptación. Por lo tanto la clave es compartida por el remitente y los
recipientes, y debe ser mantenida en secreto. El utilizar la misma clave secreta es un
método rápido y de simple cálculo, pero la clave de distribución entre usuarios en
primer lugar es un problema mayor, el cual debe ser llevado a cabo muy cuidadosamente
para prevenir que la clave pase a manos erróneas.
Para asegurar el compartir la clave secreta, claves de sesión o claves públicas son a
menudo involucrados en la operación actual.
Una clave de sesión, como su nombre describe, es sólo válido para una sesión. Incluso
si la clave es comprometida en una sesión, esta no puede ser utilizada para una
decriptación futura. Otra solución es el uso de clave pública manejada por la
Encriptación Asimétrica presentada a continuación.
Actualmente, el algoritmo de Encriptación Asimétrica más comúnmente usado

incluye:
• DES y Triple DES
– DES utiliza una clave de 56-bit y es considerada igual en resistencia a la
mayoría de los otros algoritmos que utilizan claves de 40-bit keys. Esta es
relativamente una clave de corta longitud por estándar moderno implicando que
es actualmente considerado vulnerable a ataques de fuerza bruta.
Triple-pass DES utiliza tres claves diferentes en tres pasos DES, formando
una clave teórica de longitud de 168 bits.
• Blowfish
– Una cifra bloqueada de 64-bit con longitud de clave variable entre 32 y 448
bits.
• Twofish
– Una cifra bloqueada de 128-bit con longitud de clave de 128, 192, o 256
bits.
• CAST-128
– Una cifra bloqueada de 64-bit con una clave de 128-bit, menos frecuentemente
empleado que Blowfish.
• AES
– Una medida bloqueada de 128-bit con longitudes de clave de 128-256 bits, una
sonido alternativo al período DES.
La implementación del VPN de firewall D-Link soporta todos los algoritmos anteriores.

Encriptación Asimétrica
Un par de claves es utilizada en la Encriptación asimétrica, uno denominado clave pública,

la cual puede estar disponible para cualquiera que desee utilizar encriptación, y la otra,
denominada clave privada, que debe permanecer confidencialmente y es conocida
sólo por el dueño.
Las dos claves son números primarios muy largos y matemáticamente relacionados,
pero una no podría ser utilizada para resolver la otra. Nadie puede enviar una información
privada a un receptor, supongamos A, encriptando la información utilizando la clave pública
A s . Pero no sólo A estará capacitado para recobrar la información por la decriptación
del texto cifrado utilizando la clave privada relacionada. Además, si alguna información
conocida puede ser recuperada correctamente decriptando con la clave pública de A, ésta
debe haber sido encriptada por la clave privada de A, y por lo tanto por A. Esto significa
que el algoritmo asimétrico entrega pruebas de origen. RSA y DSA son los algoritmos
asimétricos mejor conocidos y más comúnmente utilizados.
Comparado con la Encriptación simétrica, las claves más largas causan una baja
velocidad y recurso de intensidad que el utilizado por encriptación asimétrica, y por
lo tanto es inconveniente para la Encriptación de grandes cantidades de datos. Esto es
generalmente utilizado para asesorar la distribución de clave simétrica y tareas de
Autentificación. La combinación de algoritmos simétricos y asimétricos es denominada
Hybrid Encryption.
Hybrid Encryption
La Encriptación Híbrida combina lo mejor de los dos mundos: algoritmos simétricos y

asimétricos. La clave Simétrica entrega una Encriptación y Decriptación más rápida, y
los proyectos asimétricos entregan un camino conveniente para compartir la clave
secreta.
Protocolo de intercambio de clave Diffe-Hellman:

El protocolo Diffe-Hellman permite a los usuarios intercambiar una clave secreta sobre
un medio inseguro sin secretos previos, lo cual es uno de los métodos de intercambio de
clave más generalmente utilizados soportando varios protocolos seguros de Internet
ej. SSL, SSH, e IPsec.
En el protocolo, cada lado de la conexión genera un par de claves privada-pública

relacionadas, y publica la parte pública. Luego del intercambio de clave pública, se es
capaz de calcular una nueva clave secreta utilizando la clave privada de uno y la clave
pública de otro. La clave resultante es común para ambos lados, y puede ser utilizada
como una clave secreta compartida para la encriptación simétrica. De tal modo,

la información de clave crítica no es transmitida a través de una conexión

insegura.
20.2.2 Autentificación e Integridad

En adición a la Encriptación, los métodos de Autentificación son necesarios para
asegurar la integridad y autenticidad de datos encriptados.
Se puede pensar fácilmente que la Encriptación entrega una protección suficientemente

buena; ésta después de todo asegura que la información sea transferida en un
texto cifrado ilegible. No obstante, la Encriptación no entrega ningún tipo de protección
contra la alteración de datos encriptados y nada acerca de identidad del usuario.
Si alguien puede interceptar el flujo de datos encriptados y modificarlos, el

resultado en el receptor final, luego de la decriptación, podría ser alterado. El
resultado final de las modificaciones podría seguramente ser impredecible para la
persona que intercepta el flujo de datos, pero si su meta es dañar de manera sutil,
una modificación en los datos encriptados podría ser suficiente. ¿Qué sucede si, por
ejemplo, un documento es enviado a imprimir en cientos de miles de copias, y el texto
es distorsionado en cada diez páginas?
Otro caso no deseado es el denominado ataque man-in-the-middle, en donde un

tercer personaje intercepta la clave pública desde el intercambio entre dos lados y
responde con claves falsas. De este modo, el hombre en el medio establece 2 conexiones
seguras a ambos lados, y puede decriptar sus conversaciones libremente.
Estos casos son donde el mecanismo de autentificación entra en juego. La

autentificación sirve para probar al receptor que los datos son realmente
enviados por la persona que reclama haberlo hecho. Y más importante, esta
prueba que los datos no han sido alterados luego de dejar al remitente. El
mecanismo es logrado por la utilización de Firma Digital y Certificado
Firma Digital
Una firma digital es un sello utilizado para probar la identidad de una persona, y
asegurar la integridad del mensaje original. La firma es creada utilizando el plan de
Encriptación Asimétrica; esta no puede ser imitada por nadie más, y el remitente no
puede rechazar fácilmente el mensaje que ha sido firmado.
El procedimiento de producir una firma digital trabaja como a continuación:

Por el lado del remitente:
- El remitente prepara un par de claves pública-privada, y publica la pública.
- Un tipo de función, conocido como función hash, es operado en un mensaje, y

se obtiene un mensaje resumen de longitud fija. (La función matemática
es solo en un sentido; el mensaje original no puede ser recalculado desde el
resumen y cualquier cambio al mensaje original hará al resumen
totalmente diferente.)
- El remitente encripta el mensaje de resumen utilizando la clave privada.
- El mensaje resumen encriptado se vuelve la firma digital del remitente del mensaje,
y es único para ese mensaje.
- La firma digital es enviada al receptor junto con el mensaje de texto sin formato
original.
Por el otro lado:
- El receptor utiliza la función hash para hacer un mensaje resumen del mensaje
sin formato recibido.
- Utilizando la clave pública del remitente, el receptor decripta la firma digital

para obtener el mensaje resumen calculado por el remitente.
- Los dos resúmenes son comparados.
- Si los dos resúmenes son idénticos, el mensaje recibido es válido.
Certificado
Como es introducido en 8.4 X.509 Certificados, el firewall D-Link soporta además el

certificado digital para ser utilizado para más adelante autentificar que la clave pública
realmente pertenezca a la presunta persona.
Un certificado es emitido por una autoridad de certificación (CA) contenedora de una copia
de la clave pública del poseedor del certificado e información correspondiente, un
número de serie, tiempo de expiración, y la firma digital del CA, para que un receptor
pueda verificar que el certificado es real. El certificado digital es soportado por los
Firewalls D-Link conforme al X.509 estándar.

El CA crea el certificado firmando la clave pública de autentificación y la información de

identidad del poseedor de la clave con su propia clave privada. El receptor tiene copias
de la clave pública del CA para ser capaces de validar la firma certificada y
confiar en el CA y la clave pública firmada.
El CA es además responsable de manejar el CRL para reportar el certificado que

ya no es válido debido a, por ejemplo, que la clave privada correspondiente está
comprometida o que la información de identidad ha cambiado.
20.3 Por qué VPN en Firewalls

Virtual Private Network (VPN) puede ser implementada de muchas maneras distintas.
Las grandes diferencias están en si utilizar o no las puertas de enlace de seguridad:
Dispositivos de red cuyo propósito es ejecutar el trabajo de encriptación y
autentificación. Hay tanto beneficios como inconvenientes en cada despliegue
diferente de puerta de enlace de seguridad.
La puerta de enlace de seguridad, puede ser ubicada en varias localidades

diferentes con relación a su router y su firewall:
◦ Fuera del firewall, en línea
◦ Fuera del firewall, en la red externa
◦ Entre el firewall y la red interna
◦ En la red interna
◦ En un DMZ separado
√
• Incorporado en el firewall mismo
Cada escenario anterior tiene sus distintos beneficios e inconvenientes. Los asuntos
que necesitan ser consideradas incluyen:
◦ ¿Puede el firewall proteger la puerta de enlace de seguridad e intentos de

registro de los ataques en ellos?
◦ ¿Soporta la configuración a clientes roaming?
◦ ¿Puede el firewall inspeccionar y registrar el tráfico que pasa dentro y fuera del VPN?
◦ ¿Puede la configuración añadir puntos de fallo a la conexión Internet?

20.3. Por qué VPN en Firewalls 201
◦ En casos donde la puerta de enlace VPN es localizada fuera del firewall, ¿puede
el firewall reconocer el tráfico VPN protegido desde el tráfico Internet de texto sin
formato, de modo que este conoce qué pasa a través de la red interna?
◦ Requiere esto una configuración adicional al firewall o anfitriones participantes

en el VPN?
En los firewalls D-Link, la Puerta de enlace de Seguridad VPN es integrada en el firewall

mismo. La razón de este diseño puede ser encontrada en el análisis de escenario
presentado a continuación.
20.3.1 Despliegue VPN

Fuera del Firewall, En línea
(Figura 20.1)
Figura 20.1: Despliegue VPN Escenario 1
♦ Beneficios
• Soporta clientes roaming, aunque sea dificultoso
• No se necesita información especial de routing en el firewall
• El firewall puede ser inspeccionar y registrar texto sin formato desde el VPN
♦ Inconvenientes
• La Puerta de enlace de Seguridad no es protegida por el firewall
• El firewall no puede fácilmente determinar qué tráfico viene a través de un VPN

Autentificado y cual proviene desde el Internet, especialmente en el caso de
clientes roaming
• La conectividad Internet depende de la Puerta de enlace de Seguridad

Fuera del Firewall, en la Red Externa
(Figura 20.2)
♦ Beneficios
• La conectividad Internet no depende de la Puerta de enlace de Seguridad
• El firewall puede inspeccionar y registrar el texto sin formato desde el VPN
♦ Inconvenientes
• La Puerta de Enlace de Seguridad no es protegida por el firewall
• El firewall no puede fácilmente determinar qué tráfico viene a través de un VPN

Autentificado y cuál proviene desde el Internet, a menos que el router
pueda ser confiable para hacer un filtro extensivo.
• Se necesita información especial de routing en el firewall
• El soporte de clientes roaming es casi imposible
Entre el Firewall y la Red Interna
(Figura 20.3)
♦ Beneficios
• Soporta clientes roaming
• No se necesita información especial de routing en el firewall
• El firewall puede proteger la Puerta de Enlace de Seguridad
♦ Inconvenientes

• La conectividad Internet depende de la Puerta de Enlace de Seguridad
• El firewall no puede inspeccionar ni registrar el texto sin formato desde el VPN
El tráfico VPN no debe normalmente ser considerado para ser una parte incorporada de
la red interna.
En la Red Interna
(Figura 20.4)
♦ Beneficios
• La conectividad Internet no depende de la Puerta de Enlace de Seguridad
♦ Inconvenientes
• El firewall no puede inspeccionar o registrar el texto sin formato desde el VPN
• Se necesitan añadir rutas especiales al firewall o a todos los clientes internos

participantes en el VPN
• El soporte para clientes roaming es muy difícil de conseguir

En un DMZ separado
(Figura 20.5)
♦ Beneficios
• La conectividad Internet no depende de la Puerta de Enlace de Seguridad
♦ Inconvenientes
• Se necesitan añadir rutas especiales al firewall
• El soporte a clientes roaming es muy difícil de conseguir, ya que el firewall no

sabe dirigir a través de la Puerta de Enlace de Seguridad con el fin de
alcanzar los clientes VPN con IPs móviles
Incorporado en el Firewall
(Figura 20.6)
♦ Beneficios
• El firewall puede proteger el subsistema de Puerta de Enlace de Seguridad
• Soporta clientes roaming

• No se necesitan añadir rutas especiales para anfitriones participantes en el VPN
• Puede integrar a la perfección VPN y políticas firewall
♦ Inconvenientes
• La Puerta de Enlace de Seguridad integrada puede hacer al firewall menos estable.

Sin embargo, este no añade otras piezas de hardware a la cadena de puntos
que pueden fallar.
Esta solución entrega el mas alto nivel de funcionalidad & seguridad y es elegida por
los diseños D-Link. Todos los modos normales de operación son soportados y todo el
tráfico debe ser inspeccionado y registrado por el firewall.

CAPITULO 21
Planificación VPN
21.1 Consideraciones de Diseño VPN

”Una cadena no es nunca más fuerte que su eslabón más débil”.
Un agresor que desea hacer uso de una conexión VPN no intentará romper la
Encriptación VPN, ya que esto requiere grandes cantidades de cálculos y tiempo.
mas bien, él/ella verá el tráfico VPN como una indicación de que hay algo realmente
liviano en el otro extremo de la conexión. Usualmente, los clientes móviles y
sucursales son blancos más atractivos que las redes corporativas principales. Una vez
dentro de éstos, ingresar a una red corporativa se vuelve una tarea mucho más fácil.
Al diseñar un VPN, hay muchos asuntos no-obvios que necesitan ser tratados.
Estos incluyen:
• La protección de computadores móviles y de hogar.
• La restricción de acceso a través de VPN a sólo servicios necesitados, ya que

los computadores móviles son vulnerables.
• La creación de DMZ para servicios que necesitan ser compartidos con otras
compañías a través de VPN.
• La adaptación de políticas de acceso VPN para diferentes grupos de usuarios.
• La creación de políticas de distribución de claves.
207
208 Capítulo 21. Planificación VPN
Una idea equivocada común es que las conexiones VPN son equivalentes a la
red interna desde el punto de vista de la seguridad y que se pueden conectar
directamente sin mayores precauciones.
Es importante recordar que aunque la conexión VPN misma puede ser segura,
el nivel total de seguridad es sólo tan alto como la seguridad de los puntos finales
del túnel.
Se vuelve cada vez más común para los usuarios en movimiento conectarse
directamente la red de sus compañías vía VPN desde sus laptops. Sin embargo,
el laptop mismo no es a menudo protegido. En otras palabras, un intruso puede ganar
acceso a la red protegida a través de un laptop no protegido y conexiones VPN
ya abiertas.
En conclusión, una conexión VPN no debe ser considerada como parte integral de una
red protegida. La puerta de enlace VPN debe en cambio ser localizada en un DMZ
especial o fuera del firewall dedicado a esta tarea. Haciendo esto, se puede restringir
cuál servicio puede ser accedido vía VPN y módem y asegurar que estos servicios
estén bien protegidos contra intrusos.
En casos donde el firewall ofrece una puerta de enlace VPN integrada, es

usualmente posible dictar los tipos de comunicación permitidos. El módulo VPN
D-Link ofrece tal facilidad.
21.1.1 Seguridad en Punto de Término

Una precaución básica a tomar en la protección de su red contra ataques a módem y
conexión VPN es asegurar que los usuarios roaming jamás se comunican directamente
con el Internet. En cambio, ellos siempre son dirigidos a través de la conexión VPN o
módem y la red de la compañía, independiente de con quién se desean comunicar. De
este modo disfrutan mas o menos el mismo nivel de protección que el resto de la red.
Para las conexiones VPN, un cliente VPN competente que puede bloquear todo
el tráfico Internet entrante, aparte de aquel que pasa a través de la conexión VPN, debe
ser instalado en cada computador portátil o de hogar.
Es también importante recordar que las mismas restricciones colocadas en los

computadores de hogar deben ser colocadas también el los computadores
portátiles y de hogar que acceden a la red corporativa. Actualmente, las restricciones
más altas deben ser colocadas en los clientes roaming.

21.1. Consideraciones de Diseño VPN 209
Puntos finales de Seguridad para computadores pertenecientes a la Compañía.
Los puntos importantes que son a menudo incluidos en las políticas de acceso remoto
incluyen:
• Un software anti-virus es necesario de instalar y actualizar a través de la conexión
remota.
• Se debe elegir un sistema operativo multi-usuario donde las capacidades

finales del usuario pueden ser restringidas.
• NO ajuste el cliente VPN/dialup para recordar automáticamente secretos

compartidos, contraseña de acceso discado, o certificados, a menos que tales
datos sean protegidos por contraseña utilizando una encriptación fuerte.
Cualquier vendedor que diga ser capaz de asegurar tales datos sin que el usuario
ingrese una contraseña, utilizando una tarjeta electrónica o suministrando cualquier
tipo de información, no está diciendo la verdad.
• Si el cliente VPN ofrece un método para recordar todas las contraseñas sin
tener que suministrar el usuario cualquier información, deshabilite tal característica.
Si no, tarde o temprano, alguien marcará ese recuadro, y si/cuando el computador
portátil es robado, el ladrón tundra una ruta de acceso directo a la red
corporativa.
• Aplique y refuerce las mismas políticas que en los computadores de hogar. Tales
políticas usualmente incluyen:
- La no descarga de software desde el Internet

- No juegos
- No prestar el computador a amigos u otros
• Inspecciones de programas de todos computadores portátiles/de hogar para

verificar la conformidad con todo lo anterior. Este proceso puede usualmente
ser automatizado en buena medida e incluso llevado a cabo a lo largo de
la conexión remota. Unos pocos archivos de escritura verán usualmente que no
hay software adicional instalado y que las claves de registro que contienen
valores para recordar contraseñas etc. no han sido cambiados.
• Mantiene los datos almacenados localmente en computadores portátiles a

un mínimo para reducir el impacto del hurto. Esto incluye carpetas de e-mail cache.
Actualmente, puede ser lo mejor si el mail es leído a través la web gateway, ya que
ésto deja la minima cantidad de archivos en almacenaje local.

210 Capítulo 21. Planificación VPN
• Si los requisitos anteriores no pueden ser logrados, por ejemplo, en casos donde
el computador de hogar pertenece al empleado, no se garantiza el acceso VPN.
Seguridad de Punto de término para Compañeros y otras Compañías
Este tema es usualmente más sensible que el asegurar computadores que son
actualmente pertenecientes a la compañía. En casos donde la administración ha dictado
que VPN debe ser establecido con un compañero, subsidiario, ó subcontratista
que tiene políticas de seguridad mucho más relajadas, se vuelve una real pesadilla para
el staff IT.
Es lejos de ser poco común para intrusos motivados investigar compañías

como si tuvieran conexión con sus objetivos, virtuales entre otros. Debería el objetivo
de seguridad ser muy alto, este puede probar ser más fructífero para descubrir otras
localizaciones pueden ser alcanzadas para lanzar un ataque sobre los perímetros
de defensa.
En casos donde la seguridad de la red remota no puede ser garantizada,

técnica y/o físicamente, puede ser una buena idea mover recursos compartidos
a servidores en un DMZ separado y ganar acceso remoto a solo a estos servidores.
21.1.2 Distribución de Clave

Planifique sus tareas de distribución hacia delante del tiempo. Asuntos que necesitan
ser dirigidos incluyen:
• ¿Por qué medios distribuir las claves? Email no es una buena idea.
Conversaciones telefónicas pueden ser suficientemente seguras. Esto depende
de sus políticas de seguridad local.
• ¿Cómo pueden ser utilizadas las diferentes claves? ¿Una clave por usuario?¿Una
clave por grupo de usuario? ¿Una clave por conexión LAN-to-LAN?¿Una clave
para todos los usuarios y una clave para todas las conexiones LAN-to-LAN? Usted
estará probablemente mejor utilizando más claves de las que usted considera
necesarias hoy en día, ya que ésto se vuelve fácil para ajustar el acceso por usuario
(grupo) en el futuro.
• ¿Deben las claves ser modificadas? Si es así, qué tan a menudo? En casos
donde las claves son compartidas con múltiples usuarios, usted puede desear
considerar proyectos superpuestos, de modo que las claves antiguas trabajen por
un pequeño período de tiempo cuando las claves nuevas han sido establecidas.

21.1. Consideraciones de Diseño VPN 211
• ¿Qué sucede cuando un empleado en posesión de una clave deja la

compañía? Si varios usuarios están utilizando la misma clave, ésta debe
ser modificada por supuesto.
• En casos donde la clave no está directamente programada a una unidad de red

tal como un VPN gateway, ¿Cómo debe ser almacenada la clave? ¿Debe estar en
un floppy? ¿Cómo una frase de paso a memorizar? ¿En una tarjeta electrónica?
¿Si es físicamente tomada, cómo debe ser administrada?

CAPITULO 22
Protocolos & Tuneles VPN
22.1 IPsec
IPsec, Internet Protocol Security, es un grupo de protocolos definidos por el
IETF(Internet Engineering Task Force) para entregar seguridad IP a la capa de red.
Es el estándar más generalmente utilizado para implementar.
IPsec es diseñado para trabajar para todos los tráficos, independiente de la aplicación.
Esta propuesta resulta en la ventaja de que ninguna aplicación ni usuarios necesitan
conocer ningún detalle acerca de la encriptación.
IPsec utiliza el protocolo de intercambio de clave Diffie-Hellman y encriptación asimétrica

para establecer identidades, algoritmos preferidos, y una clave asimétrica. Luego, el
algoritmo utiliza el plan de encriptación simétrica para encriptar datos cuando son
transferidos.
Antes de que IPsec pueda comenzar con la encriptación y transferencia del flujo de datos,
se necesita una negociación preliminar. Esto es logrado con el Internet Internet
Key Exchange Protocol (IKE).
En resumen, un VPN basado en IPsec, tal como D-Link VPN, es realizado en dos partes:
• Internet Key Exchange protocol (IKE)
• Protocolos IPsec (AH/ESP/both)
213
214 Capítulo 22. Protocolos & Túneles VPN
La primera parte, IKE, es la fase de negociación inicial, donde los dos puntos finales
VPN concuerdan en cuáles métodos serán utilizados para entregar seguridad para el
tráfico IP subyascente. Además, IKE es utilizado para administrar conexiones
definiendo un grupo de Asociaciones de Seguridad, SAs, para cada conexión. SAs es
unidireccional, de modo que habrán al menos dos SAs por conexión.
La segunda parte es la actual transferencia de datos IP, utilizando los métodos de

Encriptación y autentificación acordados en la negociación IKE. Esto puede ser
logrado por varios caminos; utilizando protocolos IPsec ESP, AH, o una combinación
de ambos.
El flujo de operación puede ser brevemente descrita como lo siguiente:
• IKE negocia cómo IKE debe ser protegido
• IKE negocia cómo IPsec debe ser protegido
• IPsec mueve datos en VPN
22.1.1 Protocolos IPsec

Existen dos tipos primarios de protocolo IPsec: el protocolo de Encapsulating Security
Payload (ESP) y el protocolo de Authentication Header (AH).
ESP
ESP entrega tanto autentificación y encriptación a los paquetes de datos.
AH
AH entrega solo autentificación pero no encriptación a los paquetes de datos.
AH no entrega confidenciabilidad a la transferencia de datos y es raramente utilizado;

éste NO es soportado por los Firewalls D-Link.
Dónde o no modifica el protocolo IPsec al header IP original depende de los modos

IPsec.
22.1.2 Modos de Encapsulación IPsec

IPsec soporta dos modos diferentes: Modos de Transporte y Túnel.
Modo de Transporte – encapsula los datos del paquete y deja el header IP sin
modificación, lo cual es típicamente utilizado en un escenario cliente-a-puerta de enlace.

22.1. IPsec 215
Modo Túnel – encapsula el header IP y payload en un nuevo paquete IPsec

para transferencia, lo cual es comúnmente utilizado en el escenario IPsec puerta de
enlace-a-puerta de enlace.
En el modo de transporte, el protocolo ESP inserta un header ESP luego del header
IP original, y en el modo túnel, el header ESP es insertado luego de un nuevo
header IP externo, pero antes del header IP original, interior. Todos los datos luego
del header ESP son encriptados y/ó autentificados.
22.1.3 IKE
La encriptación y Autentificación de datos es bastante sencillo. Las únicas cosas
necesarias son los algoritmos de encriptación y autentificación, y las claves utilizadas
con éstos. El protocolo de Intercambio de Clave Internet, IKE, es utilizado como un
método de distribución de estas “claves de sesión”, así como para proveer un camino
para que los puntos de término VPN acuerden cómo los datos deben ser
protegidos.
IKE tiene tres tareas principales:
• Entrega un medio para que los puntos de término se autentifiquen entre sí

mismos.
• Establece nuevas conexiones IPsec (0c1rea pares SA)
• Administra conexiones existentes
IKE mantiene el rastro de conexiones asignando un paquete de Asociaciones de

Seguridad, SAs, a cada conexión. Un SA describe todos los parámetros asociados
a una conexión particular, incluyendo cosas como el protocolo IPsec utilizado
(ESP/AH/ambos), las claves de sesión utilizadas para encriptar/decriptar
y/ó autentificar los datos transmitidos. Un SA es, por naturaleza, unidireccional,
por lo tanto necesita de más de un SA por conexión. En la mayoría de los casos, en
donde solo un ESP ó HA es utilizado, serán creados dos SAs para cada conexión,
uno para el tráfico entrante, y el otro el saliente. En casos donde el ESP y HA son utilizados
en conjunto, serán creados cuatro SAs.
Negociación IKE
El proceso de parámetros de negociación de conexión consiste principalmente en dos

fases:
IKE Fase-1
– Negocia cómo debe ser protegido IKE para futuras negociaciones.

• Autentifica los grupos de comunicación, tanto con claves pre-compartidas

(PSK) o certificado.
• Intercambia los materiales de enclave con método Diffie-Hellman.
• Son creados SAs IKE.
IKE Fase-2
– Negocia cómo debe ser protegido IPsec.
• Crea un par de SAs IPsec utilizando el SAs IKE desde la fase-1,

detallando los parámetros para la conexión IPsec.
• Extrae el Nuevo material de enclave desde el intercambio de clave
Diffie-Helman en fase-1, para que la clave de sesión lo utilice en el flujo
protegido de datos VPN.
Tanto el SAs IKE SAs y el SAs IPsec tiene tiempos de vida limitados, descritos como
tiempo (segundos), y datos (kilobytes). Estos tiempos de vida previenen que una conexión
sea utilizada mucho, lo cual es conveniente desde una perspectiva del
criptanálisis.
La fase-1 IKE involucra un cálculo muy grande, ya que sus tiempos de vida son
generalmente más largos que los tiempos de vida de la fase-2 IPsec. Esto permite que la
conexión IPsec sea re-codificada simplemente ejecutan otra negociación de
fase-2. No hay necesidad de hacer otra fase-1 de negociación hasta que el tiempo de
vida SAs IKE haya expirado.
Modos de Negociación
La negociación IKE tiene dos modos de operación, modo principal y modo
agresivo.
La diferencia este estos dos es que el modo agresivo pasará más información en
menos paquetes, con el beneficio de un establecimiento de conexión ligeramente mas
rápido, al costo de transmitir las identidades de las puertas de enlace de seguridad
fuera de peligro.
Cuando se utiliza el modo agresivo, algunos parámetros de configuración, tales como,

Grupos Diffie-Hellman, no pueden ser negociados, resultando de mayor importancia
el tener configuraciones “compatibles” en ambos extremos de comunicación.

22.1. IPsec 217
Algoritmos IKE & IPsec
Hay un número de algoritmos utilizados en los procesos de negociación.

El comprender qué hacen estos algoritmos es esencial antes de intentar
configurar los puntos de término VPN, ya que es de gran importancia que ambos
extremos sean capaces de acordar en todas estas configuraciones.
Encriptación IKE & IPsec

El flujo de datos transferido en las conexiones VPN es encriptando utilizando
un plan de encriptación simétrica.
Como es descrito en 20.2.1 Encriptación Simétrica, los firewalls D-Link soportan los algoritmos
enlistados a continuación:
• DES
• 3DES
• Blowfish
• Twofish
• CAST-128
• AES
DES es solo incluido para ser interoperable con algunas antiguas implementaciones
VPN. La utilización de DES debe ser evitada siempre que sea posible, ya que este es un
algoritmo antiguo que ya no es considerado como seguro.
Perfect Forward Secrecy (PFS)

Perfect Forward Secrecy (PFS) es una propiedad opcional de las negociaciones IKE.
Cuando es configurado PFS, las claves que protegen la transmisión de datos no son
utilizadas para obtener claves adicionales, y el material de enclave utilizado para crear
las claves de transmisión de datos no son reutilizadas.
PFS puede ser utilizado de dos modos, el primero es PFS en claves, donde un nuevo
intercambio de clave será ejecutado en cada fase-2 de negociación, esto es, un
intercambio Diffie-Hellman para cada negociación SA IPsec. El otro tipo es PFS en
identidades, donde las identidades son además protegidas, borrando la fase-1 SA
cada vez que la fase-2 de negociación ha finalizado, asegurando que no más de una
fase-2 de negociación sea encriptada utilizando la misma clave.
IKE crea una nueva SA para cada SA IPsec necesitada.

PFS es con gran consumidor de recursos y tiempo y es generalmente deshabilitado, ya

que no se desea que ninguna clave de encriptación o autentificación sea
comprometida.
Intercambio de clave
IKE intercambia la clave de encriptación simétrica utilizando el protocolo Diffie-Hellman
de intercambio de clave. El nivel de seguridad que éste ofrece es configurable
especificando el grupo Diffie-Hellman(DH).
Los grupos Diffie-Hellman soportados por el VPN D-Link son:
• DH grupo 1 (768-bit)
La seguridad del intercambio de clave aumenta en la medida que los grupos DH

crecen, así como lo hace el tiempo de los intercambios
NAT Transversal
Un gran problema encontrado por los protocolos IKE e IPsec es la utilización de NAT,
Ya que los protocolos IKE e IPsec no están diseñados para trabajar a través de redes
NATed. Debido a ésto, se ha desarrollado algo denominado como ”NAT transversal ”.
NAT transversal es un complemento a los protocolos IKE e IPsec que los hace trabajar
cuando son NATed.
En resumen, NAT transversal es dividido en dos partes:
• Adición a IKE que deja a los pares IPsec coordinar entre ellos que soportan
NAT transversal, y las versiones específicas del proyecto que éstas soportan.
• Modificaciones a la encapsulación ESP. Si es utilizado NAT transversal, ESP es

encapsulado en UDP, lo cual permite un NATing más flexible.
NAT transversal es solo utilizado si ambos extremos tienen soporte para éste.
con este propósito, NAT transversal espera que VPNs envíe un ”vendedor ID” especial,
que diga al otro extremo que sí comprende NAT transversal, y cuáles versiones
específicas del proyecto soporta.
Para detectar la necesidad de utilizar NAT transversal, ambos pares IPsec envían
hashes de sus propias direcciones IP junto con la fuente de puerto UDP utilizado en las
negociaciones IKE. Esta información es utilizada para ver si la dirección IP

22.1. IPsec 219
y puerto de fuente de cada par que utiliza es la misma que el otro par ve.
Si la dirección de fuente y puerto no se ha modificado, el tráfico no ha sido NaTed en el
camino, y NAT transversal no es necesario. Si la dirección de fuente y/o puerto ha cambiado,
el tráfico ha sido NATed, y el NAT transversal es utilizado.
Una vez que el par IPsec ha decidido que NAT transversal es necesario, la negociación IKE
es movida fuera del Puerto UDP 500 a Puerto 4500. Esto es necesario ya que ciertos
dispositivos NAT tratan paquetes UDP al Puerto 500 de manera diferente desde otros paquetes
UDP en un esfuerzo por trabajar alrededor de los problemas NAT con IKE. El problema
es que este manejo especial de paquetes IKE puede en efecto romper las negociaciones
IKE, lo cual es el por qué el Puerto UDP utilizado por IKE ha sido modificado.
Otro problema que resuelve NAT transversal es con respecto al protocolo ESP.
El protocolo ESP es un protocolo IP y no hay información de puerto como en TCP y
UDP, lo cual hace imposible tener más de un cliente NATed conectado a la misma
puerta de enlace remota al mismo tiempo. Para resolver este problema, los paquetes ESP
son encapsulados en UDP. El tráfico ESP-UDP es enviado al puerto 4500, el mismo puerto
que IKE cuando es utilizado NAT transversal. Una vez que el puerto ha sido modificado,
todas las comunicaciones IKE siguientes son realizadas sobre el Puerto 4500. Los paquetes
mantenidos con vida son además enviados periódicamente para mantener el mapeo NAT
con vida.
22.1.4 Integridad & Autentificación IKE

En la fase de negociación IKE, la Autentificación a los extremos comunicativos es
llevada a cabo antes de cualquier transferencia actual de datos, y la integridad del mensaje
negociado debe ser asegurada por algoritmos matemáticos. Los VPNs D-Link incluyen
varios métodos para lograr estas tareas críticas, ej., funciones hash para integridad de
mensaje, claves pre-compartidas y certificados X.509 basado en algoritmos de
encriptación asimétrica (ej. RSA, DSA ) para verificar identidades.

Hashing para Integridad
Para asegurar el mensaje de integridad durante la negociación IKE, algunas

funciones hash son utilizadas por los firewalls D-Link para entregar resúmenes de
mensajes para diferentes métodos de autentificación. El mecanismo de hashing
asegura que los mensajes no modificados llegar al otro extreme de la
transmisión.
Los firewalls D-Link ofrecen las dos funciones hash siguientes:
• SHA-1 – 160-bit mensaje resumen.
• MD5 – 128-bit mensaje resumen, más rápido que SHA-1 pero menos seguro.
Clave pre-compartida (PSK)
La clave pre-compartida es uno de los dos métodos de autentificación primarios

soportados por los VPN D-Link. Con la autentificación de la clave pre-compartida,
una clave simétrica idéntica debe ser manualmente configurada en ambos sistemas. La
clave pre-compartida es una frase de paso secreta, normalmente una serie de caracteres
ASCII o un set de números Hexadecimales aleatorios. En los VPN D-Link, el usuario
puede tanto ingresar una contraseña ASCII como utilizar generación de clave aleatoria
automática. Ambos extremos necesitan tener la misma clave definida y la clave
debe ser mantenida en secreto.
La clave pre-compartida es utilizada solo para la autentificación primaria; las dos

entidades negociantes luego generan claves de sesión dinámica compartida para el
SAs IKE y SAs IPsec.
Las ventajas de utilizar PSK son: primero, las claves pre-compartidas no requieren una
Autoridad de Certificación(CA) central ó CAs para tareas de autentificación; segundo ésta
entrega un medio de Autentificación de puntos de término primario, basado en qué, pueden
implementar las futuras negociaciones IKE para claves de sesión dinámica. Las claves de
sesión serán utilizadas por un período de tiempo limitado, donde luego un conjunto nuevo
de claves de sesión son utilizados.
Sin embargo, una cosa que debe ser considerada cuando se utiliza PSK es la
distribución de clave. ¿Cómo son distribuidas las claves pre-compartidas para clientes
VPN remotos y puertas de enlace? Este es un asunto mayor, ya que la seguridad del
sistema PSK está basado en que los PSK se mantengan en secreto. Un PSK debe ser
comprometido de alguna manera, la configuración necesitará ser modificada para utilizar
un nuevo PSK.
22.1. IPsec 221
Certificado X.509
La otra opción para Autentificación primaria es utilizar Certificado X.509 dentro de cada
puerta de enlace VPN. Para probar la identidad, cada puerta de enlace tiene un
certificado propio firmado por un CA confiable. El certificado prueba que la clave
pública añadida a éste realmente pertenece a la puerta de enlace del titular, y cada
puerta de enlace además tiene una copia de la clave pública del CA para ser capaz de
confiar en el CA y validar los certificados de otras puertas de enlace establecidas para
ése CA.
Comparado al uso de PSK, los certificados son más flexibles. Muchos clientes VPN,
por ejemplo, pueden ser administrados sin tener la misma clave pre-compartida
configurada en todos ellos, lo cual es a menudo el caso cuando se utilizan claves pre-
compartidas y clientes roaming. A cambio, un cliente debe ser comprometido, el
certificado del cliente puede simplemente ser revocado. No se necesita re-configurar
cada cliente. Pero a este método se le añade complejidad. Un certificado basado en
Autentificación puede ser utilizado como parte de una gran infraestructura, haciendo a
todos los clientes VPN y puertas de enlace dependientes de terceros. En otras palabras,
hay más cosas que deben ser configuradas, y hay más cosas que pueden salir mal.
Listas de Identificación (Listas ID)
Cuando un certificado X.509 es utilizado como método de autentificación, el firewall

aceptará todas las puertas de enlace remoto ó clientes VPN que son capaces de presentar un
certificado firmado por cualquiera de las Autoridades de Certificación(CAs) confiables. Ésto
puede ser un problema potencial, especialmente cuando se utilizan clientes roaming.
Considere un escenario donde los empleados en curso deben tener acceso a las redes
internas corporativas utilizando clientes VPN. La organización administra su propio
CA, y los certificados son establecidos para los empleados. Diferentes grupos de empleados
tienen probablemente acceso a diferentes partes de las redes internas. Por ejemplo,
miembros de fuerzas de venta necesitan acceso a servidores corriendo el orden de sistema,
mientras ingenieros técnicos necesitan acceso a base de datos técnicas.
Cuando las direcciones IP de empleados viajeros clientes VPN no pueden ser

previstos, las conexiones entrantes VPN de los clientes no pueden ser diferenciados.
Esto significa que el firewall es incapaz de controlar el acceso a varias partes de las
redes internas.
El concepto de Listas de Identificación (Listas ID) presenta una solución a este

problema. Una lista de identificación contiene una o más identidades (IDs) configurables,

donde cada identidad corresponde al campo de tema en un certificado

X.509. Las listas de Identificación pueden por lo tanto ser utilizadas para regular qué
Certificado X.509 tiene acceso ganado a cuál conexión IPsec.
LDAP
LDAP, abreviación para Lightweight Directory Access Protocol, es un set de protocolos

para el acceso y descarga de directorios de información. LDAP soporta TCP/IP,
lo cual es necesario para cualquier tipo de acceso Internet. Éste es utilizado para
varias aplicaciones corriendo en diferentes plataformas computacionales para
obtener información desde un servidor LDAP, tal como la descarga de certificado y
registro CRL. El servidor LDAP mantiene el certificado de Autoridad de Certificación,
el Certificado de Revocación de Lista(CRL), y el certificado de usuario final. La
dirección del servidor LDAP puede ser configurada en cada punto de término VPN.
IKE XAuth
IKE Extended Authentication (XAuth), es una característica extendida para mejorar la

autentificación IKE estándar.
XAuth no reemplaza IKE; esto ocurre luego de la fase-1 de negociación IKE, pero
antes de la fase-2 de negociación SA IPsec IKE. Antes de XAuth, IKE sólo
soporta la Autentificación del dispositivo, no la autentificación del usuario que utiliza
el dispositivo. Con XAuth, IKE puede ahora autentificar los usuarios luego de que el
dispositivo ha sido autentificado durante la fase-1 de negociación. Si es habilitado una
combinación de nombres de usuario & contraseña será solicitada para añadir la
autentificación del usuario.

22.1. IPsec 223
22.1.5 Escenarios: Configuración IPsec
Ejemplo: Configurando un Túnel IPsec LAN-a-LAN
Figura 22.1: Escenario ejemplo LAN-a-LAN.
Este ejemplo describe cómo configurar un túnel IPsec LAN-a-LAN, utilizado para
conectar una sucursal a la red de la oficina central.
La red de la oficina central utiliza el span de red 10.0.1.0/24 con un IP de firewall

externo ip head wan. La sucursal utiliza el span de red 10.0.2.0/24 con el IP de firewall
externo ip branch wan.
Se debe realizar la siguiente configuración tanto en el firewall de la oficina central

como en el de la sucursal.

WebUI
:
1. Clave pre-compartida
Antes que todo se necesita crear una clave pre-compartida para utilizar con la
autentificación IPsec.
Objects → VPN Objects → Pre-Shared Keys → Add → Pre-Shared
Key:
Ingrese lo siguiente
Name: Ingrese un nombre para la clave pre-compartida, TestKey por ejemplo.
Passphrase/Shared Secret: Ingrese una frase de paso secreta.
Passphrase/Confirm Secret: Ingrese la frase de paso nuevamente.
2. Túnel IPsec
El siguiente paso es configurar el túnel IPsec.

Interfaces → IPsec Tunnels → Add → IPsec Tunnel:
→ General
Name: IPsecTunnel
Local Network: Esta es la red local a la que los usuarios remotos se conectarán.
De modo que en el firewall de la oficina central se utilizará 10.0.1.0/24 y en el
firewall de la sucursal se utilizará 10.0.2.0/24.
Remote Network: Esta es la red desde la que los usuarios remotos se conectarán.
De modo que en el firewall de la oficina central se utilizará 10.0.2.0/24 y en el
Firewall de la sucursal se utilizará 10.0.1.0/24.
Remote Endpoint: Esta es la IP pública de cada firewall, donde el túnel será
terminado. Esto significa que el firewall de la oficina central utilizará
ip branch wan y el firewall de la sucursal utilizará ip head wan.
Encapsulation Mode: Tunnel
Algoritmos
IKE Algorithms: Medium or High
IPsec Algorithms: Medium or High
→ Authentication
Pre-Shared Key: Seleccione la clave pre-compartida creada anteriormente, TestKey en
este caso.

22.1. IPsec 225
3. Configurar Ruta
El siguiente paso es configurar la ruta al túnel IPsec.

Interface: IPsecTunnel
Network: En el firewall de la oficina central 10.0.2.0/24 y en el firewall de la sucursal
10.0.1.0/24.
4. Configurar Reglas
Finalmente se necesita configurar las reglas para permitir el tráfico dentro del túnel.
Ver 14.3 Configuración de Reglas IP para detalles de cómo configurar las reglas.
Ejemplo: Configurando un Túnel IPsec para Clientes Roaming
Figura 22.2: Escenario Ejemplo para Clientes Roaming IPsec.
Este ejemplo describe cómo configurar un túnel IPsec, utilizado por clientes roaming
(usuarios móviles) que se conectan a la oficina central para ganar acceso remoto.
La red de la oficina central utiliza el span de red 10.0.1.0/24 con firewall IP externo
ip wan.

Se necesita realizar la siguiente configuración en el firewall de la oficina central.
WebUI
:
Antes que todo se necesita crear una clave pre-compartida a utilizar para la
Key:
Name: Ingrese un nombre para la clave pre-compartida, SecretKey por ejemplo.
Passphrase/Shared Secret: Ingrese una frase de paso secreta.
Passphrase/Confirm Secret: Ingrese la frase secreta nuevamente.

22.1. IPsec 227
2. Túnel IPsec
El siguiente paso es configurar el tunnel IPsec.

→ General
Name: RoamingIPsecTunnel
Local Network: 10.0.1.0/24 (Esta es la red local a la que se conectarán los usuarios
roaming)
Remote Network: El firewall ve este campo y lo compara con la dirección de fuente
IP del usuario roaming con el fin de permitir las conexiones solo desde la net local
configurada a la net remota. Sin embargo, en este escenario, los clientes deben ser
capaces para roam desde cualquier lado. De este modo, este campo es ajustado a
todas las nets (0.0.0.0/0). Este significa que virtualmente todas las direcciones IPv4
existentes son capaces de conectarse.
Remote Endpoint: (None)
Encapsulation Mode: Tunnel
Algoritmos
IKE Algorithms: Medium or High
IPsec Algorithms: Medium or High
→ Authentication
Pre-Shared Key: Seleccione la clave pre-compartida creada anteriormente, SecretKey
en este caso.
→ Routing
Automatic Routing
El túnel IPsec necesita ser configurado para añadir dinámicamente rutas a la
red remota cuando el túnel es establecido. Esto es realizado bajo la etiqueta de
Routing. Añadir Dinámicamente ruta a la red remota cuando un túnel es
establecido: Enable
3. Configurar Reglas
Finalmente se necesita configurar las reglas para permitir el tráfico dentro del túnel.
Ver 14.3 Configuración de Reglas IP para detalles sobre cómo configurar las reglas.

22.2 PPTP/ L2TP

Como fue introducido en las secciones previas, IPsec entrega métodos para que dos
puntos de término transporten paquetes de datos cuando éstos están conectados por
un “canal privado”. Tal técnica es a menudo llamada Tunneling. Como las funciones de
IPsec que se han discutido, los protocolos de tunneling ofrecen el estándar para
encapsulación, transmisión, y decapsulación del proceso de transferencia de datos.
Los puntos de término del túnel deben acordar en el mismo protocolo de tunneling para
ser capaces de comunicarse.
IPsec ofrece la encapsulación ESP de modo Túnel con encriptación y autentificación y

se vuelve extensamente utilizado para implementaciones VPN muy seguras.
Sin embargo hay algunas limitaciones en utilizar tunneling IPsec, por ejemplo, no
es soportado por todos los sistemas y puede ser difícil de configurar.
En contraste, los protocolos de tunneling PPTP y L2TP son generalmente soportados y

de una configuración más fácil que IPsec.
22.2.1 PPTP
Point-to-Point Tunneling Protocol(PPTP) es construído en el protocolo Point-to-Point
(PPP), Generic Routing Encapsulation (GRE), y TCP/IP.
Formato de tunneling PPTP
PPTP cuenta con el protocolo PPP para encapsular datagramas (ver 9.4.1
PPP). La estructura PPP es luego encapsulada en paquetes GRE con información de
routing incluída, lo cual es sucesivamente empaquetado con un header IP de acuerdo
a la convención de direccionamiento Internet, mostrado en la Tabla 22.1. La
estructura de Capa 2 es la unidad básica de transporte. El trailer y header de capa Data-link
son puestos en el paquete encapsulados PPTP para formar el tunneling de datos.
PPTP utiliza puerto TCP 1723 para su control de conexión y GRE ( protocolo 47
IP) para los datos PPP.
IP Header GRE Header PPP Payload
PPP Frame
Tabla 22.1: Encapsulación PPTP

22.2. PPTP/ L2TP 229
Autentificación PPTP
La Autentificación como una opción en PPTP es derivado directamente desde PPP, tal
como:
• Password Authentication Protocol (PAP)
• Challenge Handshake Authentication Protocol (CHAP)
• Microsoft CHAP version 1 y version 2
PAP es un proyecto de Autentificación sin formato que solicita y envía nombre de

usuario y contraseña en texto sin formato. Por lo tanto no es resistente al
ataque Man-in-the-middle y ataque diccionario cuando la contraseña del cliente
de acceso remoto puede ser fácilmente interceptado y determinado. Además, PAP
NO ofrece protección contra repetición de ataques y spoofing.
CHAP utiliza algoritmo MD5 para hash un desafío y proteger contra repetición de ataques
utilizando una serie de cuestionamientos arbitrarios por intento de autentificación.
Esto es mejor que PAP ya que la contraseña jamás es enviada sobre el link.
En cambio, la contraseña es utilizada para crear el hash de un camino MD5. Esto
significa que CHAP requiere de contraseñas que sean almacenadas en una forma
encriptada reversible.
MS-CHAP v1 es similar a CHAP, la diferencia principal es que con
MS-CHAP v1 la contraseña sólo necesita ser almacenada como un hash MD4 en vez de
una forma encriptada reversible.
MS-CHAP v2 es similar a MS-CHAP v1 con la diferencia de que el servidor además

se autentifica a sí mismo con el cliente.
Encriptación PPTP
Inicialmente, la conexión PPP no utiliza encriptación. Para entregar confidenciabilidad

al tunneling, el Microsoft Point-to-Point Encryption
(MPPE) puede ser utilizado con PPTP para soportar un túnel de datos encriptados.
MPPE utiliza el algoritmo RC4 RSA para la encriptación y soporta claves de sesión de
40-bit, 56-bit y 128-bit, lo cual es modificado frecuentemente para asegurar la
seguridad. Sin embargo, la clave de encriptación inicial es derivada basado en la
contraseña del usuario, y por lo tanto puede ser vulnerable a ataques.
Desde que la seguridad PPTP es basada en contraseña, la elección de una buena

contraseña es de importante consideración. A pesar de la longitud de clave elegida (40,
56 o 128-bit), la verdadera intensidad de la clave es gobernada por lo aleatorio de la
contraseña.

Ejemplo: Configurando Servidor PPTP
Este ejemplo describe cómo ajustar un servidor PPTP. La red LAN es una red
192.68.1.0/24, y 10.0.0.0/24 es la red de la interfaz WAN. Los clientes PPTP se
conectarán al servidor PPTP en 10.0.0.1 en la interfaz WAN, con el fin de acceder a
los recursos en la interfaz LAN.
WebUI :
1. Base de Datos de Usuario Local
Se necesita crear una base de datos de usuario local para almacenar la información del
usuario en ella. Para mayor información, ver 17.2.1 sección de Base de Datos del
Usuario Local.
User Authentication → Local User Databases → Add → Local User
Database:
Ingrese un nombre para la base de datos del usuario, ”UserDB” será utilizado en este
ejemplo:
Name: UserDB
2. Añadir un Usuario a la Base de Datos de Usuario Local
Se necesita añadir un usuario a la base de datos de usuario local creado anteriormente.

User Authentication → Local User Databases → UserDB → Add →
User:
Username: testuser
Password: testpassword
Confirm Password: testpassword
Es posible configurar una IP estática para este usuario en la sección de configuración
Por-usuario PPTP/L2TP. Luego haga click en OK

22.2. PPTP/ L2TP 231
3. Servidor PPTP
El siguiente paso es configurar el servidor PPTP.

Interfaces → L2TP/PPTP Servers → Add → L2TP/PPTP Server:
→ General
Name: PPTPServer
Inner IP Address: Esta es la dirección IP del servidor PPTP dentro del túnel. En este
caso 192.168.1.1
Tunnel Protocol: PPTP
Outer Interface Filter: WAN
Server IP: Esta es la IP a la que los usuarios remotos se conectarán, en este caso
10.0.0.1
→ PPP Parameters
Use User Authentication Rules: Enable (Especifique que la autentificación debe ser
ejecutada)
Microsoft Point-to-Point Encryption (MPPE): Seleccione la intensidad de encriptación
a permitir.
IP Pool: 192.168.1.10-192.168.1.20 (La fuente de direcciones IP para asignar IP:s
desde usuarios conectados)
DNS (Primary/Secondary): Especifique cualquier servidor DNS eventual para distribuir
a clientes conectados.
NBNS (Primary/Secondary): Especifique cualquier servidor NBNS (WINS) eventual
para distribuir a clientes conectados.
→ Add Routes
Proxy ARP: Dejar como predeterminado, o seleccionar específicamente la interfaz
LAN si los IP:s en la fuente IP son parte de la red en la interfaz LAN.

4. Regla de Autentificación del Usuario
El siguiente paso es configurar la regla de autentificación del usuario para utilizar

en la autentificación.
User Authentication → User Authentication Rules → Add → User
Authentication Rule:
Name: PPTPUARule
Agent: PPP
Interface: PPTPServer
Originator IP: 0.0.0.0/0 (todas las nets)
Terminator IP: 10.0.0.1 (La IP que el servidor PPTP está percibiendo)
Authentication Options/Local User DB: UserDB (La base de datos creada
anteriormente)
PPP Agent Options: Seleccione los protocolos de autentificación a soportar.
(El ajuste predeterminado es soportar todos los protocolos de autentificación)
5. Reglas IP
El paso final es ajustar una regla para permitir el tráfico desde clientes PPTP a
la red LAN.
Name: FromPPTPClients
Action: Allow
Service: Any
Source Interface: PPTPServer
Source Network: 192.168.1.10-192.168.1.20
Destination Network: 192.168.1.0/24 (Red en la interfaz LAN)
Si los clientes PPTP deben ser capaces de accede a los recursos externos (tales
como el Internet por ejemplo) una regla NAT debe ser configurada también.
Cuando la configuración es guardada y activada, debe ser posible para los clientes
PPTP conectarse al servidor PPTP en 10.0.0.1 en la interfaz WAN.

22.2. PPTP/ L2TP 233
Ejemplo: Configurando Cliente PPTP
Este ejemplo describe cómo ajustar un cliente PPTP. El servidor PPTP es localizado en
10.0.0.1 y todo el tráfico debe ser dirigido sobre el túnel PPTP.
WebUI
:
1. Cliente PPTP
El primer paso es configurar el cliente PPTP.

Interfaces → L2TP/PPTP Clients → Add → L2TP/PPTP Client:
Name: PPTPClient
Tunnel Protocol: PPTP
Remote Endpoint: 10.0.0.1 (La IP del servidor PPTP)
Remote Network: 0.0.0.0/0 (todas las nets, como se ha dirigido todo el tráfico en el
túnel)
Password: La contraseña entregada por su proveedor de servicio.
Confirm Password: Redigite la contraseña.
Se mantienen los ajustes predeterminados para la autentificación y encriptación. Si

es habilitado dial-on-demand, el túnel sólo será capaz cuando haya tráfico en la
interfaz del cliente PPTP. Es posible configurar cómo el firewall debe sentir actividad
en la interfaz, y cuánto tiempo esperar sin actividad antes de que el túnel sea
desconectado. Luego haga click en OK

2. Rutas
El paso final es configurar una ruta de un sólo titular al servidor PPTP sobre la
interfaz WAN.
Interface: WAN
Network: 10.0.0.1 (IP del servidor PPTP)
Gateway: La puerta de enlace en la red WAN. Ninguna si no se utiliza puerta de enlace.
Metric: 0
Cuando la configuración es guardada y activada, el cliente PPTP debe ser conectado

al servidor PPTP, y todo el tráfico (excepto el tráfico a 10.0.0.1) debe ser dirigido sobre
la interfaz PPTP.
22.2.2 L2TP
El Layer Two Tunneling Protocol (L2TP) es una extensión basada en PPP, lo cual es
más flexible que PPTP e IPsec en que éstos utilizan el protocolo UDP para comunicación,
lo cual facilita el atravesar rutas con NAT. En adición, L2TP soporta llamadas
múltiples para cada túnel mientras sólo una conexión por túnel es permitida por PPTP
ó tunneling.
Formato de Tunneling L2TP
L2TP cuenta con el protocolo para encapsular datagramas (ver 9.4.1

PPP). La estructura PPP es luego encapsulada en un header L2TP, lo cual es en
cambio empaquetado con un header UDP e IP para cumplir con la convención
de direccionamiento internet, mostrado en la Tabla 22.2. El header de capa de datos-link
y trailer son puestos en el paquete encapsulado L2TP para formar el tunneling de datos.
L2TP utiliza puerto 1701 UDP para su control y conexiones de datos.
Autentificación L2TP
Los Túneles PPTP y L2TP utilizan los mismos mecanismos de autentificación que las
conexiones PPP tales como, PAP, CHAP, MS-CHAP v1 y v2.

22.2. PPTP/ L2TP 235
IP Header UDP Header L2TP Header PPP Payload
PPP Frame
Tabla 22.2: Encapsulación L2TP.
Encriptación L2TP
L2TP llama a MPPE para encriptación.
L2TP/IPsec
Los métodos de autentificación direccionados por PPTP y L2TP principalmente cuentan

con la contraseña del usuario, y la encriptación al tunneling de datos no es inicialmente
diseñado por estos protocolos. De este modo, PPTP y L2TP NO son resistentes a
muchos ataques comunes, ej. Ataques Man-in-the-middle, Repetición,
Spoofing, Diccionario, y Dos.
L2TP e IPsec pueden trabajar juntos para beneficiarse de tanto flexibilidad como
una seguridad más fuerte. Encapsulando L2TP como payload en un paquete IPsec,
conexiones pueden ser protegidas activando Encriptación y autentificación. Esta
combinación es denominada L2TP/IPsec.
Ejemplo: Configurando Servidor L2TP/IPsec (PSK)
Este ejemplo describe cómo ajustar un servidor L2TP con IPsec, utilizando claves
pre-compartidas. La red LAN es una red 192.68.1.0/24, y 10.0.0.0/24 es la red
en la interfaz WAN. Los clientes L2TP se conectarán al servidor L2TP/IPsec en
10.0.0.1 en la interfaz WAN, con el fin de accede a recursos en la interfaz
LAN.

WebUI
:
Primero que todo se necesita crear una clave pre-compartida para utilizar con la
Autentificación IPsec.
Key:
Name: Ingrese un nombre para la clave pre-compartida, L2TPKey por ejemplo
Passphrase/Shared Secret: Ingrese una frase secreta.
2. Base de Datos del Usuario Local
Se necesita crear una base de datos de usuario local para almacenar información del
usuario.
Para mayor información, ver 17.2.1 sección de Base de Datos de Usuario Local.
User Authentication → Local User Databases → Add → Local User
Database:
Ingrese un nombre para la base de datos de usuario, ”UserDB” se utilizará en este
ejemplo:
Name: UserDB
3. Añadir Usuario a la Base de datos Local
Se necesita añadir un usuario a a la base de datos de usuario local creado antes.

User Authentication → Local User Databases → UserDB → Add →
User:
Username: testuser
Password: testpassword
Confirm Password: testpassword
Es posible configurar una IP estática para este usuario en la sección de
configuración IP por usuario PPTP/L2TP. Luego
haga click en OK

22.2. PPTP/ L2TP 237
4. Túnel IPsec

→ General
Name: L2TPIPsecTunnel
Local Network: Esta es la red local a la que los usuarios remotes se conectarán.
Como vamos a utilizar L2TP esta es la IP a la que se conectarán loc clientes L2TP.
En este caso 10.0.0.1
Remote Network: El firewall mira en este campo y lo compara con la dirección IP
de la fuente del usuario roaming con el fin de permitir conexiones sólo desde
la net local configurada a la net remota. Sin embargo, en este escenario, los clientes
deben ser capaces de roam desde cualquier lugar. De este modo, este campo es
ajustado a todas las nets (0.0.0.0/0). Eso significa que virtualmente todas las
direcciones IPv4- existentes son capaces de conectarse.
Encapsulation Mode: Transport
Algoritmos
IKE Algorithms: Medium
IPsec Algorithms: Medium
→ Authentication
Pre-Shared Key: Seleccione la clave pre-compartida creada anteriormente, L2TPKey
en este caso.
→ Routing
Automatic Routing
El túnel IPsec necesita ser configurado para añadir dinámicamente rutas a la red
remota cuando el túnel es establecido. Esto es realizado bajo la etiqueta de
Routing. Añada dinámicamente una ruta a la red remota cuando un túnel es
establecido: Enable

238 Capítulo. Protocolos & Túneles VPN
5. Servidor L2TP
El siguiente paso es configurar el servidor L2TP.

Interfaces → L2TP/PPTP Servers → Add → L2TP/PPTP Server:
→ General
Name: L2TPServer
Inner IP Address: Esta es la dirección IP del servidor L2TP dentro del túnel. En este
caso 192.168.1.1
Tunnel Protocol: L2TP
Outer Interface Filter: L2TPIPsecTunnel
Server IP: Esta es la IP a la que se conectarán los usuarios remotos, en este caso
10.0.0.1
→ PPP Parameters
Use User Authentication Rules: Enable (Especifica que la autentificación debe ser
ejecutada)
Microsoft Point-to-Point Encryption (MPPE): Seleccione la intensidad de encriptación
a permitir.
IP Pool: 192.168.1.10-192.168.1.20 (La fuente de direcciones IP para asignar IP:s
a usuarios conectados)
DNS (Primary/Secondary): Especifica cualquier servidor DNS eventual para distribuir
a clientes conectados.
NBNS (Primary/Secondary): Especifica cualquier servidor NBNS (WINS) eventual
para distribuir a clientes conectados.
→ Add Route
Proxy ARP: Dejar como predeterminado, ó seleccione específicamente la interfaz LAN
si la IP:s en la fuente es parte de la red en la interfaz LAN.

22.2. PPTP/ L2TP 239
6. Regla de Autentificación del Usuario
El siguiente paso es configurar la regla de autentificación del usuario para utilizar en

la autentificación.
User Authentication → User Authentication Rules → Add → User
Authentication Rule:
Name: L2TPUARule
Agent: PPP
Interface: L2TPServer
Originator IP: 0.0.0.0/0 (todas las nets)
Terminator IP: 10.0.0.1 (La IP que está escuchando el servidor L2TP)
Authentication Options/Local User DB: UserDB (La base de datos de usuario creada
anteriormente)
PPP Agent Options: Seleccionar los protocolos de autentificación a soportar.
(El ajuste predeterminado es soportar todos los protocolos de autentificación)
7. Reglas IP
El paso final es ajustar una regla para permitir el tráfico desde clientes L2TP en la
red LAN.
Name: FromL2TPClients
Action: Allow
Service: Any
Source Interface: L2TPServer
Source Network: 192.168.1.10-192.168.1.20
Destination Network: 192.168.1.0/24 (Red en la interfaz LAN)
Si los clientes L2TP deben ser capaces de accede a los recursos externos (tales como
el Internet por ejemplo) una regla NAT debe ser además configurada.
Cuando la configuración es guardada y activada, debe ser posible para los clientes
L2TP/IPsec el conectarse al servidor L2TP/IPsec en 10.0.0.1 de la interfaz WAN.

240 Chapter 22. VPN Protocols & Tunnels
Ejemplo: Configurando Cliente L2TP/IPsec
Este ejemplo describe cómo ajustar un cliente L2TP con IPsec, utilizando claves
pre-compartidas. El servidor L2TP está localizado en 10.0.0.1 y todo el tráfico debe
ser dirigido sobre el túnel L2TP.
WebUI
:
1. Clave Pre-Compartida
Primero que todo se necesita crear una clave pre-compartida para utilizar en la
Key:
Name: Ingrese un nombre para la clave pre-compartida, L2TPKey por ejemplo.
Passphrase/Shared Secret: Ingrese la frase secreta. (Debe ser la misma
configurada en el servidor L2TP/IPsec)

22.2. PPTP/ L2TP 241
2. Túnel IPsec

→ General
Name: L2TPIPsecTunnel
Local Network: IP de la interfaz a conectar.
Remote Network: 10.0.0.1 (Cuando ésta es donde es localizado el servidor
L2TP/IPsec)
Encapsulation Mode: Transport
Algoritmos
IKE Algorithms: Medium
IPsec Algorithms: Medium
→ Authentication
Pre-Shared Key: Seleccione la clave pre-compartida creada anteriormente, L2TPKey
en este caso.
→ Routing
Automatic Routing
El túnel IPsec necesita ser configurado para añadir rutas no-dinámicamente a la red
remota cuando el túnel es establecido. Esto es realizado bajo la etiqueta de
Routing. Añadir rutas dinámicamente a la red remota cuando un túnel es establecido:
Disable

3. Cliente L2TP
El siguiente paso es configurar el cliente L2TP.

Interfaces → L2TP/PPTP Clients → Add → L2TP/PPTP Client:
Name: L2TPClient
Tunnel Protocol: L2TP
Remote Endpoint: 10.0.0.1 (La IP del servidor L2TP/IPsec)
Remote Network: 0.0.0.0/0 (todas las nets, cuando se dirige todo el tráfico en el
túnel)
Autentificación
Password: La contraseña entregada por su proveedor de servicio.
Confirm Password: Re-digite la contraseña.
Se mantienen los ajustes predeterminados para la autentificación y la encriptación

dial-on-demand es habilitado, el túnel es sólo capaz cuando hay tráfico en la
interfaz del cliente L2TP. Es posible configurar cómo el firewall debe sentir actividad
en la interfaz, y cuánto tiempo esperar sin actividad antes de que el túnel sea
desconectado. Luego haga click en OK
4. Rutas
El paso final es configurar una ruta de un sólo titular al servidor L2TP/IPsec sobre la
interfaz IPsec.
Interface: L2TPIPsecTunnel
Network: 10.0.0.1 (IP del servidor L2TP/IPsec)
Gateway: (None)
Metric: 0
Cuando la configuración es guardada y activada, el cliente L2TP/IPsec

debe conectarse al servidor L2TP/IPsec, y todo el tráfico (a excepción del tráfico a
10.0.0.1) debe ser dirigido sobre la interfaz.

22.3. SSL/TLS (HTTPS) 243
22.3 SSL/TLS (HTTPS)

El protocolo de Secure Sockets Layer (SSL)es un buscador basado en seguridad.
Una alternativa a estándar IPsec basado en VPNs.
Requiere de un poco o ningún software o hardware en PCs remoto, y la conexión segura

es principalmente operada por el buscador web y el servidor web, lo cual es
fácilmente implementado y mayor recurso costo-eficiencia en comparación a la
estructura IPsec. Además, puede fácilmente entregar autentificación
usuario-por usuario.
Construido sobre encriptación de clave privada y autentificación de clave pública, el

SSL entrega privacidad e integridad de datos entre dos aplicaciones comunicantes
sobre TCP/IP. En el módulo OSI, la capa de protocolo SSL es ubicada entre el
protocolo TCP/IP de protocolo de capa de red conexión-orientada y la capa de aplicación.
(ej. HTTP). Este cuenta con certificados de autentificación de identidad y la clave
pública de identidad es utilizada para negociar la clave simétrica para la
encriptación de tráfico.
El Transport Layer Security (TLS), es el sucesor a SSL y entrega mucho de la misma

funcionalidad pero con una estandarización más firme y punto de apoyo en el
IETF.
El HTTP que corre en la parte superior del SSL/TLS es a menudo llamado HTTPS, lo cual
es un uso común de SSL/TLS para asegurar el servicio de buscador en web entre un
buscador y un servidor web. Cuando usted visita web sites “seguros”, usted puede ser
notificado de que el URL comienza con las letras ”https://” en vez de ”http://”.
Este HTTP es conseguido dentro del SSL/TLS. Los buscadores web más comúnmente
utilizados soportan HTTPS, y más y más web sites utilizan el protocolo para obtener
información del usuario confidencial, tal como números de tarjeta de crédito.
Hay un número de versiones del protocolo SSL/TLS. Los firewalls D-Link soportan por
completo SSLv3 y TLSv1.

Parte IX
Administración de Tráfico
La Administración de Tráfico se preocupa del control y localización
de la banda ancha de la red y minimización de posibles retrasos y
congestiones en la red. Esta abarca la medida de la capacidad de red
y modelos de tráfico para administrar recursos de red eficientemente
y entregar los servicios de banda ancha que se necesitan.
Los tópicos incluidos en esta parte incluyen:
• Traffic Shaping
• Server Load Balancing (SLB)

CAPITULO 23
Traffic Shaping
23.1 Vista General

Las redes TCP/IP son llamadas para llevar el tráfico perteneciente a una variedad
creciente de usuarios con diversas necesidades de servicio, por ejemplo, transferencia
masiva de datos, telefonía IP, VPNs, y aplicaciones multimedia. Pero uno de los mayores
inconvenientes de TCP/IP es la falta de una verdadera funcionalidad de Quality of Service
(QoS), la cual es la habilidad de garantizar y limitar la banda ancha para ciertos servicios
y usuarios. Aunque, existen protocolos como Diff-Serv (Differentiated Services) y otras
soluciones que intentan ofrecer QoS en redes grandes y complejas, ninguna de las
soluciones ha alcanzado un alto estándar suficiente para el uso a gran escala.
Otro hecho es que la mayoría de las soluciones QoS actuales son basadas en aplicaciones,
esto es, que trabajan teniendo aplicaciones que suministran a la red con información
QoS. Desde el punto de vista de la seguridad, es por supuesto inaceptable que las
aplicaciones (esto es, los usuarios) decidan la prioridad de su propio tráfico dentro de una
red. En escenarios sensible a la seguridad, donde el usuario no puede ser confiable, el
equipo de la red deberá ser el arbitro exclusivo de prioridades y localidades de
banda ancha.
Para tratar los problemas anteriores, los firewall D-Link entregan funcionalidad QoS
y aplica límites y garantías al mismo tráfico de red, más que confiar en las
aplicaciones/ usuarios para hacer elecciones. Es por lo tanto bien adecuado
administrar la banda ancha por un pequeño LAN así como en uno o más puntos de
obstrucción en grandes WANs.
247
248 Capítulo 23. Traffic Shaping
23.1.1 Funciones
El medio más simple para obtener QoS en una red, visto desde la perspectiva de
seguridad así como de la funcionalidad, es tener componentes en la red, conocidos
como Traffic Shaping, responsables del control de tráfico de red en puntos de
obstrucción bien definidos. Un firewall D-Link tiene un traffic shaper extensible
integrado.
El traffic shaper trabaja midiendo y enfilando paquetes IP, en tránsito, con

respecto a un número de parámetros configurables. Pueden ser creados índices de
limites diferenciados y garantías de tráfico basados en fuentes, destino, y parámetros de
protocolo, del mismo modo muchas reglas firewall son implementadas. Las funciones
principales pueden ser resumidas a continuación:
• Aplicación de límites de banda ancha ordenando paquetes que podrían exceder

los límites configurados en el paquete buffers, y los envía después, cuando la
demanda de banda ancha disminuye momentáneamente.
• Dropping paquetes si los buffers de paquete están llenos. El paquete que será
desechado debe ser elegido de aquellos que son responsables de la
congestión.
• Priorización del tráfico de acuerdo con la elección del administrador; si el tráfico

de alta prioridad crece mientras la línea de comunicación está llena, el
tráfico de menor prioridad será temporalmente limitado para hacer espacio
para el tráfico de alta-prioridad.
• Provee garantías de banda. Esto es comúnmente cumplido al tratar cierta

cantidad de tráfico (la cantidad garantizada) como de alta prioridad, y al
tráfico que excede la garantía como de la misma prioridad que
”cualquier otro tráfico”, lo cual luego comienza a competir con el tráfico no
priorizado.
Los traffic shapers bien construidos no trabajan normalmente ordenando enormes

cantidades de datos y luego separando el tráfico priorizado para enviarlo antes del
tráfico no priorizado. Mas bien, éstos intentan medir la cantidad de tráfico priorizado y
luego limitar el no priorizado dinámicamente, de modo que este no interfiera con el
rendimiento del tráfico priorizado.

23.2. Conductos 249
23.1.2 Características
El traffic shaper en los firewalls D-Link tienen las siguientes características claves:
• Basado en Conductos
El Traffic shaping en los firewalls D-Link es manejados por un concepto basado en
”conductos”, donde cada conducto tiene varias posibilidades de priorización,
limitación y agrupamiento. Los conductos individuales pueden ser encadenados
de diferentes maneras para construir unidades de administración de banda ancha
que exceden por mucho las capacidades de un solo conducto.
• Priorización de tráfico y limitación de banda ancha

Cada conducto contiene un número de niveles de prioridad, cada uno con su propio
límite de banda ancha, especificado en kilobits por segundo. Los límites pueden
además ser especificados por el total del conducto.
• Agrupamiento
El tráfico a través del conducto puede ser agrupado automáticamente en ”pipe
users”, donde cada usuario de conducto puede ser configurado a la misma
extensión que el conducto principal. Un grupo es especificado con respecto al
número de parámetros, por ejemplo, fuente o destino de red IP , dirección IP o
número de puerto.
• Balance Dinámico de Banda Ancha

El traffic shaper puede ser utilizado para balancear dinámicamente la asignación de
banda ancha de diferentes grupos de conductos si los conductos como total han
excedido sus límites. Esto significa que la banda ancha disponible es regularmente
balanceada con respecto al agrupamiento del conducto.
• Encadenamiento de Conducto
Cuando los conductos son asignados a reglas de conducto, pueden ser concadenados
por sobre ocho conductos para formar una cadena. Esto permite filtrar y limitar para
ser manejados de manera muy sofisticada.
• Garantías de tráfico
Con la configuración de conducto apropiado, el traffic shaping puede ser utilizado para
garantizar la banda ancha (y de este modo calidad) para el tráfico a través del
firewall.
Una vista cercana a estas características es entregada en las secciones a continuación.
23.2 Pipes
Un conducto es un concepto central en la funcionalidad de traffic shaping de los Firewalls
D-Link y es la base de todo control de banda ancha. Los conductos son bastante

simples, ya que estos no conocen mucho acerca de los tipos de tráfico que pasan a
través de estos, y no saben nada sobre la dirección tampoco. Un conducto
simplemente mide la cantidad de tráfico que pasa a través de él y aplica los
límites configurados en cada preferencia y/ó grupo de usuario. La tarea del filtro de
tráfico, categorización, y priorización es realizada por las Reglas de Conducto
cubiertas en la siguiente sección.
Los firewalls D-Link son capaces de manejar cientos de conductos simultáneamente

pero en realidad, sólo unos cuantos conductos son requeridos para la mayoría de las
instalaciones. La única ocasión que utiliza docenas de conductos es el escenario donde
un conducto individual es creado para cada servicio (protocolo, o cliente en
casos ISP).
23.2.1 Preferencias y Garantías

Dependiendo de aplicaciones particulares o configuraciones manuales, el tráfico puede ser
tratado como si tuviera diferentes niveles de importancia.
En una versión IP de 4 paquetes, hay un campo de 1-byte denominado Type-of-

Service(ToS) en el header (mostrado en la Tabla 23.1). Este recuadro ToS es utilizado en
Diff-Serv, el enfoque para entregar QoS diferenciando clases de servicio en diferentes
prioridades para soportar varias aplicaciones de red. Los 6 bits restantes
de este recuadro es llamado Differentiated Services Code Point(DSCP) y los últimos
dos bits no son definidos dentro del modelo Diff-Serv. El Diff-Serv estándar utiliza
los higher 3 bits de DSCP para ajustes de prioridad de aplicación, el cual es organizado
en 8 niveles de preferencia desde 0 a 7; and los lower 3 bits son utilizados para ofrecer
una mejor granulación para prioridades de preferencia. La prioridad de una aplicación
aumenta con 0 el más bajo y 7 el más alto. El valor 6 y 7 es reservado para paquetes de
control de red, de modo que los valores entre 0-5 pueden ser ajustados para prioridad
basada en redes IP o aplicaciones.
Correspondiente a estos 8 niveles, un conducto en un firewall D-Link contiene 4

preferencias – Low, Medium, High, and Highest – para clarificar la importancia
relativa del tráfico. Cada una de estas preferencias mapea a 2 niveles en la
definición DSCP, por ejemplo, ”Low” se mantiene para nivel 0 y 1.
El tráfico en preferencia ”Medium” será pasado ente el tráfico en preferencia
”Low”, el tráfico en preferencia ”High” antes de ”Medium” y ”Low”, y etc.
La asignación de preferencia es controlada por las Reglas de Conducto. Con el
fin de determinar a qué preferencia pertenece el tráfico, cada buffer de paquete
tiene asignada un número de preferencia antes de ser enviado a un conducto.
El límite actual de banda ancha es desplegado dentro de cada preferencia;

23.2. Conductos 251
los límites separados de banda ancha pueden ser especificados para cada una de las
4 preferencias con una unidad de ”kilobits por segundo”. El tráfico que excede el límite
de una alta preferencia será automáticamente transferido al nivel ”Low” para un mejor
esfuerzo de distribución, tanto como haya espacio en esta preferencia.
1 byte 1 byte 2 bytes

Version IP Header Length Type-of-Service Total Length
Identification Flags Fragment Offset
Time-to-Live Protocol Header Checksum
Source Address
Destination Address
Options(padding)
Data
Tabla 23.1: Formato de Paquete IPv4
En adición al límite por preferencia, puede ser especificado un límite por el conducto como
total. Cuando la utilización de banda ancha a través del conducto alcanza el límite total,
el tráfico es priorizado dependiendo de a qué preferencia este pertenezca. Una
Higher preferencia tiene una mayor oportunidad de lograrlo a través del conducto sin
ordenarlo.
Nota
1. Ajuste un límite total

Con el fin de conocer cuánto limitar el tráfico de baja-preferencia, el conducto
necesita conocer la capacidad total.
2. Los límites no pueden ser mayores que la conexión de banda ancha

disponible
Si los límites de conducto son ajustados más arriba que la banda ancha actual
disponible, el conducto jamás sabrá que la conexión está completa, y por lo
tanto es incapaz de acelerar el tráfico de menor-preferencia.
3. La Banda ancha no puede ser garantizada si la banda ancha disponible no es

conocida en todo momento.

Para que cualquier traffic shaper trabaje, éste necesita conocer la banda
ancha pasando a través del punto de obstrucción que está tratando de ”protect”.
Si la conexión es compartida con otros usuarios o servidores que no están bajo
el control del firewall, es casi imposible garantizar la banda ancha,
simplemente porque el firewall no conocerá cuánta banda ancha está
disponible para la conexión. Los límites simples trabajarán por supuesto, pero
las garantías, las prioridades y el balance dinámico no lo hacen.
4. Buscar filtraciones
Asegúrese de que todos los tráficos que son deseados por el control de banda ancha
pasen a través de los conductos.
23.2.2 Agrupamiento de Usuarios en un conducto
Si los conductos son restringidos a la funcionalidad descritas hasta el momento, el

tráfico será limitado sin relación a la fuente o destino. Este modo de operación es
probablemente suficiente para manejar los limites simples de tráfico y garantías.
Sin embargo, los firewalls D-Link tienen la habilidad de agrupar el tráfico dentro de cada
conducto. Esto significa que el tráfico será clasificado y agrupado con respecto a la
fuente o destino de cada paquete que pasa a través del conducto.
El agrupamiento puede ser ejecutado en la fuente/destino de red, dirección IP,

puerto, ó interfaz. En los casos de agrupamiento de red, el tamaño de red puede ser
especificado. Los casos de agrupamiento de puerto incluyen la dirección IP, significando
que el puerto 1024 del computador A no es del mismo “grupo” que el puerto 1024 del
computador B.
El beneficio de utilizar agrupamiento es que el control de banda ancha adicional puede ser
aplicado a cada grupo. Esto significa que si el agrupamiento es ejecutado en, por ejemplo,
agrupamiento de direcciones IP, el firewall puede limitar y garantizar la banda ancha
por dirección IP comunicada a través del conducto.
Los límites pueden ser ajustados tanto especificando la máxima banda ancha por grupo
manualmente ó utilizando el balanceo dinamico. El control primero ocurre por grupo
de usuario y luego continua con el conducto como total.

23.3. Reglas de Conducto 253
23.2.3 Balanceo de Carga Dinámico

Como fue previamente indicado, la banda ancha por usuario puede ser limitada
habilitando el agrupamiento dentro de un conducto. Esto puede ser utilizado para
asegurar que un grupo no puede consumir toda la banda ancha disponible. Pero ¿qué pasa
si la banda ancha para un conducto como total tiene un límite, y ese límite es excedido?
Tal problema es tratado por una característica en los firewalls D-Link denominada Balance
Dinámico. Este algoritmo asegura que el límite de banda ancha de cada grupo es
disminuído dinámicamente (o aumentado) con el fin de balancear regularmente la
banda ancha disponible entre los grupos del conducto. La restricción temporal será
removida cuando los límites configurados sean satisfechos.
Los ajustes dinámicos se realizan 20 veces por segundo, y se adaptarán rápidamente a

las distribuciones modificadas de banda ancha.
Las funciones de Balance Dinámico dentro de cada preferencia de un conducto individualmente

esto significa que si los grupos son asignados una pequeña cantidad de trafico de
Alta prioridad, y una gran parte de tráfico de mejor esfuerzo, todos los grupos tendrán
su parte de tráfico de high-preferencia así como un a justa repartición de tráfico de
mejor esfuerzo.
23.3 Reglas de Conducto

Las reglas de Conducto son políticas que toman decisiones sobre qué tráfico debe ser
pasado a través de cuáles conductos. Las reglas de conducto filtran el tráfico por tipo
de servicio y direcciones de interfaz & red IP, muchas del mismo modo que las reglas
normales IP. Luego, la regla elige el reenvío apropiado y regresa los conductos al tráfico,
y determina la preferencia (prioridad) en estos. Cuando el firewall recibe el tráfico, estará
capacitado para encontrar esta información de conductos y preferencias en reglas
coincidentes, y controla la utilización de banda ancha de acuerdo a los límites y/o
agrupamiento definido en conductos específicos. Recuerde que sólo el tráfico
coincidente con una regla de conducto será tráffic shaped, y la primera regla coincidente
es la utilizada.
23.4 Escenarios: Configurando Traffic Shaping

Como se ha visto en secciones previas, en los firewalls D-Link, todas las mediciones,
limitaciones, garantizaciones y balance es llevado a cabo en conductos. Sin
embargo un conducto por sí mismo no tiene sentido a menos que sea puesto en uso

en la sección de Reglas de Conducto. Cada regla puede pasar tráfico a través de

uno o más conductos, en una preferencia (prioridad) de elección del
administrador.
El tráfico de red es primero filtrado dentro e la regla de ajuste normal del firewall IP; si
es permitida, es luego comparada con la sección de Reglas de Conducto y pasada
al conducto(s) especificado en la regla de conducto coincidente. En el conducto, el
tráfico es limitado con respecto a la configuración y es luego reenviado a su destino,
ó al siguiente conducto en cadena.
Para resumir, son necesarios los siguientes pasos para ajustar el traffic shapping:
1. Plan de requerimiento del traffic shaping:

Si los requisitos a la red actual, tales como de qué manera el tráfico debe ser
limitado, priorizado, garantizado, o distribuído no son claros, el trabajo de
configuración será más confuso que útil.
2. Ajustes de Conductos
Ajusta los conductos que describen límites para diferentes preferencias, y define
los criterios de agrupamiento.
3. Ajuste de Reglas de Conducto

Asigna, el las Reglas de Conducto, tipos específicos de servicio, filtro de
dirección, preferencias, y diferentes cadenas/conductos para utilizar para tanto direcciones
de reenvío & retorno.
4. Verificación
Verifica que el traffic shaping configurado trabaje en estas maneras deseadas.
Ejemplo: Aplicando dos medios básicos de límites de banda ancha
En este ejemplo, son creados dos conductos para el control tanto de tráfico entrante
y saliente, denominado ”std-in” y ”std-out” respectivamente, y un límite de conducto
total de 1000 kilobits es ajustado a cada uno de ellos. Este par de conductos limita
simplemente todo el tráfico que pasa a través de cada dirección a 1000kbps, sin
importar de qué tráfico sea.
Luego de ajustar los límites totales en los dos conductos, dos reglas de conducto
necesitan ser especificadas para asignar conductos en direcciones apropiadas,
interfaces y redes. Desde que estas dos reglas primarias son aplicadas a todos los
servicios posibles, la preferencia fija ”Low” es definida en estos.

23.4. Escenarios: Ajustando Traffic Shaping 255
WebUI
:
1. Conductos
Conducto ”std-in” por tráfico entrante:
Ingrese lo siguiente y luego haga click en OK.

Traffic Shaping → Pipes → Add → Pipe:
General
Name: std-in
Pipe Limits
Total: 1000
Pipe ”std-out” for outbound traffic:
Crear el otro conducto utilizando los mismos pasos anteriores con el nombre
cambiado a ”std-out”
2. Reglas de Conducto
Regla ”ToInternet” asignando conductos al tráfico que va a través del firewall

desde LAN a WAN para todos los servicios(definidos por los Servicios objetivos
”all-services”):
Traffic Shaping → Pipe Rules → Add → Pipe Rule:

→ General
Name: ToInternet
Service: all-services
Address Filter
Source Destination
Interface: lan wan
Network: lannet wannet

→ Traffic Shaping
Cadenas de Conducto
Forward Chain: Seleccione ”std-out” desde la lista Available y colóquela en la lista
Selected.
Return Chain: Seleccione ”std-in” desde la lista Available y colóquela en la lista
Selected.
Preferencia
Marque Use Fixed Precedence
Seleccione Low desde la lista desplegable
Regla ”FromInternet” asignando conductos al tráfico que va a través del firewall

desde WAN a LAN para ”all-services”:

→ General
Name: FromInternet
Service: all-services
Address Filter
Source Destination
Interface: wan lan
Network: wannet lannet
→ Traffic Shaping
Cadenas de Conducto
Forward Chain: Seleccione ”std-in” desde la lista Available y colóquela en la lista
Selected.
Return Chain: Seleccione ”std-out” desde la lista Available y colóquela en la lista
Selected.
Preferencia
Seleccione Low desde la lista desplegable

Ejemplo: Aplique preferencia en los límites de conducto
Este ejemplo muestra cómo definir preferencias específicas en conductos. Se añade

una regla más en la parte superior de ”ToInternet” y ”FromInternet”, los cuales utilizan
dos conductos estándar creados en el ultimo ejemplo y habilita el buscador web al
internet para tener una prioridad superior ”Medium” más que todos los demás tráficos
que tienen la preferencia”.
Con el fin de prevenir la respuesta de servicio desde el Internet consumiendo toda la

banda ancha por su mayor prioridad, un límite de 500 kbps es ajustado a preferencia
“Medium” en el conducto ”std-in”.
WebUI :
1. Regla de conducto adicional ”HTTP” con preferencia fija ”Medium”:

→ General
Name: HTTP
Service: HTTP
Address Filter
Source Destination
Interface: lan wan
Network: lannet wannet
→ Traffic Shaping
Cadenas de Conducto
Forward Chain: Seleccione ”std-out” desde la lista Available y colóquela en la lista
Selected.
Return Chain: Seleccione ”std-in” desde la lista Available y coplóquela en la lista
Selected.
Preferencia
Seleccione Medium desde la lista desplegable
y luego haga click en OK.
Click derecho en el item de regla ”HTTP” y haga click en Move to Top.

2. Revisar conducto ”std-in” para tener límite 500kbps en la preferencia

”Medium”
Traffic Shaping → Pipes → std-in:

Límites de Conducto
Preferencias:
Añada los siguientes valores en el recuadro de editar y luego haga click en OK.
Medium: 500
Ejemplo: Utilizando el agrupamiento en un conducto.
Un conducto puede ser de manera futura dividido en varios grupos con respecto a redes
particulares, IP, puerto, ó interfaz; y el límite total de banda ancha del conducto puede
ser distribuido equitativamente en cada grupo habilitando Balance Dinámico de
Banda Ancha. Las preferencias aplicadas en el conducto pueden además ser utilizadas en
todos los grupos. En este ejemplo, se revisarán dos conductos estándar ”std-in” y
”std-out” para tener características de agrupamiento basadas en Destino IP y Fuente IP
respectivamente.
WebUI
:
1. Editar conducto ”std-in”
Traffic Shaping → Pipes → std-in:

Agrupamiento
Grouping: Seleccione DestinationIP desde la lista desplegable.
Marque Enable dynamic balancing of groups
2. Editar conductos ”std-out”
Traffic Shaping → Pipes → std-out:

Agrupamiento
Grouping: Seleccione SourceIP desde la lista desplegable.
Marque Enable dynamic balancing of groups

Ejemplo: Utilizando cadenas para crear diferentes límites
Puede ser conectado más de un conducto en una cadena de conductos para hacer los límites
de banda ancha más restrictivos. En el ejemplo anterior –Aplicar preferencias en los límites de
Conducto, un límite de 500kbps en la preferencia ”Medium” es definida en el conducto”std-in”.
La regla ”HTTP” dice que la respuesta HTTP desde el Internet puede utilizar por sobre
500kbps como alta prioridad de tráfico, y el tráfico que excede este límite caerá en la
prioridad ”Low” especificada por la regla estándar ”FromInternet”. Tal tráfico
comparará los 500kbps restantes con todos los otros tráficos
(Los límites totales definidos para ”std-in” son 1000kbps).
Si se desea garantizar que los otros tráficos siempre tienen al menos 500kbps sin
competir con el tráfico HTTP excedente, se puede añadir un conducto adicional
”http-in” que limite el consumo total de banda ancha a 500kbps, y revise la regla de
conducto ”HTTP” para tener una cadena de conducto en la dirección contraria. En
esta cadena, es puesto ”http-in” en frente de ”std-in”. El tráfico perteneciente a HTTP
necesitará pasar primero los límites totales en ”http-in” antes de que pueda ir a
”std-in”. El tráfico HTTP excedente será ordenado en ”http-in”.
WebUI
:
1. Añadir un conducto más ”http-in” con límites totales 500kbps
Ingrese lo siguiente y luego haga click en OK.

Traffic Shaping → Pipes → Add → Pipe:
General
Name: http-in
Límites de Conducto
Total: 500
2. Revisar la regla de conducto ”HTTP” para crear una cadena de conducto de
retorno
Traffic Shaping → Pipe Rules → HTTP
→ Traffic Shaping:
Cadenas de Conducto
Cadena de retorno
Seleccione ”http-in” desde la lista Available y colóquela en la lista Selected en la parte TOP
de ”std-in”
y luego haga click en OK.

CAPITULO 24
Servidor de Balanceo de Carga (SLB)
24.1 Vista General

Server Load Balancing (SLB) es un mecanismo que trata con la distribución de carga de
tráfico a través de múltiples servidores para escalar más allá de la capacidad de un sólo
servidor, y para tolerar una falla de servidor. Esta tecnología es integrada en los firewalls
D-Link para habilitar una alta ejecución y rendimiento de la red.
24.1.1 El módulo SLB

En el módulo SLB, un dispositivo de red actúa como un Server load balancer,
conectando la red donde el tráfico solicitante llega desde un cluster o servidores
denominados Server farm.
Vista lógica SLB
La Figura 24.1 ilustra una vista lógica de un módulo SLB. En este módulo, 3
servidores construyen un banco de servidores, y un firewall D-Link actúa como un server load
balancer.
Server farm
Una colección de servidores computacionales usualmente mantenidos por una

empresa para lograr las necesidades de servicio por sobre la capacidad de un solo
aparato.
261
262 Capítulo 24. Server Load Balancing (SLB)
Figura 24.1: Una vista lógica SLB.
Server load balancer
Es un aparato para ejecutar las funciones de SLB, que presta atención a las solicitudes
entrantes, decide el modo de distribución de tráfico y algoritmo, re-dirige el
tráfico a ciertos servidores dentro del banco de servidores, y monitorea la
disponibilidad de los servidores.
Los firewalls D-Link son balanceadores de carga, los cuales pueden ser configurados
para ejecutar la distribución de carga y monitoreo de funciones.
24.1.2 Características SLB

Las características claves que el SLB puede entregar son resumidas a
continuación:
Distribución de Carga
La característica de la distribución de Carga es responsable de la distribución de

tráfico a los servidores de destino de acuerdo a algunas políticas predefinidas, ej.
Modo de distribución & algoritmo. Este determina hacia donde se dirige el tráfico y
cómo es compartida la carga de tráfico entre los servidores disponibles.
Monitoreo de Servidor
Monitoreo de Servidor es utilizado para la ejecución de varias inspecciones para evaluar

la ”salud” de los servidores. Este trabaja a diferentes capas del modulo OSI, rastrea

24.1. Vista General 263
a tiempo real del estado de los servidores, y notifica la distribución de tráfico para
redireccionar el tráfico si falla algún servidor.
24.1.3 Beneficios
La solución SLB entrega una administración de tráfico más avanzada y flexible, un mayor
poder de procesamiento, en comparación a la implementación de un solo servidor.
Las ventajas significativas son:
Escalabilidad
El SLB mejora drásticamente la escalabilidad de una aplicación ó banco de
servidores distribuyendo la carga a través de servidores múltiples. La adición de
nuevos servidores, y la eliminación ó fallas de servidores existentes, pueden
ocurrir a cualquier momento, sin experimentar período de inactividad.
Habilidad Optimizada
El SLB ayuda a reducir la cantidad de trabajo de cada servidor, y por lo tanto,
entrega una respuesta más rápida a solicitudes de usuario. Cualquier servidor en el
banco de servidores no será inundado por tráfico inusualmente pesado que no es capaz
de manejar. La carga adicional puede ser tomada sobre otros servidores activos
automáticamente.
Disponibilidad
La distribución de carga y monitoreo de servidor cooperan para conseguir
recuperación de fallos automático. Con estas dos características, el SLB es capaz de
direccionar el tráfico a servidores alternativos si un servidor falla.
Seguridad
En un modulo SLB, una dirección de servidor público es presentado a los clientes,
representando la server farm. La dirección real de los servidores se encuentra
escondida detrás de tal dirección publica y jamás es revelada a la red externa
(cubierta por 24.2 Implementaciones SLB). Esta puede filtrar tráfico no deseado
basado tanto en dirección IP y TCP ó números de puerto UDP, y ayuda a
proteger contra formas múltiples de ataques de denial-of-service(DoS.)
Fácil Mantenimiento
La Administración de aplicaciones de servidor es fácil. El banco de servidores es
visto como un solo servidor virtual por los Clientes con una dirección pública; no se
necesita de una administración para los cambios reales de servidor, los cuales son
transparentes a la red externa.

24.2 Implementación SLB

Para implementar el método SLB, el administrador define un banco de servidores
contenedor de servidores reales múltiples, y amarra el banco de servidores como un sólo
servidor virtual al firewall D-Link ( load balancer), utilizando una dirección
pública IP. En este ambiente, los clientes están configurados para conectarse a la dirección
pública del banco de servidores. Cuando un cliente inicia una conexión al banco de servidores
el firewall utiliza la regla SAT para traducir la dirección de destino. Cuál servidor real
será elegido por el firewall como el más apropiado es determinado por el modo
pre-definido y algoritmo. Cooperando con la tarea de distribución, el firewall monitorea
la “salud” de los servidores por alguna verificación de conexión capa 3/ capa 4.
24.2.1 Modo de Distribución

Los firewalls D-Link pueden ser configurados para trabajar para SLB con los siguientes
modos:
1. Distribución por estado:

El estado de cada distribución es grabado por el firewall. Una sesión completa
podría ser transferida al mismo servidor para garantizar una confiable transmisión
de datos.
2. Stickiness de dirección IP:

Los modos sticky rastrean las conexiones de cliente para entregar integridad de
transmisión. En el modo stickness de dirección IP, nuevas conexiones desde
direcciones de cliente IP son asignadas al mismo servidor real como si fueran
conexiones previas de esa dirección.
3. Stickiness de red:
Este modo trabaja como el mismo stickiness de dirección IP, sólo aplique a las
direcciones subred.
24.2.2 Algoritmos de Distribución

Como server load balancers, los firewalls D-Link utilizan algoritmos
configurables como criterio de selección para controlar la distribución de tráfico. El
Firewall elige de manera inteligente el servidor más apropiado y apunta a maximizar
la utilización total del banco de servidores.
Los firewalls D-Link ofrecen los siguientes algoritmos para lograr las tareas de
distribución de carga:

24.2. Implementación SLB 265
1. Algoritmo Round-Robin – trata todos los servidores reales como si tuvieran

capacidades iguales, a pesar de los otros hechos, tal como el número de conexiones
existentes o tiempo de respuesta.
2. Algoritmo de Rango de Conexión – redirecciona una conexión a el servidor con el

menor número de nuevas conexiones en un tiempo predefinido de span.
Una selección dentro del firewall guarda el número de nuevas conexiones por
segundo para cada servidor. Éste actualiza a cada segundo para remover
los viejos valores de conexión.
El algoritmo Round-Robin es apropiado cuando los servidores reales dentro del

banco de servidores tienen iguales poderes de procesamiento, mientras que el utilizar Algoritmo
de Rango de Conexión puede optimizar el tiempo de respuesta.
Sin importar qué algoritmo es elegido, si un servidor se cae, el tráfico será enviado a
otro servidor. Y cuando el servidor vuelva a estar en línea, este puede
automáticamente ser ubicado de nuevo en el banco de servidores y comenzar a tener solicitudes
nuevamente.
24.2.3 Verificación del estado del Servidor

El ejecutar varias verificaciones para determinar la condición de “salud” de los servidores
es uno de los beneficios más importantes del SLB. En las diferentes capas OSI, los
firewalls D-Link pueden llevar a cabo ciertas verificaciones de nivel de
red.
Cuando un servidor falla, el firewall lo remueve de la lista de servidor activo, y no
dirigirá ningún paquete a este servidor hasta que éste vuelva. Un mensaje ICMP
Destination Host Unreachable será enviado por el firewall una vez que la lista de
servidor activo está vacía.
ICMP Ping
En la capa OSI 3, la verificación involucra un Ping a la dirección IP de servidor real para

ver dónde está corriendo el servidor.
Conexión TCP
En la capa 4 OSI, el firewall intenta conectarse al Puerto configurado del servidor

donde una aplicación está corriendo. Por ejemplo, si el servidor está corriendo una
aplicación web (HTTP) en el Puerto 80, el firewall tratará de establecer una
conexión para envolver ese puerto. Ésta envía una solicitud SYN TCP al puerto 80 en
ese servidor y esperará por un SYN/ACK TCP en retorno; si falla, marcará el puerto
80 para bajarlo de ese servidor.

24.2.4 Paquetes que fluyen por SAT

En los firewalls D-Link, la regla SAT habilitada de balance de carga es utilizada
para traducir intercambio de paquetes entre un cliente y los servidores reales.
Cuando una nueva conexión es abierta, la regla SAT es gatillada; ésta traduce la
dirección IP del banco de servidores público a la dirección real de servidor. Una modificación
necesaria a los paquetes es ejecutada por el sistema subyacente determinado
por la regla NAT o Allow.
24.3 Escenario: Habilitando SLB

Los pasos de configuración principales necesarios para habilitar la función SLB en
los firewalls D-Link son alineados a continuación:
• Especificar un Banco de Servidores – Definir un grupo de servidores como banco de

servidores seleccionando los objetos con IP correcta.
• Especificar la regla SAT habilitada de balance de carga – Configurar una

regla SAT con campos de filtro para que el firewall coincide con el flujo de tráfico
y gatille el SLB .
• Especificar el Modo de Distribución & Algoritmo – Entrega las políticas de

distribución que el firewall debe utilizar.
Ejemplo: Configuración SLB
Figura 24.2: Un Escenario SLB

24.3. Escenario: Habilitando SLB 267
Este ejemplo describe cómo puede ser utilizado SLB para load balance
conexiones SSH a dos servidores SSH detrás de un Firewall D-Link conectado a Internet
con dirección IP ip ext, como muestra la Figura 24.2. Los dos servidores SSH
tienen las direcciones IP privadas 192.168.1.10 y 192.168.1.11.
WebUI
:
1. Crear Objetivos
Primero que todo se necesita crear objetivos locales que mantengan la dirección IP
para cada servidor.
Objects → Address Book → Add → IP4 Host/Network:
Name: SSH Server1
IP Address: 192.168.1.10
Objects → Address Book → Add → IP4 Host/Network:

Name: SSH Server2
IP Address: 192.168.1.11
2. Crear Regla SLB SAT
El siguiente paso es ajustar la regla SLB SAT.

Name: SSH SLB
Action: SLB SAT
Service: ssh
SAT Server Load Balancing

Server Addresses: Seleccione Servidor1 SSH y Servidor2 SSH.

3. Crear Regla NAT
El siguiente paso es ajustar la regla NAT para permitir el tráfico SAT:ed por la regla
Anterior.
Name: SSH SLB NAT
Action: NAT
Service: ssh
Nota
Es posible configurar ajustes para monitoreo, método de distribución

y stickiness. Pero en este ejemplo es utilizado el valor por defecto.

Parte X
Características Misceláneas.
Además de una protección segura a la red, los firewalls D-Link pueden
actuar como agentes intermediarios para servicios variados de Internet
y así facilitar el uso de varios protocolos en nombre de los clientes.
• Clientes Miscelaneos
• DHCP Server & Relayer

CAPITULO 25
Clientes Misceláneos
25.1 Vista General

Los firewalls D-Link ofrecen soporte a clientes de red misceláneos para DNS
Dinámico y servicios similares. Actualmente, los proveedores de servicio que son
soportados por el firewall incluyen:
• Dyndns.org
• Dyns.cx
• Cjb.net
• Oray.net – Peanut Hull DynDNS
• Telia
• BigPond
25.2 DNS Dinámico

Dynamic Domain Name System (DynDNS), es un método para mantener un
nombre de dominio vinculado a una dirección IP cambiante. Cuando un usuario se
conecta al Internet a través de medios entregados por el ISP, una dirección IP sin utilizar
para una piscina de direcciones IP es asignada al aparato del usuario, y esta dirección
es utilizada sólo para la duración de ésa conexión específica. Un proveedor de servicio
DNS dinámico utiliza un programa especial que corre en la máquina del usuario,
271
272 Capítulo 25. Clientes Misceláneos
contactando el servicio DNS cada vez que la dirección IP entregada por el ISP
cambia y actualiza posteriormente la base de datos DNS para reflejar el cambio en la
dirección IP. Este método permite que la máquina del usuario tenga un nombre de
dominio que siempre apunte a éste, a pesar de que la dirección IP cambie a menudo.
Otros usuarios no tienen cómo conocer la dirección IP modificada con el fin de conectarse
a la máquina.
Con el fin de utilizar esta función como un cliente DynDNS, uno debe tener una cuenta con
uno de los proveedores de servicio soportados.
Dyndns.org
Dyndns.org es un servicio gratuito DynDNS que permite los registros bajo docenas
de dominios, ej. ”MYDNS.dyndns.org”,
”MYDNS.dnsalias.net”, etc.
Dyns.cx
Dyns.cx es un servicio gratuito DynDNS que permite los registros bajo un
número de dominios: ”dyns.cx”, ”dyns.net”, ”ma.cx”, ”metadns.cx”,
etc.
Cjb.net
Cjb.net entrega servicio gratuito DynDNS (y más) que permite los
registros bajo ”cjb.net”.
Oray.net
Oray.net – ”Peanut Hull DynDNS” ofrece servicios gratuitos DynDNS bajo varios
nombres de dominio.
Luego de un registro exitoso en uno de los proveedores de servicio DynDNS, un

cliente DynDNS puede configurar la información de cuenta en el firewall para ser capaz de
ingresar automáticamente al servicio.
25.3 Registro Automático de Cliente

Algunos proveedores de servicio Internet necesitan que los usuarios se registren vía URL
cada vez antes de que cualquier servicio sea repartido.
Actualmente, los firewalls D-Link ofrecen un registro automático de cliente a los siguientes
proveedores:
• Telia – Una mejor compañía de servicio de telecomunicación en la región Nórdica

y Báltica.

25.4. Poster HTTP 273
• BigPond – Utilizado por Telstra, un proveedor de servicio banda ancha y

multimedia. Autentifica utilizando la interfaz (la cual debe ser permitida por DHCP)
asociada con la ruta predeterminada.
25.4 Poster HTTP

Poster HTTP es una función que habilita el registro automático de cliente, ó nombres
de dominio y direcciones IP sin fecha para DynDNS. Cuando el firewall ha parcelado su
configuración, el Poster HTTP expone todos los URLs configurados sucesivamente, y
esperará un tiempo de retraso configurable para re-post los URLs.
Nota
El actualizar muy a menudo puede causar que el proveedor de servicio cancele el

servicio. De este modo, dependiendo de los requerimientos por proveedores particulares,
el valor del retraso no debe ser muy pequeño.
25.4.1 Formato URL

El formato URL utilizado en el Poster HTTP Poster varían dependiendo del proveedor
de servicio específico. Básicamente, un URL contiene Nombre de Usuario/Contraseña,
nombre de dominio del proveedor, y otros parámetros. Por ejemplo, el formato URL para
servicio DynDNS entregado por Dyndns.org es:
http://MYUID:MYPWD@members.dyndns.org/nic/update?hostname=
MYDNS.dyndns.org

CAPITULO 26
Servidor DHCP & Relayer
26.1 Servidor DHCP

El servidor DHCP implementa la tarea de asignar y manejar direcciones IP desde
piscinas de dirección especificadas para clientes DHCP. Cuando un servidor DHCP
recibe una solicitud desde un cliente DHCP, este vuelve los parámetros de
configuración (tal como una dirección IP, una dirección MAC, un nombre de Dominio y un
contrato para la dirección IP) al cliente en un mensaje unicast. Debido a que el servidor
DHCP mantiene configuraciones para varias subnets, un administrador sólo necesita
actualizar uno solo, el servidor central cuando los parámetros de configuración
cambia.
Comparado con la asignación estática en donde el cliente tiene la dirección,

el direccionamiento dinámico por el servidor DHCP contrata la dirección a cada cliente
por un periodo de tiempo pre-definido. Durante el ciclo de vida del contrato, el cliente tiene
permiso para mantener la dirección asignada y es garantía para no tener colisión de
dirección con otros clientes. Antes de la expiración del contrato, el cliente necesita renovar
el contrato desde el servidor, así este puede seguir utilizando su dirección IP. El cliente
puede además decidir en cualquier momento que no desea utilizar más la dirección IP
que fue asignada, y puede terminar el contrato soltando la dirección IP. El tiempo
de arriendo puede ser configurado en el servidor DHCP por el administrador.
275
276 Capítulo 26. Servidor DHCP & Relayer
Ejemplo: Configurando el firewall como un servidor DHCP
Este ejemplo describe cómo configurar un servidor DHCP en la interfaz interna

(LAN)( Refiérase a 9.1.2, Interfaces Ethernet en los Firewalls D-Link).
WebUI
:
• Configurar Servidor DHCP
System → DHCP Settings → DHCP Server → Add →

DHCP Server:
Name: dhcpserver lan
Interface Filter: LAN (La(s) interfaz(es) que atienden por solicitudes DHCP)
IP Address Pool: 192.168.1.10-192.168.1.20 (La piscina de direcciones IP

a distribuir)
Netmask: 255.255.255.0 (Especifique la netmask a distribuir)
Opciones
Default GW: Especifique la puerta de enlace predeterminada a distribuir a clientes
DHCP. En este caso (None).
Domain: Especifique el dominio a distribuir. Este puede ser dejado vacío.
Lease Time: Configurar el tiempo que debe ser válido el arriendo.
DNS: Configurar la información de servidor DNS para distribuir a clientes DHCP.
Este puede ser dejado en (None).
NBNS/WINS: Configurar la información de servidor NBNS/WINS para distribuir
a clientes DHCP. Este puede ser dejado en (None).
Next Server: Especifique la dirección IP del siguiente servidor en el proceso de
arranque, este es usualmente un servidor TFTP. Este puede ser dejado en
(None).
Opciones de encargo
Aquí usted puede añadir opciones de encargo al contrato DHCP. Es posible
especificar el código, tipo y parámetro.
Cuando termine, haga click en OK

26.2. DHCP Relayer 277
26.2 DHCP Relayer

En la implementación DHCP, los clientes envían solicitudes para localizar el servidor
DHCP por mensajes transmitidos. Sin embargo, las transmisiones son sólo normalmente
propagados en la red local. Esto significa que el servidor DHCP y cliente podría siempre
necesitar estar en la misma área de red física para ser capaz de comunicarse. En tal caso,
para un gran ambiente Internet, este necesita un servidor diferente en cada red, y el
beneficio de tener una configuración de servidor centralizada es ampliamente reducido.
Este problema es resuelto por el uso de relayer DHCP.
Un relayer DHCP toma el lugar del servidor DHCP en la red local para actuar como el
intermedio entre el cliente y el servidor DHCP remoto. Este intercepta solicitudes
para clientes y los re-transmite al servidor. El servidor luego responde de vuelta a la retransmisión,
la cual reenvía la respuesta al cliente. La retransmisión DHCP sigue la funcionalidad de agente
de relayer BOOPT y retiene el formato de mensaje BOOTP y protocolo de comunicación, y por
lo tanto son denominados a menudo BOOTP relayer agents.
Ejemplo: Configurando el firewall como un relayer DHCP
La configuración en este ejemplo permite a los clientes en las interfaces VLAN para
obtener direcciones IP desde un servidor DHCP.
Antes de que los siguientes pasos sean tomados, es asumido que el firewall es
configurado con interfaces VLAN que van a utilizar relaying DHCP, y la dirección IP
del servidor DHCP ha sido definido en el libro de dirección denominado como
”ip-dhcp”.
Para información sobre la configuración VLAN, por favor refiérase a 9.2.3,

Implementación VLAN. En este caso, dos interfaces VLAN denominado como ”vlan1” y
”vlan2” son utilizadas
El firewall puede también instalar una ruta para el cliente cuando ha finalizado el
proceso DHCP y obtenido una IP.

278 Capítulo 26. Servidor DHCP & Relayer
WebUI
:
1. Grupo de Interfaz:
– añadir interfaces VLAN ”vlan1” y ”vlan2” que deben retransmitir a un grupo
de interfaz denominado como ”ipgrp-dhcp”.
Interface → Interface Groups → Add → Interface Group:
Name: ipgrp-dhcp
Interfaces: seleccione ”vlan1” y ”vlan2” desde la lista Available y colóquelas en
la lista Selected.
2. DHCP relay:
– añada un DHCP relay denominado como ”vlan-to-dhcpserver”
System → DHCP Settings → DHCP Relays → Add → DHCP

Relay:
→ General:
General
Name: vlan-to-dhcpserver
Action: Relay
Source Interface: ipgrp-dhcp
DHCP Server to relay to: ip-dhcp
→ Add Route:
Marque Add dynamic routes para este contrato relayed DHCP.

Parte XI
Modo Transparente
CAPITULO 27
Modo Transparente
La característica de Modo Transparente entregado por los firewalls D-Link

apuntan a simplificar el despliegue de dispositivos firewall en la topología de red
existente, para fortalecer la seguridad. Esto ayuda a facilitar el trabajo de administración
en un modo en que no hay necesidad de configurar todos los ajustes para los nodos
dentro de la red en curso, cuando un firewall es introducido en el flujo de
comunicación.
Este capítulo entrega una vista general del ofrecimiento del modo transparente e
introduce cómo el modo transparente es implementado en los firewalls D-Link en
detalle. Los ejemplos de configuración de distribuciones simples de red y escenarios
a tiempo real más complicados pueden ser encontrados al final de este capítulo.
27.1 Vista General

La transparencia refiere a la visibilidad del firewall para hosts en ambos lados de un
firewall. Un firewall es considerado transparente para los usuarios si estos no notifican
el firewall en el flujo del paquete. Cuando se añade un firewall transparente en una
estructura de red pre-existente, se consigue las siguientes ventajas para el
administrador de red:
• No se necesita reconfiguración – los clientes pueden mantener la misma

configuración de red luego de que firewall ha sido instalado.
• No se añade obstáculo – el despliegue del firewall debe ser invisible para los usuarios
internos, cuando estos pueden aún obtener los servicios permitidos.
281
282 Capítulo 27. Modo transparente
• Mejora la seguridad – el firewall debe ser capaz de explorar el tráfico

entrante/saliente por las reglas de seguridad definida.
Los firewalls D-Link pueden trabajar de dos modos: Modo Routing & Modo
Transparente. En el Modo Routing normal, el firewall actúa como un router de Capa 3. Si
el firewall es ubicado en una red por primera vez, o si hay cualquier cambio topológico
dentro de los nodos, la configuración de routing debe ser examinada
rigurosamente para asegurar que la tabla de routing del sistema firewall es consistente
con la distribución de red actual. La reconfiguración de ajustes IP es además requerida
para routers pre-existentes y servidores protegidos. Este modo trabaja bien cuando
se desea tener un control completo sobre el routing, y saber de la localización
específica de dispositivos importantes, para tener la más alta seguridad posible. Por
ejemplo, se espera que el servidor localizado en un área protegida sólo reciba
el tráfico necesario.
Mientras que en el Modo Transparente, el firewall actúa más que un switch. Este
protege paquetes IP que atraviesan el firewall y los reenvía transparentemente
en la interfaz correcta sin modificar cualquiera de la información de fuentes o destinos.
Todas las interfaces transparentes son consideradas para estar en la misma red, de
modo que si un cliente se mueve a otra interfaz este puede aún obtener los
mismos servicios que antes sin reconfiguración routing.
En el modo transparente, el firewall permite a las transacciones ARP ir a través, y

aprende desde el tráfico ARP la relación entre la dirección IP y la dirección física de
la fuente y destino. Hay mecanismos que ayudan al firewall a recordar la
información de dirección, con el fin de transmitir paquetes IP a los receptores deseados.
Durante la transacción, ninguno de los puntos de término sabrán del trabajo del
Firewall entre ellos.
27.2 Implementación de Modo Transparente en los

Firewalls D-Link
Como se explicó anteriormente, el firewall D-Link permite transacciones ARP cuando es
ajustado para ser modo transparente y en ese sentido éste trabaja casi como un
Switch de Capa 2 en la red. El firewall utiliza el tráfico ARP como una fuente de
información cuando construye su tabla switch de ruta. Para comenzar con el modo
transparente, los siguientes pasos deben ser realizados en el firewall:
• Grupos de interfaces – especifique un grupo de interfaces que van a utilizar el

Modo transparente.

27.2. Implementación del Modo Transparente en los Firewalls D-Link 283
• Crear una Ruta Switch – como interfaz, seleccione el grupo de interfaz

creado anteriormente. Como red, especifique el rango de dirección que debe
ser transparente entre las interfaces. Cuando todo el firewall está
trabajando en el Modo Transparente este es normalmente 0.0.0.0/0.
Cuando se inicia la comunicación, un anfitrión localizará las otras direcciones físicas de

anfitriones transmitiendo una solicitud ARP. Cuando el firewall intercepta una solicitud
ARP, esta ajusta una ARP Transaction State dentro del firewall y transmite la solicitud
ARP a todas las interfaces ruta-switch a excepción de la interfaz que la solicitud ARP
ha recibido. Si el firewall recibe una respuesta ARP desde el destino dentro de
un tiempo de desconexión de tres segundos, esto transmitirá la respuesta de vuelta a la
solicitud del remitente, utilizando información almacenada en el ARP Transaction State.
Durante la transacción ARP, el firewalls aprenderá la información de dirección de

fuente de ambos extremos desde la solicitud y respuesta. Dentro del Firewall D-Link,
dos tablas son mantenidas utilizadas para almacenar tal información, llamada
Content -Addressable Memory(CAM) Table y Capa 3 Cache respectivamente.
Una tabla CAM contiene información de las direcciones MAC disponibles en una
interfaz física entregada del firewall, mientras la Capa 3 cache almacena mapeos
entre direcciones IP, dirección MAC e interfaz.
Como la Capa 3 Cache es sólo utilizada por el tráfico IP, las entradas de Capa 3 Cache
son almacenadas como una sola entrada de anfitrión en la tabla routing.
Para cada paquete IP que atravesará el firewall, se realizará una búsqueda de ruta
para el destino. Si la ruta del paquete coincide una ruta switch ó entrada de Capa 3
Caché en la tabla routing, el firewall sabe que debe manejar este paquete de manera
Transparente. Si una interfaz de destino y dirección MAC está disponible en la
ruta, el firewall tiene la información necesaria para reenviar el paquete al destino. Si
la ruta fue un routerswitch , no es disponible ninguna información específica acerca del
destino y el firewall tendrá que descubrir donde está localizado el destino en la red.
El descubrimiento es realizado enviando solicitudes ARP, actuando como el remitente
inicial del paquete original IP para el destino en las interfaces especificadas en el
RouterSwitch. Si una respuesta ARP es recibida, el firewall actualizará la tabla CAM
y la Capa 3 Cache y reenvía el paquete al destino.

284 Capítulo 27. Modo Transparente
Si la Tabla CAM ó Capa 3 Cache está completa, las tablas son parcialmente
Limpiada automáticamente. Utilizando el mecanismo de descubrimiento, el firewall
redescubrirá destinos que pueden ser limpiada.
27.3 Escenarios: Habilitando el Modo

Transparente
Ejemplo: Escenario 1 de Modo Transparente
Figura 27.1: Escenario 1 de Modo Transparente.
El escenario 1 muestra cómo un firewall en Modo Transparente puede ser ubicado en

una red existente entre un router de acceso Internet y la red interna, sin necesidad
de reconfigurar clientes en la red interna.
En este escenario un router es utilizado para compartir una conexión Internet con
una dirección IP pública. La red NAT:ed interna detrás del firewall es en el espacio de
dirección 10.0.0.0/24. Los clientes en la red interna deben estar permitidos para acceder
el Internet vía protocolo HTTP.
La interfaz WAN y LAN en el firewall deberán ser configurados para operar en Modo
Transparente. Es preferible configurar direcciones IP en las interfaces WAN y LAN,
cuando estas pueden mejorar el rendimiento durante el descubrimiento
automático de anfitriones.

27.3. Escenarios: Habilitando Modo Transparente 285
Todo el tráfico que pasa a través del firewall tendrá que pasar a través del ajuste de regla
IP. Para permitir el tráfico HTTP, una nueva regla IP debe ser configurada. (Refiérase
a 14.3 Escenario.)
WebUI
:
1. Interfaces
Interfaces → Ethernet → Edit (WAN):

IP Address: 10.0.0.2
Network: 10.0.0.0/24
Default Gateway: 10.0.0.1
Transparent Mode: Enable
Interfaces → Ethernet → Edit (LAN):

Network: 10.0.0.0/24
Transparent Mode: Enable
2. Reglas

Name: HTTPAllow
Action: Allow
Service: http
Source Network: 10.0.0.0/24

286 Capítulo 27 . Modo Transparente
Ejemplo: Escenario 2 Modo Transparente
Figura 27.2: Escenario 2 Modo Transparente.
El escenario 2 muestra cómo un firewall en Modo Transparente puede ser

utilizado para separar recursos de servidor desde la red interna agregándolas a
una interfaz firewall separada sin necesidad de diferentes rangos de dirección.
Los servidores que contienen recursos que son accesibles desde el exterior podrían
ser un riesgo de seguridad si estos están ubicados directamente en la red interna.
Debido a esto, tales servidores son a menudo conectados a una interfaz separada en el
Firewall, como DMZ.
En este escenario todos los anfitriones conectados a LAN y DMZ comparten el

espacio de dirección 10.0.0.0/24. Cuando este es configurado utilizando el Modo
Transparente cualquier dirección IP puede ser utilizada por los servidores, y no hay
necesidad para los anfitriones en la red interna el conocer si un recurso está en la misma
red o ubicado en DMZ. Esto hace al firewall transparente en la comunicación entre DMZ
y LAN aunque el tráfico pueda ser
restringido utilizando las reglas de ajuste del Firewall IP.
Aquí se permite a los anfitriones en la red interna comunicarse con un servidor HTTP
en DMZ. Además, se permite el servidor HTTP en DMZ para ser alcanzado desde el
Internet. Pueden ser añadidas reglas adicionales para permitir otro tráfico.

27.3. Escenarios: Habilitando Modo Transparente 287
Este escenario muestra cómo configurar una Ruta Switch sobre las interfaces LAN y
DMZ para el espacio de dirección 10.0.0.0/24. Es asumido que la interfaz WAN ya ha
sido configurada correctamente.
WebUI
:
1. Interfaces
Network: 10.0.0.0/24
Transparent Mode: Disable
Add route for interface network: Disable
Interfaces → Ethernet → Edit (DMZ):

Network: 10.0.0.0/24
Transparent Mode: Disable
Add route for interface network: Disable
2. Interface Groups
Name: TransparentGroup
Security/Transport Equivalent: Disable
Interfaces: Select LAN and DMZ
3. Routing
Routing → Main Routing Table → Add → Switch Route:
Switched Interfaces: TransparentGroup
Network: 10.0.0.0/24
Metric: 0

288 Capítulo 27 . Modo Transparente
4. Reglas

Name: HTTP-LAN-to-DMZ
Action: Allow
Service: http
Source Network: 10.0.0.0/24
Destination Network: 10.1.4.10

Name: HTTP-WAN-to-DMZ
Action: SAT
Service: http
Destination Network: wan-ip
Translate: Select Destination IP
New IP Address: 10.1.4.10

Name: HTTP-WAN-to-DMZ
Action: Allow
Service: http
Destination Network: wan-ip

Parte XII
Zona de Defensa
CAPITULO 28
Zona de Defensa
28.1 Vista General

La Zona de Defensa es una característica en los firewalls D-Link, la cual permite al firewall
controlar localmente los switches adjuntos. Esto puede ser utilizado como una contramedida
para evitar que un computador infectado en la red local infecte a otros computadores.
Ajustando las reglas threshold en el firewall, anfitriones ó redes que están excediendo
el treshold definido pueden ser dinámicamente bloqueados. Los tresholds están
basados en el número de nuevas conexiones realizadas por segundo, por tanto un sólo
anfitrión ó todos los anfitriones dentro de un rango de red CIDR especificada (un rango
de dirección IP especificada por una combinación de una dirección IP y su
máscara de red asociada). Cuando el firewall nota que un anfitrión o una red ha
alcanzado el límite específico, éste carga reglas ACL (Access Control
List) para los switches, lo cual bloquean en turno todo el tráfico para ese anfitrión o
red. Los anfitriones y redes bloqueadas se mantienen bloqueadas hasta que el
sistema administrador manualmente los desbloquee utilizando la Web del firewall ó
la interfaz de línea de comando.
28.2 Switches de Zona de Defensa

La información Switch de acuerdo a cada switch que es controlado por el firewall
debe ser manualmente especificada en la configuración del firewall. La información
necesitada con el fin de controlar un switch incluye:
291
292 Capítulo 28. Zona de Defensa
• La información IP de la interfaz administrada del switch
• El tipo de modelo del switch
• La sucesión SNMP comunitaria (acceso escrito)
Actualmente, la característica de Zona de Defensa soporta los siguientes

switches:
- D-Link DES 3226S (firmware mínimo: R4.02-B14)
- D-Link DES 3250TG (firmware mínimo: R3.00-B09)
- D-Link DES 3326S (firmware mínimo: R4.01-B39)
- D-Link DES 3350SR (firmware mínimo: R1.02.035)
- D-Link DES 3526 (firmware mínimo: R3.01-B23)
- D-Link DES 3550 (firmware mínimo: R3.01-B23)
- D-Link DGS 3324SR (firmware mínimo: R4.10-B15)
Nota
Asegúrese de que los switches tienen las versiones mínimas de firmware requeridas
antes de activar la zona de defensa.
28.2.1 SNMP
Simple Network Management Protocol (SNMP) es un protocolo de capa de aplicación
para la administración de redes complejas. El SNMP permite a los administradores y
dispositivos administrados en una red, comunicarse enviando mensajes, con el
propósito de acceder a diferentes partes de la red.
Administrador
Un administrador típico, como un firewall D-Link, ejecuta el protocolo SNMP

para monitorear y controlar los dispositivos de red en el ambiente administrado.
El administrador puede cuestionar estadísticas almacenadas desde los dispositivos
controlados utilizando la secuencia comunitaria SNMP, la cual es como una id
de usuario o contraseña para permitir el acceso a la base de datos de los
dispositivos. Si el tipo de sucesión comunitaria es ”escrito”, el administrador será
capaz de modificar propiedades en el dispositivo.

28.3. Reglas Threshold 293
Dispositivos administrados
Los dispositivos administrados son obedientes a SNMP, tal como los switches
D-Link. Estos almacenan datos administrados en sus bases de datos, conocidas como
Management Information Base (MIB), y entrega la información bajo cuestionamiento
al administrador.
28.3 Reglas Threshold

Como se explicó previamente, una regla threshold desencadenará la Zona de Defensa
para bloquear un anfitrión específico si el rango de conexión especificado en la regla es
excedida. Similar a las reglas IP, una regla threshold además contiene varios campos,
especificando cual tipo de tráfico debe coincidir la regla.
En total, una regla threshold es definida por:
• Fuente de interfaz y de red.
• Interfaz de destino e interfaz de red.
• Servicio.
• Tipo de threshold: Anfitrión y/o basado en red.
El tráfico que coincide el criterio anterior y que causa que el anfitrión/red

threshold sea excedido gatillará la función de Zona de Defensa, la cual prevendrá
al anfitrión/redes de acceder a los switch(es). Todos los bloqueos en respuesta a
violaciones de threshold serán prohibidos basado en direcciones IP del anfitrión ó
red en el/los switch(es). Cuando un threshold basado en red ha sido excedido,
la fuente de red será bloqueada en lugar de sólo ofender a los anfitriones.
28.4 Bloqueo Manual & Listas Excluyentes

Como un complemento a las reglas threshold, es también posible definir manualmente
a los anfitriones y redes que están estáticamente bloqueados ó excluídos.
Los anfitriones manualmente bloqueados y redes pueden ser bloqueados por defecto ó
basados en un programa. Es además posible especificar cuales protocolos y número de
puerto de protocolo deben ser bloqueados.
Pueden ser creadas listas excluyentes y utilizadas con el fin de excluir anfitriones de ser
bloqueados cuando un límite de regla threshold es alcanzada. Una buena práctica incluye

el añadir la interfaz IP del firewall ó dirección MAC conectadas hacia el switch de

Zona de Defensa para la lista Excluyente. Esto previene al firewall de ser accidentalmente
bloqueado.
28.5 Limitaciones
Dependiendo del modelo del switch, hay varias limitaciones en efecto. La primera,
es la latencia entre el activar una regla de bloqueo al momento de que el switch(es)
realmente bloquee el tráfico coincidente con la regla. Todos los modelos de
switch requieren al menos algún tiempo para reforzar las reglas luego de que éstas
son entregadas por el firewall. Algunos modelos pueden activar las reglas dentro de
un segundo mientras otras requieres de un minuto ó incluso más.
Otra limitación es el número máximo de reglas soportadas por el switch. Algunos

switches soportan solo 50 reglas mientras otros soportan por sobre 800
(usualmente, con el fin de bloquear un anfitrión ó red, una regla por Puerto switch es
necesitada). Cuando este límite ha sido alcanzado no serán bloqueados más
anfitriones ó redes.
Nota
La Zona de Defensa utiliza un rango para la regla de ajuste ACL en el switch. Para evitar
conflictos potenciales en estas reglas y garantizar el control de acceso del firewall,
es altamente recomendable que el administrador limpie por completo el ajuste de regla
ACL en el switch antes de procesar la configuración de la Zona de
Defensa.
28.6 Escenario: Ajustando Zona de Defensa

El siguiente ejemplo simple ilustra los pasos necesarios para ajustar la función de
Zona de Defensa en los firewalls D-Link. Se asume que todas las interfaces en el firewall
ya han sido propiamente configurados.
Ejemplo: Configurando Zona de Defensa
En este escenario simplificado, un threshold HTTP de 10 conexiones/Segundo es

aplicado. Si las conexiones exceden este límite, el firewall bloqueará al
anfitrión específico (en el rango de red 192.168.2.0/24 por ejemplo) de accesar al
switch por completo.

28.6. Escenario: Ajustando Zona de Defensa 295
Figura 28.1: Un Escenario de Zona de Defensa.
Un switch D-Link de modelo DES-3226S es utilizado en este caso, con una dirección de
administración de interfaz 192.168.1.250 conectando a la dirección de interfaz del firewall
192.168.1.1. Esta interfaz de firewall es añadida en la lista excluyente para prevenir que el
firewall sea accidentalmente bloqueado para accesar el switch.
El diseño de red simplificado para este escenario es mostrado en la Figura 28.1.
WebUI
:
1. Switch
– añadir un nuevo switch en la sección de Zona de Defensa.
Zone Defense → Switches → Switch:

General
Name: switch1
Switch model: DES-3226S
IP Address: 192.168.1.250
(o utilice el nombre objetivo si ha sido definido en la dirección objetiva)
SNMP Community:
Ingrese en el recuadro de editar la serie de comunidad escrita configurada en el switch.
Presione el botón de Check Switch para verificar que el firewall puede comunicarse
con el switch y la serie correcta de comunidad es ingresada.

2. Lista Excluyente
– Añada la interfaz de administración del firewall en la lista excluyente.
Zone Defense → Exclude:

General
Direcciones:
Elija el nombre objetivo de la dirección de interfaz del firewall 192.168.1.1 desde la
lista Available y colóquelo en la lista Selected.
3. Regla Threshold
– configurando un threshold HTTP de 10 conexiones/segundo.
Zone Defense → Threshold → Add → Threshold:

→ General:
General:
Name: HTTP-Threshold
Service: HTTP
Address Filter
Source Destination
Interface: (la interfaz de administración del firewal) any
Network: 192.168.2.0/24(o el nombre objetivo) all-nets
→ Action:
Action: ZoneDefense
Host-based Threshold: 10

Parte XIII
Alta Disponibilidad
CAPITULO 29
Alta Disponibilidad
29.1 Alta Disponibilidad Básica

Esta sección incluye los siguientes tópicos
• Qué hace la Alta Disponibilidad por usted
• Qué es lo que NO hace la alta Disponibilidad por usted
• Ejemplo de Configuración de Alta Disponibilidad
La Alta Disponibilidad D-Link trabaja añadiendo un firewall de respaldo a su

Firewall existente. El firewall de respaldo tiene la misma configuración que el firewall
primario. Este se mantendrá inactivo, monitoreando el firewall primario, hasta que este
considere que el firewall primario no funcionará por más tiempo, ó a qué punto éste se
activará y asumirá el rol activo en el cluster. Cuando el otro firewall se vuelve respaldo,
éste asumirá un rol pasivo, monitoreando el firewall actualmente activo.
A través de este capítulo, las frases ”master firewall” y ”primary

firewall” son utilizados de manera intercambiable, como son las frases ”slave firewall” y
”back-up firewall”.
29.1.1 Qué hará la Alta Disponibilidad por usted

La Alta Disponibilidad D-Link le entregará un firewall de estado sincronizado
superfluo. Esto significa que el estado del firewall activo, ej.
299
300 Capítulo 29. Alta Disponibiidad
Tabla de conexión y otra información vital, esta copia continua del firewall
inactivo. Cuando el cluster falla sobre el firewall inactivo, Este conoce cuál
conexión está activa, y la comunicación puede continuar hacia el flujo
no interrumpido.
El tiempo del sistema de recuperación de fallos es de alrededor de un segundo en

el alcance de una retransmisión de tiempo de inactividad TCP normal, lo cual es
normalmente por sobre de un minuto. Los clientes conectados a través del firewall
experimentarán el procedimiento de recuperación de fallos como un leve golpe de
paquetes perdidos, un TCP siempre re-transmite en tales situaciones los paquetes
perdidos dentro de un segundo o dos, y continua con la comunicación.
29.1.2 Qué es lo que NO hace la Alta Disponibilidad por usted
Añadiendo la superfluidad a su configuración de firewall eliminará uno de los puntos de

falla en su trayectoria de comunicación. Sin embargo, esta no es una panacea para
todas las fallas posibles de comunicación.
Usualmente, su firewall está lejos de tener un sólo punto de falla.

La Superfluidad de sus routers, switches, y conexión interna son también temas que
necesitan ser dirigidos.
Los clusters de Alta Disponibilidad D-Link no crearán un cluster de compartición de carga.

Un firewall será activo, y el otro será inactivo.
Los firewalls de respaldo múltiples no pueden ser utilizados en un cluster. Sólo son soportados
dos firewalls, uno ”master” y uno ”slave”.
Como es el caso con todos los otros firewall que soportan el estado de recuperación de
fallos, la Alta Disponibilidad D-Link sólo trabajará entre dos Firewalls D-Link. Como
el trabajo interno de diferentes firewalls, y en efecto, mejores versiones diferentes del
mismo firewall, pueden ser radicalmente diferentes, no hay manera de comunicar el
”state” a algo que posee una comprensión completamente diferente de lo que
”state” significa.
Las interfaces rotas no serán detectadas por la implementación actual de la Alta

Disponibilidad, a menos que sean rotas en el punto donde el firewall no pueda
continuar corriendo. Esto significa que la recuperación de fallos no ocurrirá si el firewall
activo puede comunicarse manteniéndose con vida para el firewall inactivo a través de
cualquiera de sus interfaces, incluso aunque una o más interfaces puedan ser
inoperativas.
29.2. Cuan rápido puede ser logrado el failover 301
29.1.3 Ejemplo de configuración de la Alta Disponibilidad

Todas las interfaces del firewall primario necesitan ser presentados en el firewall de
respaldo, y conectados a la misma red. Como fue previamente mencionado el failover
no es realizado innecesariamente, de modo que cualquier firewall puede mantener el rol
activo del cluster por un período de tiempo extendido. Por lo tanto, el conectar algunos
equipos a sólo el ”master” o sólo el firewall ”slave” está ligado a producir resultados
no deseados.
Figura 29.1: Ejemplo de configuración de HA.
Como se puede ver en la figura 29.1, ambos firewalls están conectados a la red interna
así como a la red externa. Si hay más redes, por ejemplo una o más zonas desmilitarizadas,
o segmentos de redes internas, ambos firewalls tendrán que ser conectadas a tales redes;
el Sólo conectar el ”master” a la red será como guiar a perder la conectividad por
períodos de tiempo extendidos.
.
29.2 Cómo es logrado el Failover

Esta sección incluye los siguientes tópicos:
• La dirección IP compartida y el mecanismo de failover
• Latidos Cluster
• La interfaz de sincronización

302 Capítulo 29. Alta Disponibilidad
Esta sección detallará las características visible externas del mecanismo de failover,
y cómo trabajan juntos los dos firewalls para crear un cluster de alta disponibilidad
con tiempos de failover muy bajos.
Para cada cluster de interfaz, hay tres direcciones IP:
• Dos direcciones IP “reales”; uno para cada firewall. Estas direcciones son
utilizadas para comunicarse con los mismos firewalls, ej. para el control y
monitoreo remoto. Estos no deben ser asociados de ningún modo con el tráfico
que fluye por el cluster; si ningún firewall es inoperativo, la dirección IP asociada
será simplemente inalcanzable.
• Una dirección IP ”virtual”; compartida entre los firewalls. Esta es la dirección IP a

utilizar cuando se configura las puertas de enlace predeterminadas y otros
asuntos relacionados a routing. Es también la dirección utilizada por la traducción
de dirección dinámica, a menos que la configuración especifica explícitamente
otra dirección.
No hay mucho que decir acerca de las direcciones IP reales; estos actuarán tal como
las interfaces firewall normalmente lo hacen. Usted puede aplica pingo controlar
remotamente los firewalls por éstos si su configuración lo permite. Consultas ARP para
las direcciones respectivas son respondidas por el firewall que posee la dirección IP
utilizando la dirección hardware normal, tal como las unidades normales IP lo
hacen.
29.2.1 La dirección IP compartida y mecanismo de failover.
Ambos firewalls en el cluster conocen sobre la dirección IP compartida. Las consultas

ARP por la dirección IP compartida, o cualquier otra dirección IP publicada vía sección
de configuración ARP o por Proxy ARP, serán respondidas por el firewall activo.
La dirección hardware de la dirección IP compartida, y otras direcciones

publicadas para esos asuntos, no están relacionadas a las direcciones hardware de
las interfaces firewall. Mas bien, está construido desde el cluster ID, en la siguiente
forma: 10-00-00-C1-4A-nn, donde nn es el Cluster ID configurado en la sección de
ajustes.
Como la dirección IP compartida tiene siempre la misma dirección hardware, no habrá

tiempo de latencia en la actualización de caches ARP de unidades apegadas al mismo
LAN como el cluster cuando el failover ocurre.

29.2. Cuan rápido es logrado el Failover 303
Cuando un firewall descubre que su par ya no es operacional, este transmitirá un

número de consultas ARP para sí mismo, utilizando la dirección hardware compartida
como dirección de remitente, en todas las interfaces. Esto causa switches y puentes
para volver a aprender dónde enviar paquetes destinados para la dirección hardware
compartida en materia de milisegundos.
Por lo tanto, el único retraso real en el mecanismo de failover es detectar que un

firewall ya no es operacional.
Los mensajes de activación (consultas ARP) descritos anteriormente son transmitidos

periódicamente para asegurar que los switches no olviden dónde enviar paquetes
destinados para la dirección hardware compartida.
29.2.2 Latidos Cluster

Un firewall detecta que su par ya no es operacional cuando éste ya no percibe los
“latidos cluster” de su par.
Comúnmente, un firewall enviará cinco latidos cluster por segundo.
Cuando un firewall ha “perdido” tres latidos, ej. luego de 0.6 segundos, éste será declarado
inoperativo.
De modo que, ¿porqué no hacerlo aún más rápido? Tal vez enviar 100 latidos por segundo
y declarar a un firewall inoperativo luego de perder sólo dos de ellos?
Esto podría después de todo resultar en un tiempo de failover de.02-segundos.
El problema con los tiempos de detección de menos de un décimo por segundo es que
tales retrasos pueden ocurrir durante la operación normal. Sólo abriendo un archivo, en
cualquier firewall, podría resultar en un gran retraso suficiente para causar que el firewall
inactivo se vuelva activo, incluso si el otro firewall se encuentra aún activo; una situación
claramente no deseada.
Los latidos cluster tienen las siguientes características:
• La fuente IP es la dirección de interfaz del firewall enviado
• El destino IP es la dirección IP compartida
• El IP TTL es siempre 255.Si un firewall recibe un latido cluster con cualquier otro
TTL, es asumido que el paquete ha atravesado un router, y por lo tanto no puede
ser del todo confiable.

304 Capítulo 29. Ala Disponibilidad
• Es un paquete UDP, enviado desde puerto 999, a puerto 999.
• La dirección de destino MAC es la dirección Ethernet multicast correspondiente

a la dirección hardware compartida, ej. 11-00-00-C1-4A-nn. Link-level multicasts
son elegidos sobre paquetes unicast normales por razones de seguridad:
El utilizar paquetes unicast podría significar que un agresor local puede engañar
switches para dirigir latidos a algún otro lugar, causando que el par firewall
jamás perciba los latidos.
29.2.3 La interfaz de Sincronización

Ambos firewalls son conectados entre ellos por una conexión separada de
sincronización; son utilizadas tarjetas actuales de red, aunque estas estén dedicadas
exclusivamente para este propósito.
El firewall activo continuamente envía mensajes de actualización de estado a su par,

informando sobre las conexiones que son abiertas, conexiones que son cerradas,
cambios de estado y tiempo de vida en las conexiones, etc.
Cuando el firewall activo cesa de funcionar, por cualquier razón e incluso por un corto
tiempo, el mecanismo de latido cluster descrito anteriormente causará que el firewall
inactivo se vuelva activo. Puesto que este ya conoce todas las conexiones abiertas,
la comunicación puede continuar fluyendo ininterrumpidamente.
29.3 Ajustando un Cluster de Alta Disponibilidad

• Planificar el cluster de Alta Disponibilidad
• Crear un cluster de Alta Disponibilidad
Esta sección describe el proceso de instalar un cluster de Alta Disponibilidad.

Para una instalación exitosa, es altamente recomendado que sean leídas las secciones
previas, Alta Disponibilidad Básica y Qué tan rápido es logrado el failover.
Un cluster puede ser creado tanto instalando un par de nuevos firewalls, o convirtiendo
firewalls ya instalados en miembros cluster.
El firewall con la más alta versión numérica de su configuración asegurará siempre que la
configuración es transferida al otro miembro cluster.

29.3. Ajustando un Cluster de Alta Disponibilidad 305
El tópico a continuación describe la operación requerida para ajustar completamente un

cluster de Alta Disponibilidad.
29.3.1 Planificar el cluster de Alta Disponibilidad

Como un ejemplo durante toda esta guía, dos Firewalls D-Link son utilizados como
miembros cluster. Para simplificar esta guía, sólo dos de las interfaces en cada
miembro cluster son utilizadas para tráfico de red. Los siguientes ajustes son utilizados:
• Las interfaces LAN en el miembro cluster son ambas conectadas al mismo switch.
Este switch reside en una red interna con direcciones IP desde la red
192.168.10.0/24.
• Las interfaces WAN en los miembros cluster son ambos conectados a un segundo
Switch. Este switch reside en una red externa con direcciones IP desde la red
10.4.10.0/24.
• Las direcciones IP para las interfaces son designadas como es indicado por esta
tabla:
Interface Shared IP address Master IP address Slave IP address

LAN 192.168.10.1 192.168.10.2 192.168.10.3
WAN 10.4.10.1 10.4.10.2 10.4.10.3
• Las interfaces DMZ en los miembros cluster son utilizadas para sincronización
de estado, y por lo tanto conectadas entre ellos utilizando cable cruzado
Ethernet.
29.3.2 Creando un cluster de Alta Disponibilidad
Ejemplo: Configurando el Firewall como un Miembro Cluster
Cada firewall en el cluster tendrá que ser configurado para actuar tanto como un HA
master ó slave. Esto incluye la configuración de direcciones privadas (master y slave) y
direcciones IP compartidas en interfaces, así como seleccionando un cluster ID e
interfaz de sincronización.

WebUI
:
1. Configuración HA
System → High Availability:
Enable High Availability: Enable
Cluster ID: 0 (Seleccione un cluster ID apropiado)
Sync Interface: DMZ (En este ejemplo se utiliza la interfaz DMZ como interfaz sync)
Node Type: Master or Slave

2. Configuración de Par de Dirección HA

Se necesita crear un Par de Dirección HA objetiva para almacenar las direcciones
IP master y slave.
Objects → Address Book → Add → HA IP4 Address Pair:
Name: lan-priv-ip (Direcciones IP privadas para interfaz LAN)
Master IP Address: 192.168.10.2
Slave IP Address: 192.168.10.3
Objects → Address Book → Add → HA IP4 Address Pair:

Name: wan-priv-ip (Direcciones IP privadas para interfaz WAN)
Master IP Address: 10.4.10.2
Slave IP Address: 10.4.10.3
3. Configuración de Interfaz
IP Address: 192.168.10.1
Advanced/High Availability
Private IP Address: lan-priv-ip Then click OK
Interfaces → Ethernet → Edit (WAN):

Advanced/High Availability
Private IP Address: wan-priv-ip
Cuando la configuración es guardada y activada, el firewall actuará como un

miembro cluster HA.

29.4. Cosas que mantener en mente 307
Nota
Todas las interfaces Ethernet y VLAN deberán tener asignadas una dirección IP
privada cuando el firewall es configurado para ser miembro HA. Sin embargo, en este
ejemplo sólo se mostrará cómo configurar las interfaces LAN y WAN. Note que
es posible utilizar el mismo Par de Dirección HA IP4 objetiva en interfaces múltiples.
Cuando una modificación a la configuración en ambos firewalls ha sido guardada y

activada, la configuración será automáticamente transferida al otro miembro cluster.
No importa si la configuración fue modificada en el firewall master ó slave, como el
miembro cluster con el número de versión de configuración más alta siempre tratará
de transferir la configuración al otro miembro cluster.
29.4 Cosas que mantener en Mente

• Asuntos de Estadisticas y Registro
• Asuntos de Configuración
Incluso a través del cluster de Alta Disponibilidad se comportará como un solo firewall
desde muchos aspectos, hay algunas cosas que mantener en mente cuando se maneja
y configura.
29.4.1 Asuntos de Estadísticas y Registro

Estadísticas SNMP
Las estadísticas SNMP no son compartidas. Los administradores SNMP no tienen

capacidades de failover. De este modo, usted necesitará obtener ambos firewalls
en el cluster.
Los registros vienen desde dos firewalls
El registro de datos proviene desde dos firewalls. Esto significa que usted tendrá que
configurar su receptor de registro para recibirlos desde ambos firewalls. Esto también
significa que sus consultas de registro probablemente tendrán que incluir ambas fuentes de
Firewall, lo cual entregará todos los datos de registro en una vista resultante. Normalmente
el firewall inactivo no enviará entradas de registro sobre el tráfico con vida, así que la
salida se verá mucho como el camino que hizo con sólo un firewall.

29.4.2 Asuntos de Configuración

Cuando se configuran los clusters de Alta Disponibilidad, hay un número de cosas que
se deben mantener en mente con el fin de evitar riesgos innecesarios.
Modificando el cluster ID
Modificando el cluster ID, usted actualmente hace dos cosas:
• Modificando la dirección hardware de los IPs compartidos. Esto podría causar

problemas para todas las unidades añadidas al LAN local, cuando estos mantendrán
la vieja dirección hardware en sus caches ARP hasta que éste times out. Tales
unidades deberán tener sus caches ARP limpios
• Usted puede además romper la conexión entre los firewalls en el cluster

mientras que estos estén utilizando diferentes configuraciones. Esto podría causar
que ambos firewalls se vuelvan activos al mismo tiempo.
En resumen, no es buena idea modificar el cluster ID innecesariamente.
Luego de que la configuración ha sido cargada en ambos firewalls, los caches ARP de
unidades vitales deberán ser limpiados con el fin de restaurar la comunicación.
Jamás utilice IPs únicos para tráfico activo
Las únicas direcciones IP (privadas) de los firewalls no pueden ser utilizados de manera
segura para nada salvo manejar los firewalls.
El utilizarla para algo más: utilizarlas como Fuentes IPs en

conexiones dinámicamente NATed ó publicando servicios en estas, causará
problemas inevitablemente, como que los IPs únicos desaparecerán cuando el firewall
al que pertenecen lo hagan.

Parte XIV
Apéndice
INDEX
ABR, 75 DMZ, 14, 119, 150, 200, 204, 207,

ACL, 291 210
ActiveX, 156 DNS, 101
AES, 196 DoS, 47, 123, 263
AH, 214 DR, 75
ALG, 47 DSA, 197
ARP, 27 DST, 97
ARP, 66 DynDNS, 271
AS, 70
ASBRs, 75 ESP, 214
Ethernet, 53
Backbone area, 74 Ethernet address, 41
BDR, 75
Firewall, 9
Blowfish, 196
BOOTP, 60 GRE, 27, 45, 228
Brute force attack, 196
H.225, 159
CA, 49, 199 H.245, 160
CAST, 196 H.323, 158
Certificate, 49, 199, 221 High availability, 54
CHAP, 62, 134, 135, 229 Hop, 69
CRL, 50, 200, 222 HTTP, 155
Cryptography, 195 HTTPPoster, 273
HTTPS, 46, 136, 243
DES, 196
DH group, 218 IANA, 45
DHCP, 60, 275, 277 ICMP, 43
Dictionary attack, 229 ID Lists, 221
Diff-Serv, 247, 250 IDlist, 51
Digital signature, 198 IDS, 26
311
312 INDEX
IKE, 213 RSA, 197

IKE XAuth, 222
IP address, 39 SA, 215
IP spoofing, 123 SAT, 114, 115
IPsec, 27, 213 SNMP, 28, 292
SNTP, 98
L2TP, 27, 228 SPF, 76
LAN, 53, 56 Spoofing, 123
LCP, 62 SSL, 136, 243
LDAP, 50, 222 Stub area, 75
LSA, 76 SYN flooding, 47
Man-in-the-middle attack, 198, T.120, 160

229 TLS, 136, 243
MCUs, 159 ToS, 250
MIB, 293 Twofish, 196
MPPE, 229
UDP/TIME, 98
NAT, 112, 218 URL, 157
NAT, 112
NCPs, 62 VLAN, 56
NTP, 98 VLink, 74
VoIP, 158
OSI, 7 VPN, 13, 193, 207
OSPF, 73, 74
WWW, 155
PAP, 62, 135, 229
PBR, 88
PFS, 217
PPP, 27, 62, 135, 228
PPPoE, 27, 61
PPTP, 27, 228
Proxy ARP, 94
PSK, 216, 220
QoS, 247, 250
RADIUS, 135
Replay attack, 229
RIP, 72
Route, 69
RouteFailover, 77
Router priority, 75
Routing table, 69

APENDICE A
Referencia De Comandos de Consola
Este Apéndice contiene la lista de comandos que pueden ser utilizados en CLI para
Monitorear y solucionar problemas en el firewall. Para información sobre cómo acceder
Desde un PC ó terminal, refiérase a 4.2, Monitoreo Via CLI.
Lista de Comandos
Al respecto
Entrega información referente a la versión del núcleo del firewall en uso y una notificación
copyright.
• Syntax: about
Ejemplo:
Cmd> about
D-Link DFL 2.01.00V

Copyright Clavister 1996-2005. All rights reserved
SSH IPSEC Express SSHIPM version 5.1.1 library 5.1.1
Copyright 1997-2003 SSH Communications Security Corp.
Build : Jun 3 2005
313
314 Capitulo A. Referencia de Comandos de Consola
Acceso
Despliega los contenidos de la sección de configuración de Acceso.
• Syntax: access
Ejemplo:
Cmd> access
Source IP Address Access list (protección spoofing)

Rule Name Action Iface Source Range
----------------- ------ ----------------- -------------
Si no coincide una regla de acceso, las reglas PBR serán utilizadas para seleccionar
Una tabla routing para ser utilizada en la búsqueda de ruta reversiva. Si la búsqueda
De ruta falla, la acción será rechazada.
ARP
Despliega entradas ARP para la interfaz especificada. Publicadas, son mostrados items
tanto estático como dinámico.
• Syntax: arp [options] <interface pattern>
• Opciones:
- ip <pattern> –Despliega sólo direcciones IP coincidentes <pattern>
- hw <pattern> –Despliega sólo direcciones hardware coincidentes <pattern>
- num <n> –Despliega sólo la primera <n> entrada por iface (default: 20)
- hashinfo –Despliega información en la tabla de salud hash
- flush –limpia el cache ARP de TODAS las interfaces
- flushif –Limpia el cache ARP cache de una

interface
Ejemplo:
Cmd> arp wan
ARP cache of iface wan

Dynamic 194.2.1.1 = 0020:d216:5eec Expire=141

315
ARPSnoop
Alternar el despliegue en pantalla de consultas ARP. Este comando puede ser de gran
Ayuda en la configuración del hardware firewall, ya que este muestra cuales
Direcciones IP son percibidas en cada interfaz.
• Syntax:
- arpsnoop <interface pattern>

Alternar rastreo en interfaces entregadas.
- arpsnoop all
rastrea todas las interfaces.
- arpsnoop none
Desactiva todo rastreo
Ejemplo:
Cmd> arpsnoop all
ARP snooping active on interfaces: lan wan dmz

ARP on wan: gw-world requesting ip ext
ARP on lan: 192.168.123.5 requesting lan ip
...
Buffers
Este comando puede ser útil en la solución de problemas; ej. si un gran número
inesperado
de Paquetes comienzan a consultar en el firewall cuando el tráfico no pareciera estar
fluyendo por alguna razón inexplicable. Al analizar los contenidos de los buffers, es
posible determinar dónde tal tráfico está trabajando en el firewall completo.
• Syntax:
-- buffers
Entrega una lista de los buffers más recientemente liberados.
Ejemplo:

Cmd> buffers
Displaying the 20 most recently freed buffers

RecvIf Num Size Protocol Sender Destination
------ ---- --- -------- --------------- ---------------
wan 1224 121 UDP 192.168.3.183 192.168.123.137
lan 837 131 UDP 192.168.123.137 192.168.3.183
wan 474 112 UDP 192.168.3.183 192.168.123.137
wan 395 91 UDP 192.168.3.183 192.168.123.137
...
-- buffer <number>
Muestra los contenidos del buffer especificado.
Ejemplo:
Cmd> buff 1059
Decodificación de número buffer 1059

lan:Enet 0050:dadf:7bbf->0003:325c:cc00, type 0x0800, len 1058
IP 192.168.123.10->193.13.79.1 IHL:20 DataLen:1024 TTL:254
Proto:ICMP
ICMP Echo reply ID:6666 Seq:0
-- buffer .
Muestra los contenidos del buffer más recientemente utilizado.
Ejemplo:
Cmd> buff .
Decodificación de número buffer 1059

lan:Enet 0050:dadf:7bbf->0003:325c:cc00, type 0x0800, len 1058
IP 192.168.123.10->193.13.79.1 IHL:20 DataLen:1024 TTL:254
Proto:ICMP
ICMP Echo reply ID:6666 Seq:0
Certcache
Despliega los contenidos del certificado cache.
• Syntax: certcache

317
CfgLog
Muestra el resultado de la configuración más reciente ó reinicia el firewall. Este
texto es el mismo que se muestra en pantalla durante la reconfiguración ó
reinicio.
• Syntax: cfglog
Ejemplo:
Cmd> cfglog
Configuration log: License file successfully loaded.

Configuration done
Conexiones
Muestra las últimas 20 conexiones abiertas por el firewall. Las conexiones son creadas
cuando el tráfico es permitido de pasar vía reglas Allow o NAT. El tráfico permitido de
pasar bajo FwdFast no es incluído en esta lista.
Cada conexión tiene dos valores de Tiempo de inactividad, uno en cada dirección. Estos
son actualizados cuando el firewall recibe paquetes desde cada extremo de la conexión.
El valor mostrado en la columna de Tiempo de inactividad es el más bajo de los dos
valores. Los valores posibles en la columna de State incluyen:
- SYN RECV TCP paquete con SYN flag recibido
- SYNACK S TCP paquete con SYN + ACK flags enviados
- ACK RECV TCP paquete con ACK flag recibido
- TCP OPEN TCP paquete con ACK flag enviado
- FIN RECV TCP paquete con FIN/RST flag recibido
- PING La conexión es una conexión ICMP ECHO
- UDP La conexión es una conexión UDP
- RAWIP La conexión utiliza un protocolo IP aparte de TCP, UDP o

ICMP
• Syntax: conexiones

Ejemplo:
Cmd> conn
State Proto Source Destination Tmout

--------- ----- ------------------ ---------------- ------
TCP OPEN TCP wan:60.20.37.6:5432 dmz:wwwsrv:80 3600
SYN RECV TCP wan:60.20.37.6:5433 dmz:wwwsrv:80 30
UDP OPEN UDP lan:10.5.3.2:5433 dmz:dnssrv:53 50
Cpuid
Muestra información respecto al CPU en el hardware firewall.
• Syntax: cpuid
Ejemplo:
Cmd> cpuid
Processor: Intel Pentium 4

Est. frequency: 1402 MHz
Family: 15
Model: 0
Stepping: 10
Vendor ID: GenuineIntel
Type: Original OEM Processor
Logical CPUs (HTT): 1
Feature flags: fpu vme de pse tsc msr pae mce cx8 apic
sep mtrr pge mca cmov pat pse-36 clfsh
ds acpi mmx fxsr sse sse2 ss htt tm
Cache and TLB information:
0x66: 1st-level data cache: 8-KB, 4-way set associative,
sectored cache, 64-byte line size
...
DHCP
• Syntax: dhcp [options] <interface>
• Options:
- renew – Fuerza a la interfaz a renovar su contrato

- release – Fuerza a la interfaz a liberar su contrato
Ejemplo:
Cmd> dhcp -renew wan

319
DHCPRelay
Muestra los contenidos del la sección de configuración de la
retransmisión DHCP.
• Syntax: dhcprelay [options]
• Opciones:
- release ip – Libera el IP y remueve las rutas asociadas desde el firewall.
Ejemplo:
Cmd> dhcprelay
Servidor DHCP
Muestra los contenidos de la sección de configuración del servidor DHCP y activa los
contratos DHCP.
• Syntax: dhcpserver [options]
• Opciones:
- rules – Muestra reglas de servidor DHCP
- leases – Muestra contraltos de servidor DHCP
- mappings – Muestra servidor IP DHCP→MAC mapeos
- release – Libera un IP active ó en lista negra
Ejemplo:
Cmd> dhcpserver
DynRoute
Despliega la regla de ajuste de filtro de política de routing dinámico y exportaciones
actuales.
• Syntax: dynroute [options]
• Options:
- rules – Despliega regla de ajuste de filtro de routing dinámico
- exports – Despliega exportaciones actuales

Frags
Muestra los 20 intentos de reensamblaje de fragmentos más recientes. Esto incluye
ambos intentos en curso y completados.
• Syntax: frags
Ejemplo:
Cmd> frags
RecvIf Num State Source Dest. Protocol Next Tout

------ --- ----- ------ --------- -------- ---- ----
lan 2 Done 10.5.3.2 26.23.5.4 ICMP 2000 58
wan 8 Accept 23.3.8.4 10.5.3.2 ICMP 1480 60
HA
Muestra información sobre el cluster HA.
• Syntax: ha
Ejemplo:
Cmd> ha
Este dispositivo es un HA SLAVE

Este dispositivo es actualmente ACTIVE (reenviará tráfico)
El par cluster HA está ALIVE
HTTPPoster
Muestra el httpposter urls configurado y estado.
• Syntax: httpposter [options]
• Opciones:
- repost – Re-post todos los URLs ahora.

321
Ejemplo:
Cmd> httpposter
HTTPPoster URL1:
Host : ""
Port : 0
Path : ""
Post : ""
User : ""
Pass : ""
Status: (no configurado)
...
Ifacegroups
Muestra los grupos de interfaz configurados.
• Syntax: ifacegroups <name pattern>
Ejemplo:
Cmd> ifacegroups
Configured interface groups

--------------------------------
internals lan,vlan1,vlan2,vlan3
IfStat
• Syntax:
-- ifstat
Muestra una lista de las interfaces instaladas en el firewall.
Ejemplo:
Cmd> ifstat
Interfaces configuradas:
Interface name IP Address Interface type
-------------- ------------ -------------
core 127.0.0.1 Null (sink)
wan 172.16.87.252 ...
lan 192.168.121.1 ...

-- ifstat <interface>
Muestra las estadisticas hardware y software para el NIC especificado.
Ejemplo:
Cmd> ifstat lan
Iface lan
...
MTU : ...
IP Address : ...
Hw Address : ...
Software Statistics:
Soft received: ... Soft sent: ... Send failures: ...
Dropped: ... IP Input Errs: ...
Driver information / hardware statistics:
...
El contador Dropped en la sección de software expone el número de paquetes
desechados como el resultado de test de integridad estructural ó reglas de ajuste drops
del firewall.
El contador IP Input Errs en la sección de software especifica el número de paquetes
desechados debido a los errores checksum ó encabezados IP rotos mas allá de
reconocimiento. El ultimo es más como el resultado de problemas de red local más
que ataques remotos.
Ikesnoop
Ikesnoop es utilizado para diagnosticar problemas con túneles IPsec.
• Syntax:
-- ikesnoop
Despliega en actual estado ikesnoop.
-- ikesnoop off
Apaga el IKE.
-- ikesnoop on [ipaddr]
Enciende el IKE, si un IP es especificado sólo el tráfico ike de ese IP
será mostrado.
-- ikesnoop verbose [ipaddr]

Habilita el verbose output, si un IP es especificado sólo el tráfico ike de ese
IP será mostrado.

323
Ipseckeepalive
Muestra el estado de las conexiones configuradas Ipsec keepalive.
• Syntax: ipseckeepalive
Ejemplo:
Cmd> ipseckeepalive
192.168.0.10 -> 192.168.1.10: Consecutive lost: 0, sent:

908, lost: 2
192.168.1.10 -> 192.168.0.10: Consecutive lost: 0, sent:
913, lost: 6
IPSectunnels
Despliega las conexiones IPSec VPN configuradas.
• Syntax: ipsectunnels
Ejemplo:
Cmd> ipsectunnel
No Name Local Net Remote Net Remote GW

0 vpn-home 192.168.123.0/24 0.0.0.0/0 None
MAIN MODE SA PER NET DONT VERIFY PAD IKE group: 2
IKE proplist: ike-default, IPsec proplist:
esp-tn-roamingclients
IPSecstats
Despliega puertas de enlace IPSec VPN conectadas y clientes remotos.
• Syntax: ipsecstats [options]
• Opciones:
- ike Despliega SAs IKE
- ipsec Despliega SAs IPsec (predeterminado)
-u Despliega información estadística SA detallada
-v Despliega información verbose

- num <n> Número máximo de entradas a desplegar (predeterminado: 40/8)

Nota: si se ajusta a 0, TODAS las entradas serán desplegadas
Ejemplo:
Cmd> ipsecstats
--- IPsec SAs:

Despliega una línea por SA-bundle
...
Killsa
Mata todos los IPsec y IKE SAs para la dirección IP especificada.
• Syntax: killsa <ipaddr>
Ejemplo:
Cmd> killsa 192.168.0.2
Destruye todos los IPsec & IKE SAs por par remoto 192.168.0.2
Licencia
Muestra en contenido del archivo de licencia. Es además posible remover una licencia
desde un firewall corriendo con este commando, removiendo la licencia.
• Syntax: license [remove]
Ejemplo:
Cmd> lic
Contenidos del archivo de Licencia

----------------------------
Registration key: ...
Bound to MAC address: ...
Model: DFL-...
Registration date: ...
Issued date: ...
Last modified: ...
New upgrades until: ...
Ethernet Interfaces: ...

...

325
Lockdown
Ajusta el bloqueo local a encendido ó apagado. Durante el bloqueo local, sólo el
tráfico de nets admin al firewall mismo es permitido. Cualquier otra cosa es
desechada
Nota: Si el bloqueo local ha sido ajustado por el núcleo mismo debido a problemas
de
licencia o configuración, este comando NO removerá tal bloqueo
• Syntax: lockdown [ on | off ]
Loghosts
Muestra la lista del destinatario de registro al que el firewall está configurado a enviar
datos de registro.
• Syntax: loghosts
Ejemplo:
Cmd> loghosts
Log hosts:
SysLog 192.168.123.10 Facility: local0
Utiliza registro en intervalos de 3600.
Memoria
Despliega el consume de núcleo de memoria. También despliega el uso de la memoria detallada
por algunos componentes y listas.
• Syntax: memory
Netcon
Muestra una lista de usuarios actualmente conectados al firewall vía protocolo de
administración netcon.
• Syntax: netcon
Ejemplo:
Cmd> netcon
Currently connected NetCon users:

Iface IP address port
lan 192.168.123.11 39495

Netobjects
Despliega la lista de su red nombrada objetiva y sus contenidos. Si una net
objetiva es especificada la salida mostrará información de autentificación del usuario
asociada con ese objeto.
• Syntax: netobjects [options]
• Options:
- num <number> Maximo de objetos enlistados (predeterminado: 20)
- dump hace netobject dump MUCHO más detallado (debug cmds)
OSPF
Muestra información de la información del tiempo de ejecución acerca de procesos de
Router OSPF y es utilizado para detener/iniciar procesos OSPF).
• Syntax: ospf [<process name>] [<parameter>]

[<argument>]
• Parámetros disponibles:
- iface [<iface>], Despliega información de interfaz
- area [<areaID>], Despliega información de área
- neighbor [<if>:][<neiID>], Despliega información del vecino
- route, Despliega la table routing del proceso interno OSPF
- database [verbose], Despliega la base de datos LSA
- lsa <lsaID>, Despliega detalles para un LS especificado
- snoop [on | off], Despliega mensajes de troubleshooting en la consola
- ifacedown <iface>, Toma la interfaz especificada fuera de línea
- ifaceup <iface>, Toma la interfaz especificada en línea
- stop, Detiene el proceso OSPF
- start, Inicia el proceso OSPF
- restart, Reinicia el proceso OSPF

327
• Parámetros de depuración:
- spf, Ejecuta un cálculo completo SPF
- refresh, Refresca todos los LSAs originados en el proceso
- ifacemetric <if> <metric>, Modifica la métrica de una interfaz
Ping
Envía un número específico de paquetes ICMP Echo Request a un destino entregado.
todos los paquetes son enviados en sucesión inmediata más que uno por segundo.
Esta conducta es la más apropiada para diagnosticar problemas de conectividad.
• Syntax: ping <IPAddr> [options] [< of packets>

[<size>]]
• Opciones:
- r <recvif>, Corre a través de la Regla de ajustes, simulando que los paquetes fueron
Recibidas por <recvif>.
- s <srcip>, Utiliza esta fuente IP.
- p <table>, Dirige utilizando la tabla PBR especificada.
- v, Verbose ping.
Ejemplo:
Cmd> ping 192.168.12.1
Al enviar 1 ping a 192.168.12.1 desde 192.168.14.19 utilizando la tabla “main” PBR.

Echo responde desde 192.168.12.1 seq=0 time= 10 ms
TTL=255
Conductos
Muestra la lista de conductos configurados; los contenidos de la sección de configuración
de conductos, junto con las figures de rendimiento básicas de cada conducto.
• Syntax: pipes [options] <name>
• Opciones:
-s Despliega estadísticas globales

-u Despliega los usuarios de un conducto entregado <name>
Ejemplo:
Cmd> pipes
Configured pipes:
Name Grouping Bits/s Pkts/s Precedence
----- ------- ------ ------ ----------
std-in Per DestIP 017
Current: 42.5 K 21.0
...
Proplists
Enlista las listas propuesta configuradas.
• Syntax: proplists [vpnconn]
Ejemplo:
Cmd> propl
Desplegando todas las listas propuestas configuradas:

ike-default
...
ReConfigurar
Re-lee el archive FWCore.cfg desde el disco. Este proceso toma aproximadamente un
segundo si se realiza desde el disco floppy, y aproximadamente una décima de segundo
desde el disco duro ó disco flash. Si hay un archivo FWCore N.cfg presentado en el disco,
éste será leído en cambio. Sin embargo, como no hay Administrador de Firewall para
intentar dos medios de comunicación con el firewall, éste concluirá que la configuración es
incorrecta y revertirá a FWCore.cfg luego de que la verificación bi-direccional del período
de tiempo de inactividad ha expirado (típicamente 30 segundos).
• Syntax: reconfiure
Ejemplo:
Cmd> reconfigure
Shutdown RECONFIGURE. Activo en 1 segundo.

Shutdown reason: Reconfigurar debido a consola de comando

329
Remotos
Muestra los contenidos de la sección de Configuración Remota.
• Syntax: remotes
Ejemplo:
Cmd> remotes
Hosts/nets con control remote del firewall:

...
WebUI HTTP (puerto 80) y acceso HTTPS (puerto 443)
Rutas
Despliega la información acerca de las tablas de routing, contenidos de una (nombrada)
tabla routing ó una lista de tablas routing, junto con una cuenta total de entradas de ruta
en cada tabla, así como cuantas de las entradas son rutas de un solo anfitrión.
Note que las rutas “núcleo” por direcciones de interfaz IP no son normalmente mostradas,
Utilice el switch de ”-all” para mostrar las rutas “núcleo” también.
En el recuadro de ”Flags” de las tablas routing, las siguientes letras son utilizadas:
O: Aprendido vía OSPF X: Ruta es Deshabilitada

M: Ruta es Monitoreada A: Publicada vía Proxy ARP
D: Dinámico (desde e.j. transmisión DHCP, IPsec, servidores L2TP/PPP, etc.)
• Syntax: rutas [opciones] <table name>
• Opciones:
- all, También muestra rutas para direcciones de interfaz
- num <n>, Despliegue límite a <n> entradas (predeterminado: 20)
- nonhost, No muestra rutas de un sólo anfitrión
- tables, Despliega una lista de tablas routing nombradas (PBR)
- lookup <ip>, Busca la ruta para la dirección IP entregada
- v, Verbose

330 Capitulo A. Referencias de Comandos de Consola
Reglas
Muestra los contenidos de la sección de configuración de Reglas.
• Syntax: rules [options] <range>

El parámetro de rango especifica cuáles reglas incluir en la salida de este
comando.
• Opciones:
- r, Muestra políticas basadas en reglas de ajuste de ruteo
- p, Muestra regla de ajuste de conductos
- i, Muestra regla de ajuste de detección de intrusos
- t, Muestra regla de ajustes threshold
- v, Be verbose: muestra todos los parámetros de las reglas
- s, Filtra las reglas que no son actualmente permitidas por programas seleccionados
Ejemplo:
Cmd> rules -v 1
Contenidos de la regla de ajuste; la acción predeterminada es desechada

Act. Source Destination Protocol/Ports
-- ----- -------------- -------------- ---------------
1 Allow lan: ... core: ... "HTTP"
"HTTP-fw" Use: 0 FWLOG:notice SYSLOG:notice
Scrsave
Activa el salva pantallas incluídas con el núcleo del firewall.
• Syntax: scrsave
Ejemplo:
Cmd> scr
Activating screen saver...

331
Services
Despliega la lista de servicios nombrados. Los servicios definidos implícitamente dentro
de las reglas no son desplegados.
• Syntax: services [name or wildcard]
Ejemplo:
Cmd> services
Configured services:
HTTP TCP ALL > 80
Shutdown
Instruye al firewall para ejecutar un reinicio dentro de un número de segundos.
No es necesario ejecutar un reinicio antes de que el firewall sea apagado, y cuando
éste no mantiene ningún archive abierto mientras corre.
• Syntax: shutdown <seconds>

-- Shutdown in <n> seconds (default: 5)
Sysmsgs
Muestra los contenidos del buffer OS sysmsg.
• Syntax: sysmsgs
Ejemplo:
Cmd> sysmsg
Contenidos del buffer OS sysmsg:

...
Ajustes
Muestra los contenidos de la sección de configuración de Ajustes.
• Syntax:
-- settings Shows available groups of settings.

Exjemplo:
Cmd> sett
Categorías disponibles en la sección de Ajustes:
IP - IP (Internet Protocol) Settings
TCP - TCP (Transmission Control Protocol) Settings
ICMP - ICMP (Internet Control Message Protocol)
ARP - ARP (Address Resolution Protocol) Settings
State - Stateful Inspection Settings
ConnTimeouts - Default Connection timeouts
LengthLim - Default Length limits on Sub-IP Protocols
Frag - Pseudo Fragment Reassembly settings
LocalReass - Local Fragment Reassembly Settings
VLAN - VLAN Settings
SNMP - SNMP Settings
DHCPClient - DHCP (Dynamic Host Configuration Protocol)
Client Settings
DHCPRelay - DHCP/BOOTP Relaying Settings
DHCPServer - DHCP Server Settings
IPsec - IPsec and IKE Settings
Log - Log Settings
SSL - SSL Settings
HA - High Availability Settings
Timesync - Time Synchronization Settings
DNSClient - DNS Client Settings
RemoteAdmin - Settings regarding remote administration
Transparency - Settings related to transparent mode
HTTPPoster - Post user-defined URLs periodically
for e.g. dyndns registration, etc
WWWSrv - Settings regarding the builtin web server
HwPerformance - Hardware performance parameters
IfaceMon - Interface Monitor
RouteFailOver - Route Fail Over Default values
IDS - Intrusion Detection / Prevention Settings
PPP - PPP (L2TP/PPTP/PPPoE) Settings
Misc - Miscellaneous Settings

333
-- settings <group name>

Muestra los ajustes del grupo especificado.
Ejemplo:
Cmd> settings arp
ARP (Address Resolution Protocol) Settings

ARPMatchEnetSender : DropLog
ARPQueryNoSenderIP : DropLog
ARPSenderIP : Validate
UnsolicitedARPReplies : DropLog
ARPRequests : Drop
ARPChanges : AcceptLog
StaticARPChanges : DropLog
ARPExpire : 900 ARPExpireUnknown : 3
ARPMulticast : DropLog
ARPBroadcast : DropLog
ARPCacheSize : 4096 ARPHashSize : 512
ARPHashSizeVLAN : 64
Estadisticas
Muestra varias estadísticas vitales y contadores.
• Syntax: stats
Ejemplo:
Cmd> stats
Uptime : ...
Last shutdown : ...
CPU Load :6
Connections : 4919 out of 32768
Fragments : 17 out of 1024 (17 lingering)
Buffers allocated : 1252
Buffers memory : 1252 x 2292 = 2802 KB
Fragbufs allocated : 16
Fragbufs memory : 16 x 10040 = 156 KB
Out-of-buffers :0
ARP one-shot cache : Hits : 409979144 Misses : 186865338
Interfaces: Phys:2 VLAN:5 VPN:0
Access entries:18 Rule entries:75
Usar el archivo de configuración "FWCore.cfg", ver ...

Tiempo
Despliega el sistema de fecha y tiempo
• Syntax: time [options]
• Opciones:
- set <arg>, Ajusta el sistema de tiempo local (YYYY-MM-DD HH:MM:SS)
- sync, Sincroniza el tiempo con servidores de tiempo (especificados en ajustes)
- force, Fuerza la sincronización a pesar del ajuste MaxAdjust
Uarules
Despliega los contenidos de la regla de ajuste de autentificación del
usuario.
• Syntax: uarules [options] <range>
• Options:
- v, (verbose)muestra todos los parámetros de las reglas de autentificación del

usuario
Ejemplo:
Cmd> uarules -v 1-2
Contenidos de la regla de Ajuste de Autentificación del Usuario

Source Net Agent Auth source Auth. Server
-- ------------------ ------- ---------- -------------
1 if1:192.168.0.0/24 HTTPAuth RADIUS FreeRadius
2 *:0.0.0.0/0 XAuth RADIUS IASRadius
Userauth
Despliega a los usuarios actualmente registrados y otra información. Además permite
a los usuarios registrados ser desconectados por la fuerza.
• Syntax: userauth [options]
• Options:
- l, despliega una lista de todos los usuarios autentificados
- p, despliega una lista de todos los privilegios conocidos (nombres de usuario y

grupos)
335
- v <ip>, despliega toda la info conocida por los usuarios con esta IP
- r <ip> <interface>, desconecta a la fuerza a usuarios autentificados
- num <num>, número máximo de usuarios autentificados para enlistar

(predeterminado 20)
Ejemplo:
Cmd> userauth -l
Usuarios actualmente autentificados:

Login IP Address Source Ses/Idle Privileges
Interface Timeouts
-------- --------------- --------- --------- -----------
user1 ... ... 1799 members
...
Userdb
Enlista base de datos de usuario y sus contenidos.
• Syntax: userdb <dbname> [<wildcard> or <username>]

Si es especificado <dbname> los usuarios configurados en ésa base de datos
de usuario serán mostrados. Una invitación puede ser utilizada para sólo mostrar
usuarios que coinciden con ese patrón ó si un nombre de usuario es información
especificada concerniente a que ese usuario debe ser mostrado.
• Opciones:
- num, Despliega el número especificado de usuarios (predeterminado 20)
Ejemplo:
Cmd> userdb
Configured user databases:

Name users
------------- -------
AdminUsers 1

Ejemplo:
Cmd> userdb AdminUsers
Configured user databases:

Username Groups Static IP Remote Networks
-------- -------------- ---------- -----------------
admin administrators
Ejemplo:
Cmd> userdb AdminUsers admin
Information for admin in database AdminUsers:

Username : admin
Groups : administrators
Networks :
Vlan
Muestra información sobre los VLANs configurados.
• Syntax:
-- vlan
List attached VLANs
jemplo:
Cmd> vlan
VLANs:
vlan1 IPAddr: 192.168.123.1 ID: 1 Iface: lan

337
-- vlan <vlan>
Muestra información acerca de VLANs especificados.
Ejemplo:
Cmd> vlan vlan1
VLAN vlan1
Iface lan, VLAN ID: 1
Iface : lan
IP Address : 192.168.123.1
Hw Address : 0003:474e:25f9
Software Statistics:
Soft received : 0 Soft sent: 0 Send failures: 0
Dropped : 0 IP Input Errs : 0


APENDICE B
Soporte al Cliente
339
340 Capitulo B. Soporte al Cliente
Oficinas Internacionales
Paises Bajos
Weena 290
U.S.A 3012 NJ, Rotterdam
17595 Mt. Herrmann Street Paises Bajos
Fountain Valley, CA 92708 Tel: +31-10-282-1445
TEL: 1-800-326-1688 Fax: +31-10-282-1331
URL: www.dlink.com URL: www.dlink.nl
Canada Belgica
2180 Winston Park Drive Rue des Colonies 11
Oakville, Ontario, L6H 5W1 B-1000 Brussels
Canada Belgium
TEL: 1-905-8295033 Tel: +32(0)2 517 7111
FAX: 1-905-8295223 Fax: +32(0)2 517 6500
URL: www.dlink.ca URL: www.dlink.be
Europa (U. K.) Italia

4th Floor, Merit House Via Nino Bonnet n. 6/b
Edgware Road, Colindale 20154 Milano
London NW9 5AB Italia
U.K. TEL: 39-02-2900-0676
TEL: 44-20-8731-5555 FAX: 39-02-2900-1723
FAX: 44-20-8731-5511 URL: www.dlink.it
URL: www.dlink.co.uk
Suecia
Alemania P.O. Box 15036,
Schwalbacher Strasse 74 S-167 15 Bromma
D-65760 Eschborn Suecia
Alemania TEL: 46-(0)8564-61900
TEL: 49-6196-77990 FAX: 46-(0)8564-61901
FAX: 49-6196-7799300 URL: www.dlink.se
URL: www.dlink.de
Dinamarca
Francia Naverland 2,
No.2 allee de la Fresnerie DK-2600 Glostrup,
78330 Fontenay le Fleury Copenhagen
Francia Dinamarca
TEL: 33-1-30238688 TEL: 45-43-969040
FAX: 33-1-30238689 FAX: 45-43-424347
URL: www.dlink.fr URL: www.dlink.dk

341
Noruega Suiza
Karihaugveien 89 Glatt Tower, 2.OG CH-8301
N-1086 Oslo Glattzentrum Postfach 2.OG
Noruega Suiza
TEL: +47 99 300 100 TEL : +41 (0) 1 832 11 00
FAX: +47 22 30 95 80 FAX: +41 (0) 1 832 11 01
URL: www.dlink.no URL: www.dlink.ch
Finlandia Grecia
Latokartanontie 7A 101, Panagoulis Str. 163-43
FIN-00700 Helsinki Helioupolis Athens,
Finlandia Grecia
TEL: +358-10 309 8840 TEL : +30 210 9914 512
FAX: +358-10 309 8841 FAX: +30 210 9916902
URL: www.dlink.fi URL: www.dlink.gr
España Luxemburgo
C/Sabino De Arana Rue des Colonies 11,
56 Bajos B-1000 Brussels,
08028 Barcelona Belgica
España TEL: +32 (0)2 517 7111
TEL: 34 93 4090770 FAX: +32 (0)2 517 6500
FAX: 34 93 4910795 URL: www.dlink.be
URL: www.dlink.es
Polonia
Portugal Budynek Aurum ul. Walic-w 11
Rua Fernando Pahla PL-00-851 Warszawa
50 Edificio Simol Polonia
1900 Lisbon TEL : +48 (0) 22 583 92 75
Portugal FAX: +48 (0) 22 583 92 76
TEL: +351 21 8688493 URL: www.dlink.pl
URL: www.dlink.es
Hungría
Repúbica Checa R-k-czi-t 70-72
Vaclavske namesti 36, Praha 1 HU-1074 Budapest
República Checa Hungría
TEL :+420 (603) 276 589 TEL : +36 (0) 1 461 30 00
URL: www.dlink.cz FAX: +36 (0) 1 461 30 09
URL: www.dlink.hu

Singapur Egypto
1 International Business Park 19 El-Shahed Helmy, El Masri
03-12The Synergy Al-Maza, Heliopolis
Singapur 609917 Cairo, Egypto
TEL: 65-6774-6233 TEL:+202 414 4295
FAX: 65-6774-6322 FAX:+202 415 6704
URL: www.dlink-intl.com URL: www.dlink-me.com
Australia Israel
1 Giffnock Avenue 11 Hamanofim Street
North Ryde, NSW 2113 Ackerstein Towers,
Australia Regus Business Center P.O.B 2148,
TEL: 61-2-8899-1800 Hertzelia-Pituach 46120
FAX: 61-2-8899-1868 Israel
URL: www.dlink.com.au TEL: +972-9-9715700
FAX: +972-9-9715601
India URL: www.dlink.co.il
D-Link House, Kurla Bandra
Complex Road OffCST Road, LatinAmerica
Santacruz (East) Isidora Goyeechea 2934
Mumbai - 400098 Ofcina 702
India Las Condes
TEL: 91-022-26526696/56902210 Santiago Chile
FAX: 91-022-26528914 TEL: 56-2-232-3185
URL: www.dlink.co.in FAX: 56-2-232-0923
URL: www.dlink.cl
Oriente Medio (Dubai)
P.O.Box: 500376 Brasil
Office: 103, Building:3 Av das Nacoes Unidas
Dubai Internet City 11857 14- andar - cj 141/142
Dubai, Emiratos Arabes Unidos Brooklin Novo
Tel: +971-4-3916480 Sao Paulo - SP - Brasil
Fax: +971-4-3908881 CEP 04578-000 (Zip Code)
URL: www.dlink-me.com TEL: (55 11) 21859300
FAX: (55 11) 21859322
Turquía URL: www.dlinkbrasil.com.br
Ayazaga Maslak Yolu
Erdebil Cevahir Is Merkezi
5/A Ayazaga Istanbul
Turquia
TEL: +90 212 289 56 59
FAX: +90 212 289 76 06
URL: www.dlink.com.tr

343
SudAfrica China
Einstein Park II No.202,C1 Building,
Block B Huitong Office Park,
102-106 Witch-Hazel Avenue No. 71, Jianguo Road,
Highveld Technopark Chaoyang District,
Centurion Beijing 100025, China
Gauteng Republic of South Africa TEL +86-10-58635800
TEL: 27-12-665-2165 FAX: +86-10-58635799
FAX: 27-12-665-2186 URL: www.dlink.com.cn
URL: www.d-link.co.za
Taiwan
Rusia 2F, No. 119, Pao-Chung Rd.
Grafsky per., 14, floor 6 Hsin-Tien, Taipei
Moscu Taiwan
129626 Russia TEL: 886-2-2910-2626
TEL: 7-095-744-0099 FAX: 886-2-2910-1515
FAX: 7-095-744-0099 350 URL: www.dlinktw.com.tw
URL: www.dlink.ru
Oficina Central
2F, No. 233-2, Pao-Chiao Rd.
Hsin-Tien, Taipei
Taiwan
TEL: 886-2-2916-1600
FAX: 886-2-2914-6299
URL: www.dlink.com.tw


Manual DFL-800 Espanol

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Manual DFL-800 Espanol

Diunggah oleh

Hak Cipta:

Format Tersedia

CONTENIDOS

II Vista General del Producto 2

III Introducción de Redes 6

3 Principios del Firewall 9

Guía de Usuario de los Firewalls D-Link

Guía de Usuario de los Firewalls D-Link

11 Fecha & Tiempo 95

13 Ajustes de Registro 103

VI Políticas de Seguridad 108

15 Acceso (Anti-spoofing) 123

Guía de Usuario de los Firewalls D-Link

16 DMZ & Port Forwarding 127

17 Autentificación del Usuario 131

VII Inspeccion de Contenido 146

18 Application Layer Gateway (ALG) 147

19 Sistema de Deteccion de Intrusos (IDS) 181

Guía de Usuario de los Firewalls D-Link

19.1.3 Accion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

VIII Red privada virtual (VPN) 192

20 VPN Básico 193

21 VPN Planificacion 207

22 VPN Protocolos y Tuneles 213

D-Link Firewalls User’s Guide

IX Administración de Tráfico 246

23 Traﬃc Shaping 247

24 Servidor de Balanceo de Carga (SLB) 261

X Características Misceláneas 270

25 Clientes Misceláneo 271

26 Servidor y relay DHCP 275

D-Link Firewalls User’s Guide

XI Modo Transparente 280

27 Modo Transparente 281

XII Zona de Defensa 290

28 Zona de defensa 291

XIII Alta Disponibilidad 298

29 Alta Disponibilidad 299

XIV Apéndice 310

Referencia a Comandos de Consola 313

D-Link Firewalls User’s Guide

Lista de Comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

D-Link Firewalls User’s Guide

B Soporte a clientes 339

D-Link Firewalls User’s Guide

2.1 The OSI 7-Layer Model. . . . . . . . . . . . . . . . . . . . . . . . 8

4.1 WebUI Authentication Window. . . . . . . . . . . . . . . . . . . 20

9.1 A VLAN Infrastructure. . . . . . . . . . . . . . . . . . . . . . . . 57

10.1 Route Failover Scenario . . . . . . . . . . . . . . . . . . . . . . . 78

14.1 Dynamic NAT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

16.1 A Web Server in DMZ . . . . . . . . . . . . . . . . . . . . . . . . 128

18.1 FTP ALG Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . 150

19.1 IDS Chain of Events Scenario 1 . . . . . . . . . . . . . . . . . . 183

19.4 An IDS Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

20.1 VPN Deployment Scenario 1 . . . . . . . . . . . . . . . . . . . . 201

22.1 LAN-to-LAN Example Scenario. . . . . . . . . . . . . . . . . . . 223

23.1 IPv4 Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . 251

24.1 A SLB Logical View. . . . . . . . . . . . . . . . . . . . . . . . . . 262

27.1 Transparent Mode Scenario 1. . . . . . . . . . . . . . . . . . . . 284

28.1 A Zone Defense Scenario. . . . . . . . . . . . . . . . . . . . . . . 295

29.1 Example HA Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . 301

D-Link Firewalls User’s Guide

Sección 10.4: Configuración Route Failover. . . . . . . . . . . . 78

Sección 10.5: Configuración Dynamic Routing. . . . . . . . . . . . 82

Sección 10.6: Configuración Static Routing. . . . . . . . . . . . . . 87