Un host de bastión es una computadora que es fundamental para hacer cumplir la política de

seguridad de red de su organización.

Los hosts de Bastion deben estar altamente protegidos, ya que son vulnerables a los ataques debido
al hecho de que están expuestos a redes desconocidas o no confiables y son los principales puntos
de contacto para los usuarios de redes confiables. A menudo, los hosts bastion proporcionan
servicios a usuarios externos, como servicios web y sistemas de acceso público. Debido a que es
muy probable que estas computadoras sean atacadas, a menudo se las denomina anfitriones de
sacrificio.

En casos más raros, los hosts de bastión se utilizan como uno de los tres componentes para construir
un sistema de servidor de seguridad: el componente que inspecciona el tráfico de red en las capas
de protocolo sobre la capa de Internet. Los dos componentes restantes son enrutadores: uno
conocido como el enrutador interno (que separa la red perimetral de la red interna) y el otro
conocido como el enrutador externo (que separa la red perimetral de la red externa o no confiable).
Debido a que los hosts bastion solo contienen una tarjeta de interfaz de red, esta computadora no
puede protegerse contra los ataques de suplantación de IP. Por lo tanto, para evitar la suplantación
de IP, el host de bastión debe colocarse entre dos enrutadores; un enrutador filtra todas las
solicitudes de las redes que no son de confianza y el otro filtra todas las solicitudes de las redes de
confianza para garantizar que ningún paquete falsificado llegue al host del bastión. Estos
enrutadores también verifican que todo el tráfico de red que pasa entre ellos se dirija únicamente
al host de bastión.
En general, un host bastion ejecuta un sistema operativo de propósito general, como UNIX, VMS,
Windows NT, en lugar de un sistema operativo basado en ROM o firmware. Recibe su nombre de
las protecciones altamente fortificadas en las paredes exteriores de los castillos medievales.
Un host Bastion es una máquina que está fuera de su zona de seguridad. Y se espera que sea un
punto débil y que necesite consideraciones de seguridad adicionales.
Debido a que sus dispositivos de seguridad se encuentran técnicamente fuera de su zona de
seguridad, los firewalls y dispositivos de seguridad también se consideran en la mayoría de los casos
en los hosts Bastion.
Normalmente estamos hablando de:
Servidores DNS
Servidores FTP
Servidores VPN

Existen otros dispositivos como Un servidor Jump, que está destinado a romper la brecha entre dos
zonas de seguridad.
El propósito previsto aquí es tener una puerta de acceso para acceder a algo dentro de la zona de
seguridad, desde la DMZ.
La razón principal por la que existe esto es para asegurarse de que la única entrada conocida a un
servidor específico que tiene que ser accesible desde el exterior se mantenga actualizada y se
conozca que solo tiene que conectarse a (a) anfitrión (s) específico (s).
Por lo general, esta es una caja de Linux reforzada que solo se usa para SSH.

Un host de Bastion es principalmente un sistema reforzado que sirve un solo servicio a redes
desprotegidas. El mejor ejemplo es DNS, HTTP. Estos sistemas están expuestos a redes
desprotegidas, como Internet, y generalmente se colocan en DMZ.
un servidor Jump es generalmente un sistema reforzado que se usa para administrar otros sistemas
en una red. Jump Server es donde un Administrador inicia sesión primero, y desde allí, administra
otros sistemas en la red. Este método tiene varios beneficios. La ubicación de un servidor de salto
varía según la implementación.
Hablar de Bastion Host / Server es un punto de entrada único a un clúster a través de SSH.
Por ejemplo, conectarse a un servidor Linux a través de SSH.
El sistema remoto desde el cual se conectará a su servidor está fuera de su Zona de seguridad.

Hosts bastión en VPC (nube virtual privada)

La inclusión de hosts bastión en su entorno de VPC le permite conectarse de forma segura a sus
instancias de Linux sin exponer su entorno a Internet. Después de configurar sus hosts bastión,
puede tener acceso al resto de las instancias de su VPC a través de conexiones Secure Shell (SSH) en
Linux. Los hosts bastión se configuran también con grupos de seguridad para proporcionar un
control de entrada detallado.

Los hosts bastión de Linux se implementan en dos zonas de disponibilidad para permitir el acceso
inmediato en la VPC. Puede configurar el número de instancias de host bastión en el momento del
lanzamiento.

Un grupo de Auto Scaling garantiza que el número de instancias de host bastión coincida con la
capacidad deseada que especifique durante el lanzamiento.

Los hosts bastión se implementan en subredes públicas (DMZ) de la VPC.

Las direcciones IP dinámicas se asocian a las instancias de host bastión para que sean más fáciles de
recordar y para permitir estas direcciones IP desde firewalls on-premises. Si se termina una instancia
y el grupo de Auto Scaling lanza una instancia nueva en su lugar, las direcciones IP dinámicas
existentes se vuelven a asociar a las nuevas instancias. De este modo, se garantiza que se utilicen
las mismas direcciones IP dinámicas de confianza en todo momento.

El acceso de entrada a los hosts bastión está restringido a los ámbitos de CIDR conocidos. Esto se
consigue asociando las instancias de host bastión a un grupo de seguridad. El inicio rápido crea un
recurso BastionSecurityGroup con este fin.

Los puertos están limitados para permitir únicamente el acceso necesario a los hosts bastión. Para
los host bastión de Linux, el puerto TCP 22 para las conexiones SSH suele ser el único puerto
permitido.

Ahora bien, hablando de cortafuegos:

