Listas de acceso 

 
Introducción 
 
Las listas de acceso, también llamadas listas de control de acceso (ACL, Access Control Lists), constituyen los mecanismos 
principales de filtrado de paquete en la mayor parte de los enrutadores de Cisco. Asimismo, las ACL se utilizan para 
otra  serie  de  funciones,  incluyendo  el  filtrado  de  ruta  y  la  utilización  de  determinados  comandos  show.  Por  ello, 
resulta  necesario  tener  un  sólido  conocimiento  sobre  las  ACL  para  poder  resolver  cualquier  clase  de  problemas  y 
configurar  los  equipos  de  Cisco  en  la  mayoría  de  las  redes.  Las  ACL  permiten  controlar  qué  clase  de  coincidencia 
efectúa un enrutador en relación con una determinada función, como el envío de paquetes. 
 
Por ejemplo, si no existe una forma de especificar de forma condicional qué paquetes pueden enviarse de una 
red a otra (como es el caso de Internet), el usuario tendrá que autorizar el envío de todos los paquetes (lo cual hace 
que  la  red  en  cuestión  sea  un  objetivo  sencillo  para  los  hockers),  o  bien  denegar  todos  los  paquetes  (lo  que  haría 
imposible la conectividad). El control general a través del filtrado de paquete constituye una función primaria de las 
ACL. Sin  embargo, las  ACL  se pueden utilizar  con comandos más complejos (como los mapas de ruta o las listas de 
distribución),  lo  que  proporciona  un  grado  de  control  muy  preciso  sobre  la  funcionalidad  del  enrutador.  En 
resumidas  cuentas,  siempre  que  sea  preciso  utilizar  alguna  clase  de  coincidencia  condicional,  las  ACL  suelen  ser  la 
herramienta a elegir. 

En  el  presente  escrito  se  analizarán  las  características  de  las  ACL,  explicando  fundamentalmente  su  propósito 
principal: el filtrado de paquetes. Aunque todos los conceptos que se estudian aquí también se aplican al resto de los 
comandos que utilizan las ACL, en el presente escrito no se considerarán las características de dichos comandos (en 
este  sentido,  si  el  lector  desea  consultar  ejemplos  de  listas  de  distribución  ACL  en  protocolos  de  enrutamiento,  se 
recomienda consultar los capítulos que van del 22 al 26 del Manual de referencia de CISCO). Por otra parte, como 
para  comprender  el  funcionamiento  de  las  ACL  es  preciso  conocer  todas  las  cuestiones  relacionadas  con  su 
configuración, a lo largo del presente escrito se examinan la resolución de problemas y la configuración de las ACL en 
lugar de analizarlas en apartados distintos. Finalmente, como TCP/IP constituye el tema fundamental del presente 
libro, el filtrado de paquete IPX no se analiza aquí. 

Comprender el filtrado de paquetes 

Los  objetivos  básicos  del  filtrado  de  paquete  resultan  muy  sencillos.  Supongamos  que  se  desea  que  una  red 
remota (generalmente,  una  red  pública como  Internet)  acceda  exclusivamente  a recursos  específicos  situados  en 
una  red  privada,  al  tiempo  que  se  autoriza  el  acceso  de  la  red  privada  a  la  red  remota.  Parece  simple,  ¿verdad? 
Desafortunadamente,  es  más  fácil  decirlo  que  hacerlo.  Para  ver  por  qué,  conviene  observar  la  situación  que  se 
ilustra en la ilustración No. 1, donde se pretende efectuar un filtrado de paquete. 

Ilustración 1: Red simple no segura 

 
 La  red que  se ilustra  en la figura  no  está  utilizando la  traducción  de  direcciones de red (NAT, Network Address 
Trasslation),  sino  que  simplemente  gestiona  direcciones  IP  públicas  para  las  dos  estaciones  de  trabajo, 
proporcionándoles acceso a Internet. El problema que presenta este esquema es que, sin filtrado de paquete, cada 
servidor de la red privada puede comunicarse con Internet libremente, y viceversa. Suponiendo que la información 
bancada  online  del  usuario  está  colocada  en  una  unidad  compartida  situada  en  el  servidor  64.1.1.69,  la  única 
protección que recibe el servidor ante la aparición de intrusos es el sistema de seguridad del sistema operativo, que 
habitualmente resulta altamente sospechoso. 

Antes de aprender a resolver este problema conviene examinar el significado de algunos de los nuevos términos 
asociados con la NAT y el filtrado de paquete. La red interna es la red que se desea proteger de un acceso realizado 
desde el exterior. La red externa es la red remota. La interfaz interna es la interfaz de enrutador vinculada a la red 
interna.  La  interfaz  externa  es  la  interfaz  vinculada  a  la  red  externa.  Finalmente,  cuando  se  trabaja  con  filtros  es 
preciso comprender el concepto de dirección (o sentido del flujo): el tipo de tráfico, entrante o saliente, al que se 
aplica el filtro. 

Si la dirección es entrante, el filtro se aplica al tráfico introduciendo la interfaz desde la red vinculada. En el caso 
de  una  interfaz  interna,  el  tráfico  entrante  no  es  otra  cosa  que  el  tráfico  que  introduce  la  interfaz  desde  la  red 
interna. Si este tráfico se enrula hacia la red externa, tendría que considerarse tráfico saliente en la interfaz externa. 
Si la dirección es saliente, el filtro se aplica al tráfico que abandona la interfaz en la red vinculada. En el caso de 
una interfaz interna se trata de tráfico enviado desde la interfaz interna a la red interna. Si este tráfico se enrula 
desde la red externa, también se debe considerar tráfico entrante en la interfaz externa. 

A continuación se resolverán las cuestiones suscitadas en el ejemplo anterior. Para solucionar el problema del 
acceso libre a los recursos internos se puede utilizar el filtrado de paquete en el enrutador para denegar el acceso a 
la  red  interna  desde  Internet.  Por  ejemplo,  es  posible  eliminar  todo  el  acceso  a  la  red  interna  desde  Internet,  de 
forma que se puede optar por utilizar un filtrado de paquete que rechace todos los paquetes destinados a la red 
interna.  Para  ello  habría  que  utilizar  un  filtro  de  paquete  que  ejecutara  la  función  «denegar  todo»o  «denegar 
paquetes con una dirección de destino de 64.1.1.64 a 71». Posteriormente, habría que aplicar el filtrado de paquete 
a  los  paquetes  entrantes  en  la  interfaz  externa  (64.1.1.2/24)  o  a  los  paquetes  salientes  en  la  interfaz  interna 
(64.1.1.6.5/29). 

Parece  que  el  problema  se  ha  resuelto...  Desafortunadamente,  aún  no  es  así.  Este  filtro  de  paquete  no  sólo 
rechazaría  el  acceso  no  autorizado  (correctamente)  desde  el  mundo  exterior,  sino  que  también  denegaría  los 
paquetes  de  retorno  procedentes  de  los  anfitriones  internos  a  Internet.  En  otras  palabras,  cuando  se  envía  un 
paquete a wivw.cwco.com desde el servidor 64.1.1.69, los paquetes de establecimiento de conexión TCP deberían 
abandonar  la  red  privada  libremente  dirigiéndose  a  Internet,  pero  cuando  el  servidor  web  situado  en  Cisco 
responda, ¡el filtro debería descartar los paquetes! Obviamente, no se trata de una solución adecuada, así que hay 
que volver a la mesa de trabajo. 

Una posible solución a este problema consiste en autorizar la existencia de paquetes que utilicen números de 
puerto  de  cliente  para  entrar  en  la  red  privada.  Habitualmente,  los  clientes  utilizarían  puertos  considerados 
exclusivamente como «dinámicos y privados» por la IANA, que incluye todos los puertos situados entre 49.192 y 
65.535.  Sin  embargo,  muchos  clientes  también  utilizarían  puertos  comprendidos  en  un  rango  que  va  de  1.024  a 
49.191  (definidos  por  la  IANA  como  «registrados»).  Esto  conduce  a  una  serie  de  problemas  a  la  hora  de  filtrar 
paquetes,  ya  que  si  simplemente  se  rechaza  cada  paquete  que  tiene  un  número  de  puerto  inferior  a  49.192,  se 
acabaría por denegar el tráfico de retorno legítimo tanto a los clientes como al tráfico de carácter sospechoso. 

Así que ¿por qué no autorizar que todo el tráfico utilice un puerto de destino situado por encima de 1023? La 
respuesta es sencilla: porque varias aplicaciones de servidor de uso común, muchas de las cuales no deberían resultar 
accesibles desde servidores externos, utilizan puertos situados en ese rango (como es el caso del servidor de catálogo 
global de Microsoft en el Directorio Activo situado en los puertos 3268/3269 y el servidor SNA de Microsoft situado 
en 1477 y 1478). 

Nota:  

Si se desea obtener un listado completo de los números de puerto registrados y conocidos, hay que 
visitar la dirección http://www.iana.org/ assignments/port‐numbers.htm. 

La solución más fácil para este pequeño problema consiste en admitir exclusivamente el tráfico de 
conexiones  establecidas.  Mediante  esta  acción  cabe  indicar  al  enrutador  que  admita  la  llegada  de 
paquetes  de  retorno  procedentes  de  cualquier  servidor  externo,  posibilitando  su  entrada  en  la  red 
privada.  De  esta  manera,  mientras  la  sesión  TCP  con  el  servidor  remoto  siga  en  activo,  el  enrutador 
autorizará que los paquetes entren en la red privada. 

El filtrado de paquete establecido funciona de la manera siguiente: 
 1. Se configura un filtro establecido en la interfaz externa para los paquetes entrantes que afirme 
básicamente: «Admitir todas las conexiones establecidas». 

2.        Se  envía un  paquete  a un  servidor  remoto.  Puesto que  el  filtro  de  paquete  está  configurado 
para  comprobar  los  paquetes  entrantes  exclusivamente  en  la  interfaz  externa,  todos  los  paquetes 
procedentes de la red interna que van a Internet quedan autorizados automáticamente. 

3.    El servidor remoto responde. Éste debe tener los bits ACK o RST configurados en el paquete de 
respuesta. El filtro establecido autoriza todos los paquetes procedentes de la red externa con estos bits 
configurados en posición de entrada. 

Obviamente, la funcionalidad descrita en el paso 3 deja un pequeño agujero en lo que respecta a la 
seguridad de la red. Por ejemplo, un hacker avispado podría configurar manualmente el bit ACK en un 
paquete TCP e introducir la red interna. Por esta razón, los mecanismos de Cisco también admiten un 
tipo especial de filtro de paquete, conocido como ACL reflexiva. Una ACL reflexiva crea dinámicamente 
entradas de filtro de paquete para así poder autorizar el acceso hacia y desde el servidor, así como el 
destino para el que se ha establecido la sesión. Las ACL reflexivas funcionan de la manera siguiente: 

1.  Se  configura  el  filtro  reflexivo  en  la  interfaz  externa  para  los  paquetes  entrantes,  que  afirme: 
«Autorizar todas las conexiones establecidas».  

2.  Se  envía  un  paquete  al  servidor  remoto  usando  una  IP  de  origen  específica  (por  ejemplo, 
64.1.1.69), un puerto de origen específico (por ejemplo, 50.000), un destino IP específico (como podría 
ser 71.100.1.1) y un puerto de destino específico (por ejemplo, 80 para HTTP). La ACL reflexiva cons‐
truye un filtro de paquete dinámico para autorizar todas las respuestas clonadas desde la red externa 
para entrar en la red interna hasta que haya caducado el tiempo límite o hasta que el bit FIN aparezca 
en la sesión. En ' este caso, la ACL reflexiva crearía una entrada que diría lo siguiente: «Autorizar todos 
los  paquetes  procedentes  de  la  dirección  de  origen  71.100.1.1  con  un  puerto  de  origen  de  80  y  un 
destino de 64.1.1.69, con un puerto de destino de 50.000 para entrar en la red interna». 

3.    El servidor remoto responde y se envía el paquete. 

4.    Cuando termina la sesión (aparece el bit FIN o caduca el tiempo límite), se elimina el filtro de 
paquete dinámico. 

Nota 

En  muchos  servidores  proxy/NAT,  incluyendo  el  servidor  ISA  de  Microsoft,  las  conexiones 
establecidas  y  las  conexiones  reflejadas  se  autorizan  automáticamente,  mientras  que  el  resto  de  los 
paquetes se rechazan como efecto secundario de la creación de la tabla NAT/PAT. Aunque no se trata 
técnicamente de un filtrado de paquete, su funcionamiento es el mismo. 

El  filtrado  reflexivo  simplifica  las  cosas,  facilitando  la  autorización  eficaz  del  tráfico  interno  para 
acceder a la red externa. Sin embargo, esta clase de filtrado tiene dos características que hay que tener 
en cuenta: 

• El filtrado reflexivo no funciona con todas las aplicaciones. Específicamente, aquellas aplicaciones 
que  cambian  los  números  de  puerto  en  el  transcurso  de  la  sesión  (por  ejemplo,  FTP  y  RPC)  deben 
autorizarse estáticamente. 

•  Asimismo,  se  pueden  utilizar  filtros  reflexivos  para  autorizar  sólo  aquellos  tipos  específicos  de 
tráfico que vayan a emplearse para acceder a la red externa desde la red interna. 

A  continuación  se  examinará  el  primer  punto.  Ciertas  aplicaciones  cambian  dinámicamente  los 
puertos  en  el  transcurso  de  una  sesión.  Dichas  aplicaciones  deben  autorizarse  para  transmitir 
elementos  (si  se  requiere)  de  forma  estática.  Por  ejemplo,  FTP  utiliza  dos  puertos,  20  y  21,  en  el 
transcurso de las comunicaciones. Cuando se establece una conexión FTP se utiliza el puerto 21 para 
transferir el control de sesión de estilo Telnet. Sin embargo, cuando se comienza a descargar un archi‐
vo se utiliza el puerto 20 para la transferencia. Las ACL reflexivas no conocen el puerto de transferencia 
de  archivo.  Lo  único  que  conocen  es  el  puerto  utilizado  inicialmente,  por  tanto  la  ACL  bloquearía  la 
transferencia FTP. La llamada de procedimiento remoto (RPC, Remote Procedure Cali], utilizada por la 
mayor parte de las aplicaciones de servidor de Microsoft, funciona de manera similar, pero añade un 
elemento de complejidad adicional. Tras la conexión inicial, RPC escoge un puerto al azar en 1024 para 
establecer una comunicación. 

Para resolver las cuestiones relacionadas con estos tipos de aplicaciones existen dos posibilidades: 
 •  Cambiar  a  una  solución  de  cortafuegos  más  sólida  que  comprenda  los  detalles  de  nivel  de 
aplicación (eficaz, pero quizás muy cara). 

• Catalogar esta clase de aplicaciones, el puerto utilizado y los puertos abiertos. 

Nota: 

Algunas soluciones proxy/cortafuegos ya incluyen la mayoría de los filtros de nivel de aplicación que 
puedan resultar necesarios. El soporte FTP, por ejemplo, está disponible por omisión en la mayoría de 
los productos comerciales. 

Puesto  que  la  primera  solución  escapa  al  marco  planteado  en  el  presente  libro,  se  analizará  la 
segunda.  La  forma  más  sencilla  de  implementarla  consiste  en  activar  ACL  reflexivas  y  luego  verificar 
qué aplicaciones no funcionan. Con el tiempo, el usuario sabrá qué aplicaciones podrá considerar como 
ACL estáticas para adaptarse prácticamente a todas las situaciones (como FTP), pero, inicialmente, se 
explicará  la  forma  más  rápida  de  comenzar.  Una  vez  que  se  haya  determinado  cuáles  son  las 
aplicaciones que no tienen soporte de las ACL reflexivas, se pueden rastrear los puertos utilizados por 
esta aplicación y configurar las ACL para transmitir este tráfico específico. Por ejemplo, para que todos 
los clientes puedan utilizar FTP habría que configurar una ACL estática que dijera lo siguiente: «Autori‐
zar todo el tráfico con un puerto de origen de 20 y una dirección de destino equivalente a todas las 
direcciones presentes en la red interna». 

En  el  caso  de  las  aplicaciones  que  elijan  puertos  aleatorios,  como  es  el  caso  de  RPC,  la  solución 
resulta  algo  más  compleja.  Si  la  aplicación  sólo  utiliza  un  pequeño  rango  de  puertos,  simplemente 
habrá que abrir los puertos en dicho rango. Sin embargo, si la aplicación utiliza un extenso rango de 
puertos  (como  RPC)  el  trabajo  se  complica.  El  primer  paso  consiste  en  obligar  a  la  aplicación  a  que 
utilice un rango de puertos más pequeño. Así, por ejemplo, en el caso de RPC, se puede modificar el 
registro  de  Windows  en  los  anfitriones  (normalmente,  servidores)  que  requieran  conectividad  RPC  a 
través del cortafuegos. Una vez definido un rango pequeño de puertos aleatorios, para utilizarlos basta 
con  añadir  una  sentencia  de  ACL  estática  que  permita  que  dichos  puertos  se  comuniquen  con  estos 
puertos específicos. 

Por ejemplo, si hay cinco servidores en el rango de direcciones IP 70.1.1.5 a 70.1.1.9 que necesiten 
comunicarse utilizando RBC con otro servidor en la dirección IP 140.0.0.1, en primer lugar habría que 
obligar a que, en todos los servidores, RPC utilizara puertos dentro de un rango dado, como puede ser 
el  comprendido  entre  50.000  y  60.000.  Luego  habría  que  añadir  una  sentencia  ACL  en  la  interfaz 
externa del cortafuegos para la red 70.1.1.0 que dijera lo siguiente: «Autorizar paquetes entrantes con 
una dirección de origen de 140.0.0.1 que use cualquier número de puerto con una dirección de destino 
en  el  rango  comprendido  entre  70.1.1.5  y  70.1.1.9,  y  con  un  puerto  de  destino  en  el  rango  situado 
entre 50.000 y 60.000». En el cortafuegos correspondiente a la red 140.0.0.0 simplemente habría que 
reflejar esta sentencia. 