Según [Ran95], un firewall o cortafuegos es un sistema o grupo de sistemas que hace cumplir una
política de control de acceso entre dos redes. De una forma más clara, podemos definir un
cortafuegos como cualquier sistema (desde un simple router hasta varias redes en serie) utilizado
para separar - en cuanto a seguridad se refiere - una máquina o subred del resto, protegiéndola así
de servicios y protocolos que desde el exterior puedan suponer una amenaza a la seguridad. El
espacio protegido, denominado perímetro de seguridad, suele ser propiedad de la misma
organización, y la protección se realiza contra una red externa, no confiable, llamada zona de riesgo.
Evidentemente la forma de aislamiento más efectiva para cualquier política de seguridad consiste
en el aislamiento físico, es decir, no tener conectada la máquina o la subred a otros equipos o a
Internet. Sin embargo, en la mayoría de las organizaciones - especialmente en las de I+D - los
usuarios necesitan compartir información con otras personas situadas en muchas ocasiones a miles
de kilómetros de distancia, con lo que no es posible un aislamiento total. El punto opuesto consistiría
en una conectividad completa con la red, lo que desde el punto de vista de la seguridad es muy
problemático: cualquiera, desde cualquier parte del mundo, puede potencialmente tener acceso a
nuestros recursos. Un término medio entre ambas aproximaciones consiste en implementar cierta
separación lógica mediante un cortafuegos.

Antes de hablar de cortafuegos es casi obligatorio dar una serie de definiciones de partes o
características de funcionamiento de un firewall; por máquina o host bastión (también se
denominan gates) se conoce a un sistema especialmente asegurado, pero en principio vulnerable a
todo tipo de ataques por estar abierto a Internet, que tiene como función ser el punto de contacto
de los usuarios de la red interna de una organización con otro tipo de redes. El host bastión filtra
tráfico de entrada y salida, y también esconde la configuración de la red hacia fuera.

Por filtrado de paquetes entendemos la acción de denegar o permitir el flujo de tramas entre dos
redes (por ejemplo la interna, protegida con el firewall, y el resto de Internet) de acuerdo a unas
normas predefinidas; aunque el filtro más elemental puede ser un simple router, trabajando en el
nivel de red del protocolo OSI, esta actividad puede realizarse además en un puente o en una
máquina individual. El filtrado también se conoce como screening, y a los dispositivos que lo
implementan se les denomina chokes; el choke puede ser la máquina bastión o un elemento
diferente.

Un proxy es un programa (trabajando en el nivel de aplicación de OSI) que permite o niega el acceso
a una aplicación determinada entre dos redes. Los clientes proxy se comunican sólo con los
servidores proxy, que autorizan las peticiones y las envían a los servidores reales, o las deniegan y
las devuelven a quien las solicitó.
Físicamente, en casi todos los cortafuegos existen al menos un choke y una máquina bastión,
aunque también se considera firewall a un simple router filtrando paquetes, es decir, actuando
como choke; desde el punto de vista lógico, en el cortafuegos suelen existir servidores proxy para
las aplicaciones que han de atravesar el sistema, y que se situan habitualmente en el host bastión.
También se implementa en el choke un mecanismo de filtrado de paquetes, y en alguno de los dos
elementos se suele situar otro mecanismo para poder monitorizar y detectar la actividad
sospechosa.
Los firewalls son cada vez más necesarios en nuestras redes, pero todos los expertos recomiendan
que no se usen en lugar de otras herramientas, sino junto a ellas; cualquier cortafuegos, desde el
más simple al más avanzado, presenta dos gravísimos problemas de seguridad: por un lado,
centralizan todas las medidas en un único sistema, de forma que si éste se ve comprometido y el
resto de nuestra red no está lo suficientemente protegido el atacante consigue amenazar a toda la
subred simplemente poniendo en jaque a una máquina. El segundo problema, relacionado con éste,
es la falsa sensación de seguridad que un cortafuegos proporciona: generalmente un administrador
que no disponga de un firewall va a preocuparse de la integridad de todas y cada una de sus
máquinas, pero en el momento en que instala el cortafuegos y lo configura asume que toda su red
es segura, por lo que se suele descuidar enormemente la seguridad de los equipos de la red interna.
Esto, como acabamos de comentar, es un grave error, ya que en el momento que un pirata acceda
a nuestro cortafuegos - recordemos que es un sistema muy expuesto a ataques externos -
automáticamente va a tener la posibilidad de controlar toda nuestra red.

Además - esto ya no es un problema de los firewalls sino algo de sentido común -, un cortafuegos
evidentemente no protege contra ataques que no pasan por él: esto incluye todo tipo de ataques
internos dentro del perímetro de seguridad, pero también otros factores que a priori no deberían
suponer un problema. El típico ejemplo de estos últimos son los usuarios que instalan sin permiso,
sin conocimiento del administrador de la red, y muchas veces sin pensar en sus consecuencias, un
simple modem en sus PCs o estaciones de trabajo; esto, tan habitual en muchas organizaciones,
supone la violación y la ruptura total del perímetro de seguridad, ya que posibilita accesos a la red
no controlados por el cortafuegos. Otro problema de sentido común es la reconfiguración de los
sistemas al pasarlos de una zona a otra con diferente nivel de seguridad, por ejemplo al mover un
equipo que se encuentra en el área protegida a la DMZ (zona desmilitarizada, por sus siglas en ingles
sigla en inglés de demilitarized zone); este acto - que en ocasiones no implica ni tan siquiera el
movimiento físico del equipo, sino simplemente conectarlo en una toma de red diferente - puede
ocasionar graves problemas de seguridad en nuestra organización, por lo que cada vez que un
cambio de este estilo se produzca no sólo es necesaria la reconfiguración del sistema, sino la revisión
de todas las políticas de seguridad aplicadas a esa máquina ([Mel97]).

Cortafuegos de filtrado de paquetes