CONSEJO 

Si  se  desea  consultar  información  detallada  sobre  cómo  obligar  a  RPC  para  que  utilice  un  rango 
específico de puertos en las plataformas de servidor de Microsoft en uso hay que consultar el artículo 
Q154596: http://support. microsoft.com/def a u lt.aspx?scid=kb;EN‐US;q154596. 

Sin  embargo,  en  el  caso  del  filtrado  de  paquetes  se  puede  actuar  de  una  forma  más  compleja  y 
elegir la posibilidad de autorizar exclusivamente ciertos tipos de tráfico desde los anfitriones internos 
para  permitir  que  salgan  a  la  red  externa.  Por  ejemplo,  suponiendo  que  sólo  se  desea  proporcionar 
acceso a Internet para navegación web, pero no se quiere que los usuarios empleen otras aplicaciones 
estándar de Internet, como FTP, Telnet y SMTP, o bien si no se desea que los clientes internos tengan 
la  capacidad  de  utilizar  aplicaciones  no  admitidas  (y  que  en  ocasiones consumen  un  gran  ancho  de 
banda) como es el caso de Quake o Napster, habría que crear una ACL reflexiva que diga lo siguiente: 
«Autorizar que los anfitriones internos accedan a todos los anfitriones externos utilizando el puerto 80 
(HTTP) y 443 (HTTPS/SSL)». Posteriormente habría que aplicar la ACL a la interfaz de enrutador interna 
para el tráfico entrante. 

Consejo 

Por regla general, hay que intentar aplicar el filtrado de paquete tan cerca del borde de la red como 
sea posible. Asimismo, hay que intentar filtrar el tráfico cuando se entra en una interfaz (dirección de 
entrada)  en  lugar  de  hacerlo  cuando  se  sale  de  ella  (dirección  de  salida).  Esta  estrategia  ayuda  a 
conservar  los  recursos  del  enrutador,  eliminando  la  necesidad  de  que  éste  efectúe  un  proceso  en  el 
paquete antes de arrojarlo al «cubo de bits». 
  

Uso de la NAT y la PAT con filtrado de paquetes 

La traducción de direcciones de red (NAT, Netwvork Address Translation) puede simplificar la vida del 
programador evitando que tenga que concentrarse en la cuestión del acceso no autorizado a anfitriones 
situados  en  la  red  privada.  Por  definición,  la  NAT  y  la  traducción  de  direcciones  de  puerto  (PAT,  Pon 
Address Translation) generan tablas de traducción dinámicamente (aunque también cabe la posibilidad 
de definir entradas estáticas) para autorizar anfitriones procedentes del mundo externo de modo que 
entren en la red interna. Asimismo, estas entradas dinámicas se crean sólo cuando un anfitrión interno 
necesita acceder al mundo externo. Si un anfitrión externo desea comunicarse con un anfitrión interno y 
el mecanismo NAT no dispone de una entrada en la tabla de traducción para el anfitrión de destino, el 
paquete se rechaza. Por consiguiente, como si se tratara de un subproducto NAT, los recursos internos 
ya tienen un nivel de seguridad similar al de una ACL reflexiva. 

Nota: 

   Si  desea  conocer  las  características  de  la  NAT  puede  consultar  el  Captulo  6  de  CISCO,  Manual  de 
referencia‐ 

Si en la red interna existen anfitriones que deben resultar accesibles desde anfitriones situados en la red 
externa, como puede ser el caso de un servidor web, basta con agregar una entrada estática en la NAT 
similar  a  la  entrada  que  habitualmente  se  colocaría  en  un  filtro  de  paquete  estándar,  exceptuando  el 
hecho de que hay que especificar la dirección externa y el puerto asociado con el servidor web, así como 
la  dirección  interna  y  el  puerto  asociado  con  dicho  servidor.  Por  ejemplo,  en  la  ilustración  No.  2  se 
muestra la red que aparecía en la Ilustración No. 1 con la incorporación del direccionamiento privado 
destinado a la red interna (el enrutador está ejecutando la NAT) y un servidor web en la red interna. En 
este caso habría que estipular que todo el tráfico externo estuviera autorizado para acceder al servidor 
web, pero sólo en lo que respecta a HTTP (no se debe autorizar el acceso al servidor web utilizando cual‐
quier otro protocolo). Asimismo, habría que permitir que los clientes internos accedieran a los recursos 
externos, pero sólo en lo que respecta a FTP, HTTP, HTTPS, POP3 y SMTP. El resto de las comunicaciones 
quedarían denegadas. 

 
Ilustración 2: Ejemplo de red con inclusión NAT y un servidor web 
 

A  continuación  se  incluye  un  listado  de  los  filtros  de  interfaz  interna correspondientes  a  la  ilustración 
No. 2 (en la localización marcada con un 1): 

1. Filtros de interfaz interna correspondientes a la ilustración No 2 

 
Para  albergar  estos  requerimientos  hay  que  crear  una  sentencia  NAT  que  autorice  que  todas  las 
direcciones  públicas  se  usen  para  una  traducción  dinámica.  Luego  habría  que  agregar  una  traducción 
estática  (conocida  como  correspondencia  estática)  que  asociara  a  64.1.1.2,  puerto  80,  con 
192.168.1.100, puerto 80. Debido a la naturaleza de la NAT, estas dos acciones rechazan que el tráfico 
entre en la red interna desde un anfitrión remoto que no se inicie mediante un anfitrión interno o que 
esté destinado al HTTP en el servidor web. 
A  continuación,  para  evitar  que  los  anfitriones  internos  utilicen  protocolos  distintos  de  FTP  (20,  21), 
HTTP (80), HTTPS (443), POP3 (110) y SMTP (25) basta con aplicar un filtro de paquete al tráfico entrante 
en la interfaz interna que señale lo siguiente: 
• Autorizar el tráfico desde cualquier anfitrión interno utilizando cualquier puerto de origen 
destinado a cualquier anfitrión externo, utilizando los puertos de destino 20, 21. 80, 443, 110 O 
o 25. 
• Autorizar el tráfico desde 192.168.1.100 utilizando el puerto de origen 80 para cualquier 
dirección de destino y puerto. 
• Rechazar el tráfico restante. 
Como  es  lógico,  una  vez  efectuados  todos  estos  pasos  para  proteger  la  red,  probablemente  el  lector 
puede darse cuenta de que sigue existiendo un elemento vulnerable: el propio cortafuegos. Si un hacker 
tuviera  la  intención  de  comprometer  el  cortafuegos,  el  resto  de  las  configuraciones  de  seguridad 
también quedarían comprometidas. Para tratar de evitar este desastre potencial es preciso desactivar 
todos los servicios necesarios en el enrutador, efectuando un filtrado de paquete/ NAT. En una situación 
de  cortafuegos  individual  o  único,  si  el  cortafuegos  está  efectuando  una  PAT,  es  preciso  ser 
particularmente cuidadoso en lo que respecta al filtrado de paquete en la interfaz externa. Por omisión, 
en  un  enrutador  de  Cisco,  la  PAT  (también  conocida  como  sobrecarga  NAT)  intenta  asignar  el  mismo 
número de puerto a los paquetes traducidos. En otras palabras, si un anfitrión interno está intentando 
comunicarse con un anfitrión externo utilizando un puerto de origen de 12.000, la NAT intenta utilizar el 
mismo puerto para la dirección traducida. 
 
Sin  embargo,  como  es  posible  que  el  puerto  de  origen  se  haya  elegido  anteriormente  (otro  anfitrión 
interno puede estar utilizando 12.000 como puerto de origen), es posible que la NAT tenga que asignar 
un  número  de  puerto  diferente.  Cuando  la  NAT  tiene  que  cambiar  el  puerto  de  una  sesión,  asigna 
aleatoriamente  un  puerto  no  utilizado  a  la  comunicación  desde  uno  de  los  tres  rangos  de  puerto 
siguientes: 1‐511, 512‐1023 y 1024‐65535. La NAT siempre asigna un puerto al paquete traducido, que 
estará en el mismo rango que el puerto de pretraducción. 
Por ejemplo, si el cliente utilizó originalmente el puerto 443, la NAT elegiría un puerto situado entre 1 y 
511 para la traducción de paquetes, dando por supuesto que ya se ha utilizado el puerto 443. Puesto 
que  el  puerto  que  la  NAT  elige  para  una  conexión  de  cliente  particular  no  se  puede  predecir,  la 
posibilidad de realizar un filtrado de paquete en la interfaz externa resulta limitada. Por esta razón, es 
preciso  considerar  cuidadosamente  el  filtrado  de  paquete  correspondiente  a  la  ¡nterfaz  externa  del 
enrutador antes de implementar la NAT. 
 
Nota: 
La configuración de la NAT en un enrutador de Cisco escapa al marco propuesto por el presente libro. 
Para  obtener  más  información  al  respecto  hay  que  visitar  las  páginas 
http://www.cisco.com/warp/pubí¡c/cc/  pd/iosw/ioft/ionetn/prodlit/1195_pp.htm  y 
http://www.cisco.com/warp/ public/cc/pd/¡osw/ioft/iofwft/prodlit/¡osnt_qp.htm. 
 

Comprender la DMZ 

Una  zona  desmilitarizada  (DMZ,  Demilitarized  Zone)  (también  conocida  como  subred  protegida  o 
«apantallada»)  constituye  una  medida  de  seguridad  adicional  para  garantizar  que  la  disponibilidad  de 
recursos de acceso público no comprometa la seguridad de la red interna. Una DMZ separa los recursos 
de  acceso  público  de  los  recursos  completamente  privados,  colocándolos  en  subredes  distintas,  auto‐
rizando el bloqueo de los recursos privados e incluso proporcionando seguridad a los recursos públicos. 

Nota: 

    Aunque  esto  se  puede  considerar  una  blasfemia  en  algunos  círculos  de 
seguridad  en  redes,  en  el  presente  escrito  se  usa  el  término  cortafuegos  para  representar  cualquier 
mecanismo  que  filtre  paquetes  para  el  control  del  acceso,  incluyendo  tanto  enrutadores  de  Cisco 
estándar  como  los  productos  cortafuegos  específicos,  como  los  de  las  series  PIX,  a 
menos que se indique expresamente otra cosa. 

Las  DMZ  se  pueden  estructurar  de  diversas  formas,  pero  en  este  escrito  sólo  se  analizarán  las 
configuraciones más frecuentes: 

• DMZ con cortafuegos individual. Este tipo de DMZ consta de un cortafuegos individual con tres o más 
interfaces,  y  al  menos  una  de  las  interfaces  conectadas  a  la  red  interna,  a  la  red  externa  y  a  la  DMZ. 
Estas DMZ son más eficaces en términos de coste, pero los beneficios de seguridad (más allá de un único 
cortafuegos que no tenga DMZ) resultan mínimos. 

• DMZ con cortafuegos dual. Esta clase de DMZ es una de las más comunes y consiste en un cortafuegos 
externo,  un  cortafuegos  interno  y  una  DMZ  situada  entre  ambos.  Los  recursos  internos  quedan 
protegidos  por  el  cortafuegos  interno,  mientras  que  los  recursos  de  la  DMZ  están  protegidos  por  el 
cortafuegos externo. Este tipo de estructura DMZ puede incrementar la seguridad sustancialmente: el 
cortafuegos  dual  proporciona  una  protección  suplementaria  a  los  recursos  internos.  Sin  embargo,  el 
problema surge cuando se considera que la DMZ con cortafuegos dual tiende a ser mucho más cara que 
una  con  cortafuegos  individual,  y,  al  mismo  tiempo,  su  manejo  puede  requerir  conocimientos 
adicionales (especialmente, si se siguen las recomendaciones que los distintos fabricantes realizan sobre 
los cortafuegos). 

• DMZ con cortafuegos triple. Se trata de una estructura que utiliza tres cortafuegos para proteger la 
red  interna  y  que,  al  mismo  tiempo,  utiliza  DMZ  interna  y  externa.  Esta  configuración  de  cortafuegos 
sólo  se  usa  en  instituciones  en  las  que  la  seguridad  es  un  elemento  muy  importante  y  suele  implicar 
toda  una  serie  de  aplicaciones  subsidiarias.  Aunque  resultan  extremadamente  seguros,  estos 
cortafuegos  son  extremadamente  caros  tanto  en  lo  que  respecta  a  su  implementación  como  a  su 
mantenimiento. 

En primer lugar se examinará la solución del cortafuegos individual. La ilustración. 3 muestra un único 
cortafuegos con tres interfaces. Los servidores web y otros servidores de acceso público están situados 
en la DMZ, mientras que todos los recursos internos están totalmente protegidos en la subred interna. 
Asimismo  hay  que  observar  que  el  servidor  SQL  utilizado  por  el  servidor  web  para  generar  eí 
procesamiento está situado en la red interna. 

 
Ilustración 3: Sistema de cortafuegos individual DMZ 

A  continuación  se  incluye  un  listado  de  los  filtros  de  interfaz  correspondientes  a  las  localizaciones 
numeradas en la ilustración. 3. 

1. Filtros de interfaz internos correspondientes a la ilustración. 3. 
  
2. Filtros DMZ correspondientes a la ilustración. 3. 

3. Filtros de interfaz externa correspondientes a la ilustración. 3. 

Nota: 

Hay que tener en cuenta que la mayoría de los fabricantes de cortafuegos, incluyendo Cisco, utilizan la 
regla  de  la  «primera  coincidencia».  Todos  los  filtros  correspondientes  a  una  determinada  dirección  en 
una interfaz dada se examinan en orden y se utiliza el primer filtro coincidente. 

A  continuación  se  analizarán  las  características  de  los  filtros  de  paquete,  empezando  por  el  filtro 
externo. El primer filtro situado en la interfaz externa permite que cualquier anfitrión alcance cualquier 
servidor público en la DMZ utilizando cualquiera de los puertos correspondientes a los servicios que se 
suministran  en  dichos  servidores.  En  otras  palabras,  si  en  la  DMZ  se  dispone  de  un  servidor  web,  un 
servidor FTP o un servidor SMTP, se tendría acceso al servidor web utilizando el puerto 80 o el 443, al 
tiempo  que  se  tiene  acceso  al  puerto  FTP  utilizando  los  puertos  20  y  21,  y  acceso  al  servidor  SMTP 
utilizando el puerto 25. 
El  segundo  filtro  en  la  interfaz  externa  es  un  filtro  reflexivo  que  facilita  la  comunicación  inicialmente 
establecida mediante los anfitriones internos para retornar a dichos anfitriones. El filtro final presente 
en la interfaz externa rechaza el resto de las comunicaciones (en las ACL de Cisco no es necesario, ya 
que siempre hay una denegación implícita al final). No se aplican filtros hacia el exterior de la interfaz 
externa, por lo que se autoriza todo el tráfico en dicho sentido. 

Asimismo, conviene observar el orden de los filtros orientados hacia dentro. El primer y segundo filtro 
admiten  conexiones  específicas,  mientras  que  el  tercero  deniega  todas  las  conexiones.  Puesto  que  el 
filtro que efectúa la denegación está situado al final, se convierte desde un punto de vista funcional en 
un  elemento  que  deniega  al  resto.  Si  los  paquetes  coincidieran  con  el  primer  filtro  (destinados  a  un 
servidor público situado en un puerto público), serían autorizados y finalizaría el procesamiento de filtro 
correspondiente  a  esta  interfaz.  En  caso  contrario,  se  examinaría  el  filtro  siguiente.  Si  el  paquete 
coincide  con  el  segundo  filtro  (si  fuera  un  paquete  de  respuesta  para  una  sesión  previamente 
establecida mediante un anfitrión interno o basado en DMZ) también quedaría autorizado y finalizaría el 
procesamiento  de  filtro correspondiente  a esta  interfaz. Si  el  paquete no  coincidiera  con  ningún  filtro 
sería denegado. Nuevamente, hay que recordar que los filtros se procesan en orden, y una vez que se 
logra una coincidencia, finaliza el procesamiento de filtro correspondiente a esa interfaz. 

En el caso de las DMZ, los dos primeros filtros, orientados hacia dentro, autorizan al servidor web (y sólo 
al  servidor  web) presente  en  la  DMZ para que  se  comunique con  el  servidor  SQL  asegurado en  la  red 
interna,  utilizando  exclusivamente  el  protocolo  SQL.  La  estipulación  de  que  SQL  debe  ser  el  único 
protocolo  utilizado  garantiza  que,  en  caso de  que  los  hackers  ataquen  a  otros  servidores  públicos, no 
puedan  tener  acceso  a  la  base  de  datos  segura  situada  en  el  servidor  SQL.  El  tercer  filtro,  orientado 
hacia  fuera,  es  un  filtro  reflexivo  que  autoriza  todas  las  comunicaciones  que  se  establecen  desde 
anfitrión DMZ. El tercer filtro es necesario debido a la presencia del cuarto filtro orientado hacia fuera, 
que deniega el resto de paquetes. Utilizando esta técnica de filtrado cabe garantizar que el servidor SQL 
seguro no sólo se aborde desde anfitriones externos, sino también desde servidores situados en la DMZ. 

Finalmente, en el caso de la red interna, los dos filtros orientados hacia dentro permiten que el servidor 
SQL se comunique exclusivamente con el servidor web en la DMZ utilizando el protocolo SQL. Este filtro, 
aunque  no  se  requiera  estrictamente,  garantiza  la  seguridad  del  servidor  SQL  asegurándose  de  que 
dicho servidor no pueda comunicarse con un anfitrión externo distinto del servidor web y luego utilice 
exclusivamente  SQL  como  aplicación.  Si  el  usuario  no  ha  generado  esta  sentencia,  un  administrador 
situado físicamente junto al servidor SQL podría abrir una sesión a un sitio web utilizando dicho servidor. 