Un firewall sencillo puede consistir en un dispositivo capaz de filtrar paquetes, un choke: se trata
del modelo de cortafuegos más antiguo ([Sch97]), basado simplemente en aprovechar la capacidad
de algunos routers - denominados screening routers - para hacer un enrutado selectivo, es decir,
para bloquear o permitir el tránsito de paquetes mediante listas de control de acceso en función de
ciertas características de las tramas, de forma que el router actue como pasarela de toda la red.
Generalmente estas características para determinar el filtrado son las direcciones origen y destino,
el protocolo, los puertos origen y destino (en el caso de TCP y UDP), el tipo de mensaje (en el caso
de ICMP) y los interfaces de entrada y salida de la trama en el router.
En un cortafuegos de filtrado de paquetes los accesos desde la red interna al exterior que no están
bloqueados son directos (no hay necesidad de utilizar proxies, como sucede en los cortafuegos
basados en una máquina con dos tarjetas de red), por lo que esta arquitectura es la más simple de
implementar (en muchos casos sobre hardware ya ubicado en la red) y la más utilizada en
organizaciones que no precisan grandes niveles de seguridad - como las que vemos aquí -. No
obstante, elegir un cortafuegos tan sencillo puede no ser recomendable en ciertas situaciones, o
para organizaciones que requieren una mayor seguridad para su subred, ya que los simples chokes
presentan más desventajas que beneficios para la red protegida. El principal problema es que no
disponen de un sistema de monitorización sofisticado, por lo que muchas veces el administrador no
puede determinar si el router está siendo atacado o si su seguridad ha sido comprometida. Además
las reglas de filtrado pueden llegar a ser complejas de establecer, y por tanto es difícil comprobar
su corrección: habitualmente sólo se comprueba a través de pruebas directas, con los problemas de
seguridad que esto puede implicar.

Si a pesar de esto decidimos utilizar un router como filtro de paquetes, como en cualquier firewall
es recomendable bloquear todos los servicios que no se utilicen desde el exterior (especialmente
NIS, NFS, X-Window y TFTP), así como el acceso desde máquinas no confiables hacia nuestra subred;
además, es también importante para nuestra seguridad bloquear los paquetes con encaminamiento
en origen activado.
Dual-Homed Host
El segundo modelo de cortafuegos está formado por simples máquinas Unix equipadas con dos o
más tarjetas de red y denominadas ([SH95]) anfitriones de dos bases (dual-homed hosts) o
multibase (multi-homed hosts), y en las que una de las tarjetas se suele conectar a la red interna a
proteger y la otra a la red externa a la organización. En esta configuración el choke y el bastión
coinciden en el mismo equipo: la máquina Unix.

El sistema ha de ejecutar al menos un servidor proxy para cada uno de los servicios que deseemos
pasar a través del cortafuegos, y también es necesario que el IP Forwarding esté deshabilitado en el
equipo: aunque una máquina con dos tarjetas puede actuar como un router, para aislar el tráfico
entre la red interna y la externa es necesario que el choke no enrute paquetes entre ellas. Así, los
sistemas externos “verán” al host a través de una de las tarjetas y los internos a través de la otra,
pero entre las dos partes no puede existir ningún tipo de tráfico que no pase por el cortafuegos:
todo el intercambio de datos entre las redes se ha de realizar bien a través de servidores proxy
situados en el host bastión o bien permitiendo a los usuarios conectar directamente al mismo. La
segunda de estas aproximaciones es sin duda poco recomendable, ya que un usuario que consiga
aumentar su nivel de privilegios en el sistema puede romper toda la protección del cortafuegos, por
ejemplo reactivando el IP Forwarding); además - esto ya no relativo a la seguridad sino a la
funcionalidad del sistema - suele ser incómodo para los usuarios tener que acceder a una máquina
que haga de puente entre ellos e Internet. De esta forma, la ubicación de proxies es lo más
recomendable, pero puede ser problemático el configurar cierto tipo de servicios o protocolos que
no se diseñaron teniendo en cuenta la existencia de un proxy entre los dos extremos de una
conexión.
Screened Host
Un paso más en términos de seguridad de los cortafuegos es la arquitectura screened host o choke-
gate, que combina un router con un host bastión, y donde el principal nivel de seguridad proviene
del filtrado de paquetes (es decir, el router es la primera y más importante línea de defensa). En la
máquina bastión, único sistema accesible desde el exterior, se ejecutan los proxies de las
aplicaciones, mientras que el choke se encarga de filtrar los paquetes que se puedan considerar
peligrosos para la seguridad de la red interna, permitiendo únicamente la comunicación con un
reducido número de servicios.

Pero, ¿dónde situar el sistema bastión, en la red interna o en el exterior del router? La mayoría de
autores ([Ran93], [Sem96]...) recomiendan situar el router entre la red exterior y el host bastión,
pero otros ([WC94]) defienden justo lo contrario: situar el bastión en la red exterior no provoca
aparentemente una degradación de la seguridad, y además ayuda al administrador a comprender
la necesidad de un elevado nivel de fiabilidad en esta máquina, ya que está sujeta a ataques externos
y no tiene por qué ser un host fiable; de cualquier forma, la “no degradación” de la seguridad
mediante esta aproximación es más que discutible, ya que habitualmente es más fácil de proteger
un router que una máquina con un operativo de propósito general, como Unix, que además por
definición ha de ofrecer ciertos servicios: no tenemos más que fijarnos en el número de problemas
de seguridad que afectan a por ejemplo a IOS (el sistema operativo de los routers Cisco), muy
reducido frente a los que afectan a diferentes flavours de Unix. En todo caso, aparte de por estos
matices, asumiremos la primera opción por considerarla mayoritaria entre los expertos en seguridad
informática; así, cuando una máquina de la red interna desea comunicarse con el exterior existen
dos posibilidades:
El choke permite la salida de algunos servicios a todas o a parte de las máquinas internas a través
de un simple filtrado de paquetes.
El choke prohibe todo el tráfico entre máquinas de la red interna y el exterior, permitiendo sólo la
salida de ciertos servicios que provienen de la máquina bastión y que han sido autorizados por la
política de seguridad de la organización. Así, estamos obligando a los usuarios a que las conexiones
con el exterior se realicen a través de los servidores proxy situados en el bastión.
La primera aproximación entraña un mayor nivel de complejidad a la hora de configurar las listas de
control de acceso del router, mientras que si elegimos la segunda la dificultad está en configurar los
servidores proxy (recordemos que no todas las aplicaciones soportan bien estos mecanismos) en el
host bastión. Desde el punto de vista de la seguridad es más recomendable la segunda opción, ya
que la probabilidad de dejar escapar tráfico no deseado es menor. Por supuesto, en función de la
política de seguridad que definamos en nuestro entorno, se pueden combinar ambas
aproximaciones, por ejemplo permitiendo el tráfico entre las máquinas internas y el exterior de
ciertos protocolos difíciles de encaminar a través de un proxy o sencillamente que no entrañen
mucho riesgo para nuestra seguridad (típicamente, NTP, DNS...), y obligando para el resto de
servicios a utilizar el host bastión.