Nota: 

Si el servidor web estuviera comunicándose realmente con el servidor SQL interno, empleando SQL como 
protocolo, y el servidor SQL fuera un servidor SQL de Microsoft, el puerto que habría que abrir sería el 
1433.  Sin  embargo,  como  puede  utilizarse  como  extremo  para  el  servidor  SQL  cualquier  otro  tipo  de 
aplicación u otra versión comercial de SQL (como es el caso de la versión de Oracle), en este ejemplo no 
se ha incluido el número de puerto en bruto. Cuando se utilice esta técnica hay que saber cuáles son los 
puertos que pueden abrirse. 

Aunque los administradores que naveguen por la web desde un servidor realmente no tienen mucho de 
qué preocuparse, existe la remota posibilidad de que la sesión a un sitio web pudiera verse secuestrada 
por un hacker y, puesto que la sesión se estableció previamente mediante el servidor SQL, los paquetes 
que  enviara  el  hacker  al  servidor  SQL  podrían  tener  autorización  para  franquear  el  cortafuegos.  Para 
eliminar esta posibilidad se pueden crear dos filtros para desactivar todas las comunicaciones SQL que 
se  produzcan  fuera  de  la  red  interna,  exceptuando  los  paquetes  necesarios  para  que  el  servidor  web 
utilice los puertos SQL. 
Consejo: 

Cabe  aplicar  esta  misma  filosofía  y  técnica  de  filtrado  a  prácticamente  todos  los  servidores  internos, 
eliminando la posibilidad de acceso no autorizado. Por ejemplo, se puede aplicar un filtro adicional antes 
del tercer filtro para denegar el bloque de dirección asignado a los servidores internos desde el uso de 
recursos  externos.  Sin  embargo,  hay  que  tener  en  cuenta  que esta  técnica  de  filtrado  requiere  que  los 
administradores  del  servidor  utilicen  estaciones  de  trabajo  estándar  para  transferir  actualizaciones  y 
cualquier otro archivo de servidor necesario desde Internet, y que luego compartan las unidades de disco 
de  las  estaciones  de  trabajo  !o  utilicen  redes  secretas)  para  transferir  los  archivos  a  los  servidores, 
provocando  un  esfuerzo  administrativo  adicional  (lo  cual  no  resulta  necesario  en  un  principio,  aunque 
depende de la política de seguridad). 

Los cinco filtros siguientes colocados en la interfaz interna se usan para controlar el acceso a Internet 
desde los anfitriones internos. Estos cinco filtros permiten que cualquier anfitrión situado en la subred 
interna acceda a Internet utilizando los puertos 80 (HTTP), 443 (HTTPS/SSL), 20 o 21 (FTP) y 25 (SMTP), 
al tiempo que deniega cualquier otro acceso. Aunque el bloque de dirección IP que aparece reflejado en 
los  filtros  (192.168.1.X)  no  es  estrictamente  necesario  (ya  que  se  podría  utilizar  la  sentencia  any 
[cualquiera]  para  una  subred  individual),  se  incluye  aquí  para  mostrar  cómo  utilizar  la  dirección  de 
origen para permitir que los usuarios de una subred accedan a Internet mientras se deniega el acceso a 
Internet  a  otros  usuarios  situados  en  una  subred  diferente.  Si  otra  subred  (por  ejemplo,  192.168.2.0) 
tuviera estos filtros, se denegaría a la segunda subred la conectividad a la DMZ y a Internet. 

Después de analizar las características del filtro mediante un cortafuegos individual se examinarán las 
DMZ con cortafuegos dual. En la Figura. 4 se observan cortafuegos duales, internos y externos, pero en 
medio de ambos aparece una DMZ. 

 
Ilustración 4: DMZ con cortafuegos dual. 

Los filtros de interfaz para las localizaciones numeradas ¡lustradas en la Figura 4 aparecen en el listado siguiente: 

1. Filtros de interfaz internos correspondientes a la ilustración. 4 
  
2. Filtros de interfaz externa correspondientes a la ilustración. 4 
 

 
 
3. Filtros de interfaz interna correspondientes a la ilustración. 4 

 
4. Filtros de interfaz externa correspondientes a la ilustración. 4 

 
La interfaz externa en el cortafuegos 3600 tiene básicamente las mismas ACL que la interfaz externa del 
cortafuegos ilustrado en la Figura 27.3. Un filtro no reflexivo permite la comunicación con los servidores 
públicos utilizando los números de puerto adecuados, una ACL reflexiva autoriza el paso del tráfico de 
retorno  desde  los  anfitriones  internos  y  una  sentencia  deny  en  blanco  se  ocupa  del  tráfico  no 
autorizado. La interfaz interna del cortafuegos 3600 autoriza el paso a todo el tráfico hacia el exterior de 
la red. 
La  interfaz  del  P1X  está  autorizada  a  establecer  comunicación  exclusivamente  desde  el  servidor  web 
público para acceder al servidor SQL con una lista de acceso no reflexiva. Luego se ocupa de garantizar 
que  no  se  produzca  comunicación  alguna  desde  cualquier  mecanismo  distinto  del  servidor  web  que 
pueda  alcanzar  el  servidor  SQL,  con  una  lista  de  acceso  no  reflexiva  que  deniegue  específicamente 
cualquier clase de comunicación con el servidor SQL. Puesto que la entrada que permite al servidor web 
acceder  al  servidor  SQL  está  colocada  en  primer  lugar  en  la  lista,  mientras  se  utilicen  los  puertos 
correctos, el servidor web generará una coincidencia con la sentencia permit en primer lugar y tendrá 
autorización para acceder al servidor SQL. 

La sentencia siguiente es una sentencia reflexiva que permite que todas las comunicaciones establecidas 
desde  los  clientes  internos  accedan  a  los  recursos  externos.  Finalmente,  se  deniega  el  resto  de  las 
comunicaciones  externas  entrantes  mediante  el  uso  de  una  sentencia  deny  en  blanco,  situada  en  la 
interfaz PIX externa. 

Las últimas sentencias se aplican a la interfaz interna del PIX. Estas sentencias permiten que los clientes 
internos  accedan  a  recursos  externos  utilizando  HTTP.  HTTPS/SSL,  FTP  y  SMTP.  Existe  una  sentencia 
adicional  que  autoriza  al  servidor  SQL  a  comunicarse  con  el  servidor  web  en  la  DMZ.  Por  último,  una 
sentencia deny en blanco rechaza el resto de las comunicaciones. 

La ventaja que supone la utilización de una DMZ de cortafuegos dual consiste en la consecución de un 
nivel  de  seguridad  adicional  de  los  recursos.  Cuando  se  utilizan  cortafuegos  duales  resulta  más  difícil 
realizar entradas no autorizadas, ya que dos mecanismos deben estar comprometidos para acceder con 
éxito  a  los  recursos  internos.  Si  se  utilizan  cortafuegos  de  distintos  fabricantes,  la  seguridad  de  la  red 
aumenta,  ya  que  el  hacker  debe  tener  los  conocimientos  necesarios  para  acceder  a  plataformas 
completamente distintas. Lógicamente, la desventaja viene marcada por el coste de la red y los posibles 
quebraderos  de  cabeza  en  lo  que  respecta  a  su  configuración.  Sin  embargo,  en  las  redes  de  tamaño 
intermedio, los cortafuegos duales resultan muy populares. 

Nota: 

El  ejemplo  que  aparece  en  la  Figura  .4  utiliza  un  cortafuegos  dedicado  para  la  red  interna,  con  la 
estructura de un cortafuegos PIX de Cisco. Aunque la funcionalidad de cortafuegos básica consiste en el 
"filtrado  de  paquetes  (que  pueden  realizar  la  mayoría  de  los  enrutadores,  los  cortafuegos  verdaderos 
tienen una serie de funciones (incluyendo el filtro de paquete de estado completo) que pueden mejorar el 
nivel  de  seguridad  general  de  toda  la  red.  En  este  capítulo  se  analiza  exclusivamente  el  filtrado  de 
paquetes. Para obtener mayor información sobre los cortafuegos dedicados, puede consultar la dirección 
http://secinf.net/ifwe.html. 

En  las  situaciones  en  que  se  emplean  cortafuegos  triples  cabe  garantizar  un  alto  nivel  de  seguridad, 
incluso cuando se requiera implementar contextos de filtrado muy complejos. Por ejemplo, en la Figura. 
5 se muestra un ejemplo de diseño de alta seguridad con cortafuegos triple, utilizando DMZ duales. La 
DMZ externa se emplea para alojar los recursos de dominios absolutamente públicos, mientras que la 
DMZ  interna  sirve  para  alojar  el  servidor  SQL,  así  como  los  recursos  externos  a  la  red  (semipúblicos), 
como  servidores  VPN  y  servidores  web  externos  a  la  red  (como  el  acceso  a  web  de  Outlook).  El 
cortafuegos externo se utiliza para proteger a los servidores que tengan acceso a Internet, mientras que 
el cortafuegos medio se emplea para proteger los recursos externos a la red. Finalmente, el cortafuegos 
interno protege exclusivamente los recursos internos, haciendo que esta configuración de cortafuegos 
constituya una barrera formidable contra los posibles intentos de acceso no autorizado. 

 
  