La arquitectura screened host puede parecer a primera vista más peligrosa que la basada en una
simple máquina con varias interfaces de red; en primer lugar, tenemos no uno sino dos sistemas
accesibles desde el exterior, por lo que ambos han de ser configurados con las máximas medidas de
seguridad. Además, la mayor complejidad de diseño hace más fácil la presencia de errores que
puedan desembocar en una violación de la política implantada, mientras que con un host con dos
tarjetas nos aseguramos de que únicamente aquellos servicios con un proxy configurado podrán
generar tráfico entre la red externa y la interna (a no ser que por error activemos el IP Forwarding).
Sin embargo, aunque estos problemas son reales, se solventan tomando las precauciones necesarias
a la hora de diseñar e implantar el cortafuegos y definiendo una política de seguridad correcta. De
cualquier forma, en la práctica esta arquitectura de cortafuegos está cada vez más en desuso debido
a que presenta dos puntos únicos de fallo, el choke y el bastión: si un atacante consigue controlar
cualquiera de ellos, tiene acceso a toda la red protegida; por tanto, es más popular, y recomendable,
una arquitectura screened subnet.
Screened Subnet (DMZ)
La arquitectura Screened Subnet, también conocida como red perimétrica o De-Militarized Zone
(DMZ) es con diferencia la más utilizada e implantada hoy en día, ya que añade un nivel de seguridad
en las arquitecturas de cortafuegos situando una subred (DMZ) entre las redes externa e interna,
de forma que se consiguen reducir los efectos de un ataque exitoso al host bastión: como hemos
venido comentando, en los modelos anteriores toda la seguridad se centraba en el bastión, de forma
que si la seguridad del mismo se veía comprometida, la amenaza se extendía automáticamente al
resto de la red. Como la máquina bastión es un objetivo interesante para muchos piratas, la
arquitectura DMZ intenta aislarla en una red perimétrica de forma que un intruso que accede a esta
máquina no consiga un acceso total a la subred protegida.

Screened subnet es la arquitectura más segura, pero también la más compleja; se utilizan dos
routers, denominados exterior e interior, conectados ambos a la red perimétrica como se muestra
en la figura. En esta red perimétrica, que constituye el sistema cortafuegos, se incluye el host bastión
y también se podrían incluir sistemas que requieran un acceso controlado, como baterías de
módems o el servidor de correo, que serán los únicos elementos visibles desde fuera de nuestra
red. El router exterior tiene como misión bloquear el tráfico no deseado en ambos sentidos (hacia
la red perimétrica y hacia la red externa), mientras que el interior hace lo mismo pero con el tráfico
entre la red interna y la perimétrica: así, un atacante habría de romper la seguridad de ambos
routers para acceder a la red protegida; incluso es posible implementar una zona desmilitarizada
con un único router que posea tres o más interfaces de red, pero en este caso si se compromete
este único elemento se rompe toda nuestra seguridad, frente al caso general en que hay que
comprometer ambos, tanto el externo como el interno. También podemos, si necesitamos mayores
niveles de seguridad, definir varias redes perimétricas en serie, situando los servicios que requieran
de menor fiabilidad en las redes más externas: así, el atacante habrá de saltar por todas y cada una
de ellas para acceder a nuestros equipos; evidentemente, si en cada red perimétrica se siguen las
mismas reglas de filtrado, niveles adicionales no proporcionan mayor seguridad.

Figura 15.2: Arquitectura DMZ.

Esta arquitectura de cortafuegos elimina los puntos únicos de fallo presentes en las anteriores: antes
de llegar al bastión (por definición, el sistema más vulnerable) un atacante ha de saltarse las medidas
de seguridad impuestas por el enrutador externo. Si lo consigue, como hemos aislado la máquina
bastión en una subred estamos reduciendo el impacto de un atacante que logre controlarlo, ya que
antes de llegar a la red interna ha de comprometer también al segundo router; en este caso extremo
(si un pirata logra comprometer el segundo router), la arquitectura DMZ no es mejor que un
screened host. Por supuesto, en cualquiera de los tres casos (compromiso del router externo, del
host bastión, o del router interno) las actividades de un pirata pueden violar nuestra seguridad, pero
de forma parcial: por ejemplo, simplemente accediendo al primer enrutador puede aislar toda
nuestra organización del exterior, creando una negación de servicio importante, pero esto suele ser
menos grave que si lograra acceso a la red protegida.

Aunque, como hemos dicho antes, la arquitectura DMZ es la que mayores niveles de seguridad
puede proporcionar, no se trata de la panacea de los cortafuegos. Evidentemente existen problemas
relacionados con este modelo: por ejemplo, se puede utilizar el firewall para que los servicios fiables
pasen directamente sin acceder al bastión, lo que puede dar lugar a un incumplimiento de la política
de la organización. Un segundo problema, quizás más grave, es que la mayor parte de la seguridad
reside en los routers utilizados; como hemos dicho antes las reglas de filtrado sobre estos elementos
pueden ser complicadas de configurar y comprobar, lo que puede dar lugar a errores que abran
importantes brechas de seguridad en nuestro sistema.
Otras arquitecturas
Algo que puede incrementar en gran medida nuestra seguridad y al mismo tiempo facilitar la
administración de los cortafuegos es utilizar un bastión diferente para cada protocolo o servicio en
lugar de uno sólo; sin embargo, esta arquitectura presenta el grave inconveniente de la cantidad de
máquinas necesarias para implementar el firewall, lo que impide que muchas organizaciones la
puedan adoptar. Una variante más barata consistiría en utilizar un único bastión pero servidores
proxy diferentes para cada servicio ofertado.

Cada día es más habitual en todo tipo de organizaciones dividir su red en diferentes subredes; esto
es especialmente aplicable en entornos de I+D o empresas medianas, donde con frecuencia se han
de conectar campus o sucursales separadas geográficamente, edificios o laboratorios diferentes,
etc. En esta situación es recomendable incrementar los niveles de seguridad de las zonas más
comprometidas (por ejemplo, un servidor donde se almacenen expedientes o datos administrativos
del personal) insertando cortafuegos internos entre estas zonas y el resto de la red. Aparte de
incrementar la seguridad, firewalls internos son especialmente recomendables en zonas de la red
desde la que no se permite a priori la conexión con Internet, como laboratorios de prácticas: un
simple PC con Linux o FreeBSD que deniegue cualquier conexión con el exterior del campus va a ser
suficiente para evitar que los usuarios se dediquen a conectar a páginas web o chats desde equipos
no destinados a estos usos. Concretamente en el caso de redes de universidades sería muy
interesante filtrar las conexiones a IRC o a MUDs, ya sea a nivel de aulas o laboratorios o a nivel de
todo el campus, denegando en el router de salida de la red hacia INet cualquier tráfico a los puertos
6667, 8888 y similares; aunque realmente esto no evitaría que todos los usuarios siguieran jugando
desde los equipos de la universidad - por ejemplo a través de un servidor que disponga de conexión
en otros puertos -, sí conseguiría que la mayor parte de ellos dejara de hacerlo.

En las redes TCP/IP el término pasarela con múltiples interfaces de red describe una máquina que
tiene tarjetas múltiples de interfaz de red, donde en general cada tarjeta se conecta a una red.
Si la función de encaminamiento de la pasarela de múltiples interfaces está inhabilitada, la pasarela
o máquina puente puede aislar por completo el tráfico de la red interna y la red externa a la que se
conecta. Se podría tratar de un encaminador apantallado, que opera en el nivel de red y basa sus
actuaciones en el contenido de las cabeceras TCP/IP. Como hemos visto es la forma más rápida,
flexible y barata de cortafuegos, pero también la más vulnerable a ataques y con serias deficiencias
ya presentadas. Por lo tanto, en la actualidad se basa en un ordenador con dos tarjetas o más
tarjetas de red (dual-homed host o multi-homed host) y un software específico llamado proxy que
se encarga de realizar el transvase de información entre ambas aplicaciones. Es decir, aunque la
máquina puente aísle el tráfico entre la red interna e Internet, cada red procesará sus aplicaciones
en la pasarela de dos bases y si las aplicaciones lo permiten, las redes también pueden compartir
datos.

Un servidor o host bastión es un punto de la red crítico en cuanto a seguridad, debido a que si su
seguridad es violada nuestra red puede verse comprometida. Es el punto central para la seguridad
en la red de una organización y, por su función, debe estar muy bien protegido y sometido a
auditorias regularmente. Como en este esquema el servidor bastión coincide con la máquina puente
entre la Intranet e Internet, además de inhabilitar el envío IP, se debe eliminar de la pasarela todos
los programas, útiles y servicios que puedan ser peligrosos en manos de un intruso. Si la máquina
puente falla, la red interna no tendrá defensa ante futuros intrusos (por ejemplo, si el intruso
obtiene suficientes privilegios del sistema, podrá cambiar el valor e la variable ipforwarding y
habilitar el envío IP, con el cual se ignorará el mecanismo del sistema de protección.), a menos que
el problema se detecte y corrija con rapidez.

Cortafuegos con encaminador supervisor

En el esquema visto en primer lugar, puesto que el servidor de bastión es el punto de entrada y de
salida a Internet, red externa no confiable, casi siempre están sujetos a invasiones. Por lo tanto, por
lo general se coloca otra primera línea de defensa entre la red externa no confiable y la interna. Esta
línea la suele proporcionar un encaminador apantallado creándose un área denominada DMZ (De
militarized Zone). En esta área se puede colocar el servidor Web externo, el servidor FTP, y otros
que se estimen oportunos destinados a los usuarios externos.
En este ejemplo, sólo una interfaz de red del servidor bastión está configurada y conectada a la red
interna. Uno de los puertos del encaminador apantallado está conectado a Internet y el otro a la
Intranet. El encaminador apantallado se debe configurar para que envíe primero hacia el servidor
bastión todo el tráfico recibido de Internet hacia la Intranet. Antes de enviar el tráfico hasta el
bastión, el encaminador aplicará sus reglas de filtro en el tráfico del paquete. Sólo el tráfico de red
que pase tales reglas será dirigido hacia el servidor bastión, el resto del tráfico será rechazado. Un
intruso necesita primero penetrar en el encaminador apantallado y, si lo logra, debe enfrentarse
con el servidor bastión. El servidor bastión utiliza funciones a nivel de aplicación para determinar si
las solicitudes hacia y desde Internet se aceptarán o negarán. Si la solicitud pasa el escrutinio del
servidor bastión, se enviará a la red Interna para el tráfico de entrada. Para el tráfico de salida, las
solicitudes se enviarán al encaminador apantallado.

Ejemplo: Cortafuegos con un encaminador supervisor.

Cortafuegos de subred supervisada