Ilustración 5: DMZ con cortafuegos triple 

A continuación se incluye un listado de los filtros de interfaz correspondientes a las localizaciones numeradas de la 
Figura.5. 

1. Filtros de interfaz interna para la Figura. 5 

2. Filtros de interfaz externa para la Figura. 5 

3. Filtros de interfaz interna para la Figura. 5 

  

4.  Filtros de interfaz externa para la Figura. 5 

 
5. Filtros de interfaz interna para la Figura. 5 

6. Filtros de interfaz externa para la Figura. 5 

 
Los  diseños  que  implican  cortafuegos  triples  pueden  justificar  el  esfuerzo  que  supone  su  creación, 
aunque  sólo  se  utilizan  en  las  redes  más  extensas  y  con  mayor  preocupación  por  las  cuestiones  de 
seguridad, o en determinadas situaciones. 
  

Configuración de las ACL 

El primer paso a la hora de configurar las ACL consiste en comprender la sintaxis de las listas de acceso. 
En el caso de una lista de acceso estándar, la sintaxis no resulta demasiado compleja. Sin embargo, en el 
caso de las listas de acceso extendidas, la sintaxis puede resultar un poco más confusa. 

En este apartado se analiza la configuración de las listas de acceso utilizando ACL estándar y extendidas, 
tanto en estilo denominado como en estilo numerado. 

En la Tabla No. 1 se describen las características de los comandos empleados en este apartado. 

Tabla 1: Comandos de listas de acceso 

Comando  Descripción Modo    

access‐list [número de lista de acceso] [deny  Crea una lista de acceso IP numerada de  Configuración global 
\ permit] [origen] [máscara comodín de  carácter estándar 
origen] [log] 

access‐list [número de lista de acceso]  Crea  una  lista  de  acceso  numerada  de  Configuración global 

[deny I permit] [protocolo] [origen]  carácter extendido   
[máscara comodín de origen] 
[operadores de puerto (opcionales)] 
[destino] [máscara comodín de destino] 
[operadores de puerto (opcionales)] 
[established] [log] 
ip access‐list standard [nombre]  Crea una lista de acceso numerada de  Configuración global 
carácter estándar   
[deny I permit] [origen] [comodín de  Introduce sentencias en una lista de acceso  Configuración de listas  de acceso
origen] [log]  IP denominada de carácter estándar 
 
ip access‐list extended [nombre]  Crea una lista de acceso IP denominada de  Configuración global 
  carácter extendido   
[deny \ permit] [protocolo] [origen]  Introduce sentencias en una lista de acceso  Configuración de listas  de acceso
[máscara comodín de origen]  IP denominada de carácter extendido   
[operadores de puerto (opcionales)] 
[destino] [máscara comodín de origen] 
[operadores de puerto (opcionales)] 
[established] [log] 
 
ip  access‐group  [número  o  nombre  de  Aplica una lista de acceso a una interfaz Configuración de interfaz 
lista de acceso] [in I out] 
 
show ip access‐list [número o nombre de  Muestra una o todas las listas de acceso IP Ejecución de usuario 
lista de acceso] 
 
show access‐lists [número o nombre de lista  Muestra una o todas las listas de acceso IP Ejecución de usuario 
de acceso] 
 

El  primer  comando  que  aparece  en  la  lista,  access‐list,  se  usa  para  crear  listas  de  acceso  IP  numeradas  de  carácter 
estándar y extendido. El factor decisivo que indica si una lista de acceso debe ser estándar o extendida es simplemente el 
número utilizado para definir la lista de acceso. Si dicho número está comprendido entre 1 y 99, la lista de acceso será una 
ACL  IP  estándar.  Si,  por  el  contrario,  el  número  utilizado  se  sitúa  entre  100  y  199,  la  lista  de  acceso  será  una  ACL  IP 
extendida. 

 Nota:  En  las  nuevas  versiones  del  IOS,  las  ACL  numeradas  con  valores  comprendidos entre 1300 y 1999 
también están disponibles para las ACL IP estándar. 
La configuración de las listas de acceso en el formato numerado sigue una serie de reglas de carácter 
simple: 

• Las listas de acceso coinciden con las sentencias introducidas utilizando comandos de lista de 
acceso múltiples con el mismo número, para crear listas multisentencia. 

• Las listas de acceso coinciden con las sentencias procesadas en el orden introducido, donde la 
primera sentencia coincide con el paquete que se está utilizando. 

• Se incluye una sentencia deny al final de cada ACL, lo que significa que una vez que se aplica a 
una  interfaz,  todos  los  paquetes  que  no  coincidan  con  cualquiera  de  las  sentencias  permit 
presentes en una ACL se abandonarán automáticamente. 

• Las sentencias individuales presentes en las listas de acceso numeradas no pueden modificarse. 
Para  eliminar  una  sentencia  ACL  hay  que  utilizar  el  comando  no  access‐üst  [número], 
eliminando todas las sentencias asociadas con dicha ACL. 

A  medida  que  se  exploren  las  características  de  los  comandos  access‐list,  el  usuario  aprenderá  más 
sobre la estructura de estas reglas. Para los principiantes se explica a continuación cómo se construye 
una lista de acceso IP numerada estándar. 

Listas de acceso estándar 

La  sintaxis  utilizada  para  el  comando  access‐list  cuando  se  construye  un  listado  numerado  estándar 
resulta muy sencilla: access‐list [número de lista de acceso] [deny I permit] [origen] [máscara comodín de 
origen] [conectar]. El número debe situarse, lógicamente, en el rango que va de 1 a 99. La sección deny \ 
permit especifica la acción que se va a efectuar (abandonar o enviar) en relación con los paquetes que 
cumplen esta sentencia match. Las secciones origen y máscara comodín de origen definen qué paquetes 
deben  coincidir,  basándose  en  la  dirección  de  origen,  y  el  parámetro  opcional  log  indica  al  IOS  que 
conecte con paquetes que coincidan con esta lista de acceso con la función syslog. 

Las únicas partes de una lista de acceso IP estándar que generan cierta dificultad son las secciones de 
dirección de origen y la de máscara comodín. La sección origen es la parte de la dirección de origen con 
la que se desea coincidir. Por ejemplo, si se desea coincidir con todas las direcciones de origen en la red 
172.16.0.0, habría que introducir 172.16.0.0 como dirección de origen. Verdaderamente, se puede co‐
locar cualquier cosa que se desee en los últimos octetos de la dirección (siempre y cuando se configure 
la  máscara  correctamente),  pero  no  tiene  sentido  introducir  una  dirección  completa  cuando  lo  único 
que  se  desea  es  efectuar  una  coincidencia  con  los  primeros  dos  octetos.  La  máscara  realmente 
determina qué cantidad de la dirección de origen forma parte de la coincidencia. La máscara está escrita 
en el formato wildcard (comodín), y quizás pueda parecer que está colocada en orden inverso a cómo 
cabría esperar. En una máscara comodín, las partes de la dirección que se describen mediante el valor 
binario 0 en la máscara deben coincidir exactamente, mientras que se ignoran las partes que tienen un 
valor binario 1. 

Por  ejemplo,  para  efectuar  una  coincidencia  con  172.16.0.0‐172.16.255.255,  habría  que  introducir  la 
dirección de origen de 172.16.0.0 con una máscara comodín de 0.0.255.255. Siguiendo la misma lógica, 
para efectuar una coincidencia con cada dirección IP situada entre 192.168.1.128 y 192.168.1.255 habría 
que introducir una dirección de origen de 192.168.1.128 con una máscara comodín de 0.0.0.127. Esta 
combinación coincide con las direcciones IP seleccionadas, ya que en lenguaje binario todos los bits que 
tienen un valor O deben coincidir con la IP de origen escogida (192.168.1.128), mientras que todos los 
valores  binarios  1  pueden  ser  diferentes.  Cuando  se  convierte  a  binario,  esta  combinación  tiene  el 
siguiente aspecto: 
IP ‐ 192.168.1.128 : 11000000.10101000.00000001.10000000 
IP ‐ 192.168.1.255 : 11000000.10101000.00000001.11111111          
Mask ‐ 0.0.0.127   : 00000000.00000000.00000000.01111111 
 
Basándose en esta información, si se desea configurar un filtro de paquete utilizando ACL estándar para 
bloquear todas las transmisiones desde 192.168.1.1, autorizar todas las comunicaciones desde el resto 
de la red 192.168.1.0 y denegar todas las demás, habría que crear el filtro de paquete con los comandos 
siguientes: 
 
Router(config)#access‐list 1 deny 192.168.1.1 0.0.0.0  
Router (config)#access‐list 1 permit 192.168.1.0 0.0.0.255 
 