Otro tipo de configuración de cortafuegos se tiene creando un segmento de red aislado,
considerado DMZ, que sea la única forma de comunicación entre la Intranet e Internet. A este
segmento se conectan, por un lado, la red interna con los usuarios de la empresa a través de un
encaminador apantallado interno y por otro, también a través de un encaminador, Internet. En este
mismo segmento se encuentra el bastión. Los encaminadores deben estar configurados para
encaminar u recibir el tráfico desde y hasta el servidor bastión.
La organización colocará algunos servidores en la DMZ externa y mantendrá los más delicados
detrás del encaminador interior. Si una empresa quiere proporcionar acceso completo a una gran
variedad de servicios, como FTP anónimo, Gopher y WWW, puede proveer ciertos servidores en la
DMZ exterior. El encaminador apantallado interno no debe confiar en ningún tráfico generado
desde estos servidores.
La utilización de en vez de un segundo encaminador de selección de otro bastión mejora la
seguridad. En general estos esquemas se utilizan en Intranets grandes, dando a cada bastión la
responsabilidad de un grupo administrativo diferente. Esto asegura que los errores de un grupo de
administradores no los repiten el resto de los administradores. Todos los grupos deberán compartir
información acerca de las debilidades descubiertas en los servidores bastión.
Esta arquitectura es la utilizada para filtrar DNS. El CERT (Computer Emergency Response Team)
recomienda filtrar siempre DNS (Domain Name Service) para evitar las transferencias de zonas,
permitiendo el acceso al mismo únicamente a servidores de nombres secundarios conocidos para
no permitir que los intrusos puedan obtener inteligencia relacionada con nuestra red (estructura de
distribución de correo, detalles hardware, versiones de sistemas operativos…). Una forma de limitar
la cantidad de información que es accesible desde el exterior es utilizar dos servidores de nombres
separados por el filtro de paquetes o encaminador apantallado: el servidor externo o aparente
contiene sólo los datos que se quieren hacer visibles a Internet (direcciones de unos pocos
servidores, las pasarelas…) y el interior o real contiene toda la información necesaria para
administrar la Intranet. El servidor aparente y el real son definidos como servidores de dominio,
pero el aparente sólo interacciona con clientes de Internet y el real con los de la Intranet. Cuando
el servidor interno no pueda resolver una petición de un cliente externo, relativa a una dirección
Internet, deberá configurarse para que redirija ésta al servidor externo. El filtro de paquetes tiene
por fin impedir que ninguna petición del exterior llegue al servidor interno (para que nadie pueda
acceder a información local) así como asegurar que los ordenadores internos no puedan solicitar
información si no es a través del servidor interno (para evitar que puedan ser engañados por
servidores ajenos falsos), aunque si debe permitir pasar información entre ambos servidores DNS.
Los clientes internos así sólo pueden obtener información del servidor privado, que contiene toda
la información local necesaria y que obtendrá la información externa del servidor exterior en caso
de necesidad. Los clientes externos, sólo sabrán de la existencia del servidor exterior y sólo podrán
acceder a él, debido al filtro de paquetes. Este servidor sólo proporciona información de que dispone
y al considerarse autorizado terminará toda petición externa, denegando cualquier información
adicional.

Un host bastion es un host de alto riesgo en su red. Puede ser un Linux dedicado ejecutando netfilter
o OpenBSD box ejecutando PF o un dispositivo Cisco PIX. Este dispositivo está diseñado para
proteger su red de amenazas externas.

Por lo general, el host bastion se ubica fuera de su firewall corporativo o en la propia DMZ.
En la mayoría de los casos, tiene acceso desde Internet o partes / computadoras no confiables. En
algunos casos, un host de bastión puede ser un:

Servidor web
Servidor DNS
Servidor FTP
Servidor proxy
Ollas de miel
Servidor de correo electrónico, etc.

Bastion Host y subred filtrada

El host Bastion agrega una capa adicional de seguridad a la arquitectura del host filtrado. Aísla su
red interna de la red. El resultado final es que su host bastion es el objetivo principal de los ataques
de Internet. Si alguien golpea en el host bastion, sus hosts internos están a salvo, ya que el host
bastion está aislado por la red perimetral. La configuración del firewall del host bastion tiene más
seguridad. Por lo general, el seguimiento se realiza en los hosts de bastión:

 El firewall funciona en cerrar todos los puertos y solo abrió el modo de puerto requerido.
 Sistema de detección de intrusiones (IDS / IPS) como snort.
 Configuraciones de seguridad para evitar Denegación de Servicio (DoS), falsificación y
ataques de inundación.
 Someterse a auditoria regular.
 Ejecuta software actualizado.
 Puede ejecutar parches especiales de seguridad del kernel .
 Todas las cuentas de usuario están bloqueadas excepto la cuenta de administrador.
 Cifrado utilizado para el registro (ssh) o almacenamiento en disco.
 Elimine todo el software del usuario final y otros servidores de red como Apache, MySQL,
etc.
 Pila TCP / IP sintonizada para el tráfico de red, incluyendo buffers de red.
 /etc/sysctl.conf personalizado para mejorar la seguridad del servidor
 Por lo general, el host bastión actúa como servidor proxy. Permite y niega la conexión según
lo creado por su política de seguridad.
¿Cómo se construye un Linux como host de Bastion?
Un host de bastión basado en Linux puede construirse usando los siguientes pasos:

 Coge el CD de Debian / CentOS o tu distribución de Linux favorita.

 Instalar el sistema operativo mínimo. Evite instalar software de escritorio u otras
aplicaciones como MySQL, Apache y otro software.
 Reinicie el servidor.
 Servidor de parches .
 Instale el parche del kernel de grsecurity y reinicie el sistema.
 Instale software adicional como snort IDS y configúrelo.
 Instale el software Advanced Intrusion Detection Environment (AIDE).
 Asegúrese de que todos los parches de seguridad estén instalados.
 Deshabilite todos los servicios de red excepto ssh.
 Desactivar todos los demás demonios .
 Ajuste de red vis sysctl.conf
 Configure el firewall (vea la secuencia de comandos de muestra a continuación).
 Elimine la autenticación centralizada como LDAP.
 Elimine tantas utilidades y herramientas de configuración del sistema como sea práctico
para su configuración. No es necesario tener compiladores de gcc y otras herramientas no
deseadas. Use el comando rpm / yum y dpkg para enumerar todos los paquetes.
 Registrar todos los eventos relacionados con la seguridad y activar la auditoría .
 La escritura protege todos los archivos de registro y solo les permite en el modo de solo
agregar mediante el comando chattr (por ejemplo, chattr + a / var / log / messages o chattr
+ i / etc / shadow).
 Cifre todas las contraseñas de la base de datos, incluidos los sistemas de archivos, si es
posible.
 Crear un DVD o cinta de recuperación del sistema.
 Por encima de todo son los pasos genéricos y recomendados para configurar bastion host.

A continuación se muestra un ejemplo de reglas de host de Linux Iptables Bastion

Necesita al menos dos interfaces de red, una conectada a Internet a través de IP pública y otra
privada a su LAN.

#! / bin / sh
# El servidor de seguridad del bastion host para bhost.lan.nixcraft.net.in
# El host bastion también es:
# (a) Servidor de correo para retransmitir el correo a postfix.lan.nixcraft.net.in
# (b ) El servidor DNS envía la transferencia de zona a ns1.lan.nixcraft.net.in y ns2.lan.nixcraft.net.in
# (c) Permitir la entrada de ssh / http / https a bhost.lan.nixcraft.net.in desde LAN SUBNET sothat
# podemos administrar bhost.lan.nixcraft.net.in a través de ssh, y leer estadísticas de snort a través
de la interfaz web de ACID.
# ------------------------------------------------- --------------------------------------------------
### Configurar vars ###
IPT = / sbin / iptables
SYSCTL = / sbin /sysctl
### Establecer interfaces ###
EXT_IF = "eth0" # Internet
LAN_IF = "eth1" # Lan
LOOP_BACK = "lo"

### Bloque de espacio de direcciones privadas RFC 1918 ###

### Bloque reservado Clase D y E IP ###
### Bloquear el rango de direcciones no asignadas et all ###
SPOOFDIP = "127.0.0.0/8 192.168.0.0 / 16 172.16.0.0/12 10.0.0.0/8 169.254.0.0/16 0.0.0.0/8
240.0.0.0/4 255.255.255.255/32 168.254.0.0/16 224.0.0.0/4 240.0.0.0/5 248.0.0.0 / 5 192.0.2.0/24
"

### Configurar Lan Subnet ###

LAN_SUBNET = "192.169.1.0/24"

### Establecer las IP del servidor DNS ###

NS1_SERVER_IP = 192.168.1.130
NS2_SERVER_IP = 192.168.1.131

### Establecer la IP del servidor Postfix ###

SMTP_SERVER_IP = 192.168.1.132

### Establecer números de puerto ###

SSH_PORT = 22
SMTP_PORT = 25
HTTP_PORT = 80
HTTPS_PORT = 443
DNS_PORT = 53

### Limpie el antiguo fw ###

$ IPT -F
$ IPT -X
$ IPT -t nat -F
$ IPT -t nat -X
$ IPT -t mangle -F
$ IPT -t mangle -X
$ IPT -P ENTRADA ACEPTA
$ IPT -P SALIDA ACEPTA
$ IPT -P ADELANTE ACEPTA

### Activar la protección contra inundaciones SYN ###

$ SYSCTL -w net / ipv4 / tcp_syncookies = 1

### Bloquear todo ###

$ IPT -P INPUT DROP
$ IPT -P OUTPUT DROP
$ IPT -P FORWARD DROP

### Permitir acceso completo al bucle invertido ###

$ IPT -A ENTRADA -i $ {LOOP_BACK} -j ACEPTAR
$ IPT -A SALIDA -o $ {LOOP_BACK} -j ACEPTAR

### Bloquee los rangos de espacio de direcciones privadas RFC 1918 ###
para rfc en $ SPOOFDIP
do
$ IPT -A INPUT -i $ {EXT_IF} -s $ {rfc} -j LOG --log-prefix "SPOOF DROP"
$ IPT -A ENTRADA -i $ {EXT_IF} -s $ {rfc} -j DROP
hecho

###
Eliminar cosas malas ### $ IPT -A INPUT -p tcp --tcp-flags SYN, RST SYN, RST -j DROP
$ IPT -A INPUT -p tcp --tcp-flags SYN, FIN, PSH SYN , FIN, PSH -j DROP
$ IPT -A INPUT -p tcp --tcp-flags SYN, FIN, RST SYN, FIN, RST -j DROP
$ IPT -A INPUT -p tcp --tcp-flags SYN, FIN, RST, PSH SYN, FIN, RST, PSH -j DROP
# FIN-Sólo
$ IPT -A ENTRADA -ptcp --tcp-flags FIN FIN -j DROP
$ IPT -A INPUT -p tcp -tcp-flags TODOS TODOS -j DROP
$ IPT -A INPUT -p tcp -tcp-flags TODOS SYN -j DROP
$ IPT - A INPUT -p tcp --tcp-flags ALL FIN, URG, PSH -j DROP
$ IPT -A INPUT -p tcp --tcp-flags ALL SYN, RST, ACK, FIN, URG -j DROP

# FIN
$ IPT -A ENTRADA -p tcp --tcp-flags FIN, ACK FIN -j DROP

# Paquetes
nulos $ IPT -A ENTRADA -p tcp --tcp-flags TODOS NINGUNOS -j DROP

# XMAS
$ IPT -A ENTRADA -p tcp --tcp-flags SYN, FIN SYN, FIN -j DROP

# Fragmentos
$ IPT -A ENTRADA -f -j GOTA

# sync
$ IPT -A INPUT -p tcp ! --syn -m estado --estado NUEVO -j DROP

### Permite al host bastión consultar servidores DNS remotos ###