Nota:  Para  especificar  un  anfitrión  individual  hay  que  utilizar  la  palabra  clave  host  en  la  ACL.  Por 
ejemplo, en el comando anterior, en lugar de escribir access‐list 1 deny 192.168.1.1 0.0.0.0, habría que 
escribir typed access‐list 1 deny host 192.168.1.1. 
 
Para garantizar la creación de esta lista de accesos se pueden utilizar los comandos show ip access‐list o 
show access‐lists: 
 
Routert show access‐lists 
Standard IP access list 1  
deny    192.168.1.1   
permit   192.168.1.0, wildcard bits 0.0.0.255  
Router# show ip access‐list  
Standard IP access list 1 
deny     192.168.1.1 
permit  192.168.1.0, wildcard  bits   0.0.0.255 
Router# 
 
El  orden  de  los  comandos  en  una  ACL  resulta  muy  importante.  Por  ejemplo,  si  se  reorganizan  estas 
sentencias,  la  dirección  192.168.1.1  tendría  autorización  para  comunicarse,  ya  que  dicha  dirección 
coincide  con  192.168.1.0  0.0.0.255.  Hay  que  recordar  que  una  ACL  simplemente  utiliza  la  primera 
sentencia coincidente e ignora el resto. 
 
Por lo general, lo lógico es colocar las entradas más específicas en la parte superior de la lista. El truco 
consiste  en  examinar  mentalmente  el  orden  de  la  lista,  punto  por  punto,  y  garantizar  que  todos  los 
objetivos se encuentren satisfechos en el listado. Sin embargo, a medida que la lista se complica, este 
proceso se hace cada vez más complejo. 
 
Por ejemplo, hay que suponer que se desea configurar un listado que efectúe las siguientes tareas: 
• Autorizar  todas  las  direcciones  situadas  en  el  rango  que  va  de  192.168.1.64  ;                  a 
192.168.1.127. 
• Autorizar las que van de 192.168.1.1 a 192.168.1.3. 
• Autorizar todas las direcciones comprendidas entre 10.0.2.0 y 10.255.255.255. 
• Denegar todas las demás direcciones. 
 
En este caso, se podría utilizar la siguiente lista de acceso para cumplir estas metas: 
 
Router(config)#access‐list  1 permit 10.0.0.0 0.255.255.255 
Router(config)#access‐list  1 permit 192.168.1.64 0.0.0.127 
Router(config)#access‐list 1 permit host 192.168.1.1         
Router(config)#access‐list  1 permit host 192.168.1.2 
Router(config)#access‐list  1 permit host 192.168.1.3 
Router(config)#access‐list  1 deny 10.0.1.0 0.0.0.255 
 
¿Usted reconoce los problemas que surgen con esta lista? A continuación se examinará cada objetivo en 
orden para garantizar el análisis de cada uno de los problemas. 
En  primer  lugar,  se  desea  autorizar  el  rango  que  va  de  192.168.1.64  a  127.  Mirando  en  la  lista,  la 
segunda  sentencia  cumple  este  objetivo.  Sin  embargo,  la  sentencia  access‐list  1  permit  192.168.1.64 
0.0.0.127 coincide con todas las direcciones IP situadas entre 192.168.1.0 y 192.168.1.127. 
 
El  segundo  objetivo  consiste  en  autorizar  el  rango  que  va  desde  192.168.1.1  hasta  192.168.1.3  para 
establecer la comunicación. Aunque la tercera, la cuarta y la quinta sentencia efectúan esta tarea, ésta 
no es la manera más eficaz de hacerlo. Además, la segunda sentencia del listado se alcanzaría antes de 
acceder a estas sentencias. 
 
El tercer objetivo consiste en autorizar todas las direcciones situadas en el rango que va de 10.0.2.0 a 
10.255.255.255  para  establecer  la  comunicación.  Aunque  la  primera  sentencia,  access‐list  1  permit 
10.0.0.0 0.255.255.255, cumple esta tarea, coincide con todas las direcciones desde la red 10.0.0.0. 
 
El objetivo final es denegar todos los paquetes, lo cual no se lleva a cabo debido a las siguientes razones: 
• La  segunda  sentencia  autoriza  al  rango  que  va  de  192.168.1.0  a  192.168.1.63  para  que 
establezcan la comunicación. 
• La  primera  sentencia  autoriza  todas  las  direcciones  de  la  red  10.0.0.0  (10.0.0.0  a 
10.255.255.255)  para  que  establezcan  la  comunicación,  lo  cual  no  coincide  con  el  rango 
especificado. 
 
Para eliminar estos problemas habría que reconstruir la lista de la siguiente manera: 
 
Router(config)#access‐list  1  deny 10.0.0.0 0.0.1.255 
Router(config)#access‐list  1  permit 10.0.0.0 0.255.255.255 
Router(config)#access‐list  1  permit 192.168.1.64 0.0.0.63   
Router(config)#access‐list  1  permit 192.168.1.0 0.0.0.3 
 
Hay que observar que, en este caso, se puede realizar esta tarea con sólo cuatro sentencias. La primera 
sentencia  deniega  el  rango  de  dirección  IP  que  va  de  10.0.0.0  a  10.0.1.255,  ya  que  la  dirección  y  la 
máscara coinciden de la siguiente manera: 
 

 
La segunda sentencia autoriza todas las direcciones de la red 10.0.0.0 que no coincidan con la primera 
sentencia. La tercera sentencia admite todos los paquetes situados en el rango que va de 192.168.1.64 a 
192.168.1.127, como se muestra a continuación: 

 
La cuarta sentencia autoriza todos los paquetes que van de 192,168‐1‐1 a 192.168.1.3, como se muestra 
a continuación: 

 
Nota:  En  realidad,  el  último  filtro  también  coincide  con  192.168.1.0,  pero  como  esta  dirección  no  se 
puede utilizar en una red de clase C sin superred, no tiene sentido denegar la dirección específicamente. 
 
El  deny  implícito  situado  al  final  de  la  lista  de  acceso  se  ocupa  del  último  objetivo,  que  consiste  en 
rechazar todos los demás paquetes. 
 
Una vez creada la lista de acceso, será preciso aplicarla a una interfaz y elegir una dirección utilizando el 
comando ip access‐group [número o nombre de lista de acceso] [entrada\salida]. Hay que recordar que 
cuando se aplica una lista de acceso se suele desear hacerlo tan cerca del origen del paquete como sea 
posible.  De  esta  manera,  si  se  desea  utilizar  esta  lista  para  realizar  una  coincidencia  interna  con  los 
usuarios que entren en el enrutador, habría que aplicar la lista a la interfaz de enrutador interna con la 
dirección entrante, como se muestra a continuación: 
 
Router{config‐if )# ip access‐group 1 in 
 
Nota: 
Hay que tener en cuenta que sólo se puede aplicar una lista de acceso individual en cualquier interfaz  
para  el  tráfico  orientado  hacia  dentro  o  hacia  fuera  (una  ACL  por  dirección).  Por  tanto,  es  preciso 
garantizar que todas las metas requeridas puedan alcanzarse con una ACL individual. 
 
En el caso de una lista de acceso denominada, el proceso es casi idéntico, exceptuando el hecho de que 
se modifica la ACL. Cuando se introduce la ACL se emplea el comando ip access‐list standard [nombre]. 
Este  comando  permite  cambiar  al  modo  de  configuración  de  lista  de  acceso  para  la  lista  de  acceso 
denominada, como se ilustra a continuación: 
 
Router(config)#ip access‐list standard test 
Router (config‐std‐nacl) # 
 
Una vez en el modo de configuración de lista de acceso se pueden introducir los parámetros de lista de 
acceso utilizando sentencias permit o deny: 
 
Router(config‐std‐nacl)#   deny   10.0.0.0   0.0.255.255   
Router(config‐std‐nacl)#   permit   172.16.0   0.0.255.255    
 
Estas sentencias se procesan en el orden en que se introduzcan, como ocurre con las listas de acceso 
numeradas. La única diferencia está en el hecho de que, a diferencia de las listas de acceso numeradas, 
se  pueden  eliminar  comandos  individuales  en  una  lista  de  acceso  denominada  mediante  el  uso  de 
sentencias específicas no deny o no permit: 

 
Consejo:  La diferencia  fundamental que  existe  entre  una lista  de acceso  denominada y  una  numerada 
radica en la capacidad de utilizar nombres descriptivos para listas de acceso denominadas y la capacidad 
de  modificar  entradas  individuales  en  las  listas  de  acceso  numeradas.  Sin  embargo,  esta  última 
diferencia  suele  quedar  anulada,  ya  que  basta  con  copiar  la  sentencia  de  lista  de  acceso  en  el 
portapapeles desde una lista de acceso numerada (mostrada en un comando show run o show star) y 
reordenar la lista a placer. Una vez terminado este proceso, basta con eliminar la lista de acceso original 
con  un  comando  no  access‐list  (número]  y  pegar  la  lista  de  acceso  modificada  en  la  ventana  del 
terminal. 
 