$ IPT -A INPUT -i $ {EXT_IF} -p udp --dport $ {DNS_PORT} -m estado --estado NUEVO,
ESTABLECIDO -j ACEPTAR
$ IPT -A ENTRADA -i $ {EXT_IF} -p tcp --dport $ {DNS_PORT} -m estado --estado NUEVO,
ESTABLECIDO -j ACEPTAR
$ IPT -A SALIDA -o $ {EXT_IF} -p udp --sport $ { DNS_PORT} -m estado--estado NUEVO,
ESTABLECIDO -j ACEPTAR
$ IPT -A SALIDA -o $ {EXT_IF} -p tcp --sport $ {DNS_PORT} -m estado --estado NUEVO,
ESTABLECIDO -j ACEPTAR
### Permitir DNS interno trasfer es decir, la zona entre el bastión y 2 LAN ns1 y ns2 ###
$ IPT -A ENTRADA -i $ {ext_if} -p udp -s $ {} NS1_SERVER_IP --dport $ {DNS_PORT} -m estado --
state NUEVO, establecida -j ACCEPT
$ IPT -A ENTRADA -i $ {} ext_if -p udp -s $ {} NS2_SERVER_IP dport $ {} DNS_PORT -m estado --
state NEW, ESTABLISHED -j ACCEPT
$ IPT- A ENTRADA-i $ {} ext_if -p TCP -s $ {} NS1_SERVER_IP dport $ {} DNS_PORT -m estado --
state NEW, ESTABLISHED -j ACCEPT
$ IPT -A ENTRADA -i $ {} ext_if -p TCP -s $ {} NS2_SERVER_IP dport $ {} DNS_PORT -m estado --
state NUEVO, establecida -j ACCEPT

### Permitir transferencias salientes de DNS y de zona entre el host bastion y dos 2 LAN ns1 y ns2
###
$ IPT -A SALIDA -o $ {EXT_IF} -p udp -d $ {NS1_SERVER_IP} --sport $ {DNS_PORT} -m estado --
state NUEVO, establecida -j ACCEPT
$ IPT -A OUTPUT -o {} $ ext_if -p udp -d $ {} NS2_SERVER_IP --sport $ {} DNS_PORT -m estado -
-state NEW, ESTABLISHED -j ACEPTAR
$ IPT -A SALIDA -o $ {EXT_IF} -p tcp -d $ {NS1_SERVER_IP} --sport $ {DNS_PORT} -m estado --
estado NUEVO, ESTABLECIDO -j ACEPTAR
$ IPT -A SALIDA -o $ {EXT_IF} -p tcp -d $ {NS2_SERVER_IP} --sport $ {DNS_PORT} -m estado --
estado NUEVO, ESTABLECIDO -j ACEPTAR

### Deje estación de trabajo LAN para entrar en el host de baluarte a través de SSH, pero no tiene
acceso a través de Internet ###
$ IPT -A ENTRADA -i $ {} LAN_IF -p TCP -s $ {} LAN_SUBNET dport $ {} SSH_PORT -m estado --
state NUEVO, establecida -j ACCEPT
$ IPT -A OUTPUT -o $ {} LAN_IF -p TCP -d $ {} LAN_SUBNET --sport $ {} SSH_PORT -m estado --
state ESTABLECIDO -j ACCEPT

### Permitir que la estación de trabajo LAN ingrese al host del bastión a través de HTTP para leer
las cosas de SNORT a través de la interfaz web pero no tiene acceso desde Internet ###
### Leer estadísticas de ACID ###
$ IPT -A INPUT -i $ {LAN_IF} -p TCP -s $ {} LAN_SUBNET dport $ {} HTTP_PORT -m estado --state
NEW, ESTABLISHED -j ACCEPT
$ IPT -A OUTPUT -o $ {} LAN_IF -p TCP -d $ {} LAN_SUBNET - sport $ {HTTP_PORT} -m estado --
estado ESTABLECIDO -j ACEPTAR
$ IPT -A ENTRADA -i $ {} LAN_IF -p TCP -s $ {} LAN_SUBNET dport $ {} HTTPS_PORT -m estado --
state NEW, ESTABLISHED -j ACCEPT
$ IPT -A OUTPUT -o $ {} LAN_IF -p tcp -d $ {LAN_SUBNET} --sport $ {HTTPS_PORT} -m estado --
estado ESTABLECIDO -j ACEPTAR

### Reglas externos SMTP ###

IPT $ -A ENTRADA -i $ {} ext_if -p tcp --dport $ {} SMTP_PORT -m estado --state NUEVO,
ESTABLECIDO - j ACCEPT
$ IPT -A OUTPUT -o $ {EXT_IF} -p tcp --sport $ {SMTP_PORT} -m estado --estado NUEVO,
ESTABLECIDO -j ACEPTAR
### Reglas SMTP internas ###
$ IPT -A INPUT -i $ {LAN_IF} -p tcp -s $ {SMTP_SERVER_IP} --sport $ {SMTP_PORT} -m estado --
estado NUEVO, ESTABLECIDO -j ACEPTAR
$ IPT -A OUTPUT -o $ {} LAN_IF -p TCP -d $ {} SMTP_SERVER_IP dport $ {} SMTP_PORT -m estado
--state NEW, ESTABLISHED -j ACCEPT

### Agrega tus otras reglas debajo de ###

### No finalice la edición debajo de ###

### Conectarse ###

$ IPT -A ENTRADA -m estado --state VÁLIDA -j LOG --log-prefix "INVAID DROP"
$ IPT -A ENTRADA -m estado --state VÁLIDA -j DROP

$ IPT -A ENTRADA -i $ {EXT_IF} -j LOG --log -logix "INPUT DROP"

$ IPT -A SALIDA -o $ {EXT_IF} -j LOG --log -log "OUTPUT DROP"

Webgrafía:
https://www.quora.com/Are-jump-servers-the-same-thing-as-bastion-hosts
https://docs.aws.amazon.com/es_es/quickstart/latest/linux-bastion/architecture.html
https://www.rediris.es/cert/doc/unixsec/node23.html
https://www.ramonmillan.com/tutoriales/cortafuegos_parte2.php
https://community.cisco.com/t5/vpn-and-anyconnect/why-is-logging-important-on-a-bastion-
host/td-p/598559
https://blog.scottlowe.org/2015/11/21/using-ssh-bastion-host/
https://www.cyberciti.biz/faq/linux-bastion-host/