Hay que observar que la sentencia host aparece en la parte superior de la lista de acceso incluso si se 
introduce después de otras sentencias. Se trata de un elemento específico que permite acceder a listas 
que pertenecen a un anfitrión determinado, ya que tienen un carácter más específico y, habitualmente, 
deberían colocarse en la parte superior de la lista. También hay que advertir la presencia de la sentencia 
permit  any.  La  palabra  clave  any  constituye  una  forma  rápida  de  garantizar  que  todos  los  paquetes 
coincidan con un filtro. La palabra clave any es la misma que se especificó en un IP de 0.0.0.0 (a decir 
verdad, cualquier IP) con una máscara 255.255.255.255. 
 
Listas de acceso extendidas   
 
Después de conocer las ACL estándar, en este apartado se explicarán las complejidades propias de las 
ACL  extendidas.  En  una  ACL  extendida  se  pueden  especificar  muchos  más  parámetros,  protocolos 
(incluyendo IP, TCP y UDP), direcciones de destino y puertos (para TCP y UDP). 
 
Nota: Las ACL IP extendidas numeradas pueden utilizar rangos que van de100 a 199 o de 2000 a 2699. 
 
Con una ACL extendida se debe especificar un protocolo para generar la coincidencia. El protocolo con el 
que se establece dicha coincidencia puede ser cualquier número de protocolo IP situado entre 1 y 255, o 
cualquiera de las siguientes palabras clave 
• IP (para coincidir con todos tos paquetes IP).   
• ICMP. 
• TCP  
• EIGRR 
• IGRP 
• OSPF 
• Los protocolos restantes escapan al propósito de este apartado (PIM, IPINIP GRE, NOS o IGMP).   
 
Cuando se genera una coincidencia con TCP o UDP se abren otras posibilidades interesantes. Se puede 
elegir la posibilidad de establecer coincidencias con puertos de origen o de destino. Cuando se coincide 
con puertos es preciso tener la capacidad de efectuar la coincidencia basándose en cinco operadores: 
• It.   Menor que el número listado. 
• gt.   Mayor que el número listado. 
• eq.   Igual que el número listado. 
• neq.   Distinto del número listado. 
• range. Todos los puertos situados en el rango especificado mediante dos números. 
 
Nota:  También  se  pueden especificar  puertos  mediante el  uso  de palabras  clave en  lugar de  números. 
Entre las palabras clave IOS reconocidas para puertos se incluyen las siguientes: bgp, echo, finger, ftp, 
ftp‐data, gopher, irc, nntp, pop2, pop3, smtp, syslog, telnet, whois, y www. 
 
Asimismo,  es  posible  especificar  la  autorización  de  paquetes  (o  su  rechazo,  aunque  esto  último  no 
resulta útil) basándose en el paquete que forma parte de una sesión previamente establecida mediante 
el  uso  de  la  palabra  clave  established.  De  esta  misma  manera,  se  puede  utilizar  la  palabra  clave 
established para las sentencias reflexive en las ACL. 
 
Para  ver  de  qué  forma  casan  todas  estas  piezas  adicionales  en  una  ACL  extendida,  a  continuación  se 
analizará  un  conjunto  de  metas  de  filtrado  y  se  explicará  cómo  alcanzar  estos  objetivos.  Las  metas 
requeridas  para  filtrar  los  paquetes  entrantes  en  la  interfaz  externa  del  enrutador  se  enumeran  a 
continuación: 
• Deben  autorizarse  todos  los  paquetes  destinados  a  192.168.1.1  utilizando  un  puerto  80  de 
destino TCP. 
• Deben  autorizarse  todas  las  comunicaciones  que  se  originen  desde  la  red  privada  a  los 
servidores web externos que utilicen HTTP y HTTPS. 
• Deben autorizarse todas las comunicaciones entrantes desde el anfitrión externo 10.1.1.1 que 
utilicen números de puerto de origen TCP y UDP que vayan de 22.000 a 44.000. 
• Deben autorizarse todas las comunicaciones entrantes al anfitrión 192.168.1.200. 
• Deben autorizarse todas las sesiones no establecidas que entren en la interfaz externa y utilicen 
puertos de destino conocidos al anfitrión 192.168.1.100. 
• Debe rechazarse todo el tráfico restante. 
 
Para alcanzar el primer objetivo hay que introducir una sentencia similar a la siguiente: 
 
Router(config)#access‐list 100 permit tcp any host 192.168.1.1 eq 80 
 
La palabra clave any indica al enrutador que debe realizar una coincidencia con cualquier IP de origen. 
Como el puerto no se especifica a continuación, se efectúa una coincidencia con todos los puertos de 
origen.  La  sección  host  192.168.1.1  indi ca  al  enrutador  que  debe  efectuar  una  coincidencia  con  el 
anfitrión de  destino  192.168.1.1.  Finalmente,  eq  80  indica  al  enrutador  que debe  efectuar una  coinci‐
dencia  con  el  puerto  destino  80.  Este  filtro  efectúa  exactamente  la  tarea  requerida:  establece 
coincidencia con todas las comunicaciones procedentes de cualquier anfitrión destinado a 192.168.1.1 
utilizando el puerto de destino 80 TCP 80 (HTTP).  
 
Para  establecer  una  coincidencia  con  el  próximo  objetivo  hay  que  emplear  sentencias  similares  a  las 
siguientes: 
 
Router(config)ftaccess‐list 100 permit tcp any eq 80 any established  
Router(config)#access‐list 100 permit tcp any eq 443 any established 
 
Como lo que se desea es autorizar exclusivamente los paquetes que utilicen HTTP o HTTPS para regresar 
a los anfitriones situados en la red interna, es necesario  establecer una coincidencia con el puerto de 
origen en 80 y 443 en lugar de hacerlo con el de destino. Asimismo, puesto que únicamente se desea 
devolver  paquetes  procedentes  exclusivamente  de  las  sesiones  previamente  establecidas  por  estos 
anfitriones, se utiliza la palabra clave established. 
 
Para autorizar todas las comunicaciones entrantes procedentes del anfitrión externo 10.1.1.1 utilizando 
números de puerto de origen TCP y UDP comprendidos entre 22.000 y 44.000, hay que introducir dos 
sentencias similares a las siguientes: 
 
Router(config)#access‐list 100 permit tcp 10.1.1.1 range 22000 44000 any  
Router(config)#access‐list 100 permit udp 10.1.1.1 range 22000 44000 any 
 
Para  autorizar  todas  las  conexiones  internas  al  anfitrión  192.168.1.200  hay  que  utilizar  la  sentencia 
siguiente: 
 
Router(config)#access‐list 100 permit ip any host 192.168.1.200 
 
Finalmente,  para  autorizar  conexiones  utilizando  puertos  de  destino  conocidos  al  anfitrión 
192.168.1.100 hay que utilizar la sentencia siguiente: 
 
Router(config)#access‐list 100 permit ip any host 192.168.1.100 lt 1024 
 
Una  vez  terminada  la  construcción  de  la  ACL,  cabe  aplicarla  a  la  interfaz  externa  del  enrutador, 
utilizando el comando estándar ip access‐group [número o nombre de lista de acceso][in \out]. 
 
Las ACL extendidas denominadas siguen los mismos principios generales las ACL numeradas, por lo que 
aquí no se analizarán sus características Basta aplicar los principios relacionados con las ACL extendidas 
a los comandos enumerados en el apartado dedicado a las ACL denominadas estándar. Siguiendo este 
procedimiento, el usuario podrá crear ACL extendidas denominadas. 
 
 
  ACL extendidas y ACL reflexivas 
 
  Hay que observar que una ACL extendida que utiliza la palabra clave 
established  no  es  lo  mismo  que  una  ACL  reflexiva  verdadera.  Una 
  ACL reflexiva verdadera lleva un registro de las sesiones y construye 
  entradas  ACL  de  carácter  temporal  basándose  en  dichas  sesiones, 
  mientras que la palabra clave established simplemente examina los 
  bits ACK y RST en paquetes y autoriza cualquier paquete que cumpla 
 
los criterios de filtro configurados con estos bits. El simple uso de la 
palabra clave established, aunque puede reducir la complejidad de 
  la  ACL  y  deshacer  la  mayor  parte  de  los  intentos  de  entrada,  no 
  detendrá a un hacker hábil que sepa cómo manipular los bits ACK o 
  RST en un paquete y, por tanto, no deben utilizarse en redes de alta 
  seguridad.  En  el  presente  libro  no  se  analizarán  con  detalle  las 
características  de  las  ACL  reflexivas,  pero  si  el  lector  desea  más 
  información  al  respecto,  se  recomienda  visitar  la  dirección 
  http://www.dsco.comando/univercd/cc/td/doc/ 
  product/software/ios 121/12 Icgcr/secur_c/scprt3/scdreflx.htm. 
 
   
 
 
 
 
Referencias Bibliográficas: 
HILL, Brian. CISCO Manual de referencia. McGaw‐Hill/Interamericana de España. Pp 963‐990.