☰

Cómo configurar la lista de control de acceso a la red de AWS para SSH en una subred privada

tag-icon • tag-icon ssh amazon-web-services access-control-list amazon-vpc
Cómo configurar la lista de control de acceso a la red de AWS para SSH en una subred privada

Estoy haciendo un curso sobre AWS. Lo que intento hacer es configurar una VPC con dos servidores Linux. Configuré la VPC con dos subredes. He puesto un servidor en cada uno. La idea es que una subred sea pública y la otra sea privada.

Creé dos ACL de red y asocié una con cada subred.

Puedo SSH desde mi máquina al servidor en la subred pública. Cuando intento realizar SSH desde allí al servidor en mi subred privada, se agota el tiempo de espera de la conexión.

No estoy seguro de qué reglas necesito establecer en mis dos ACL de red para que SSH funcione. ¿Alguien puede ayudar? Dado que estoy aprendiendo, agradecería una explicación de por qué deberían ser las reglas, no solo cuáles deberían ser.

Tengo una VPC llamada MyVPC con CIDR 10.0.0.0/16
Mi primera subred se llama MyVPCSub1 CIDR 10.0.1.0/24
Mi segunda subred se llama MyVPCSub2 CIDR 10.0.2.0/24
Tengo una tabla de rutas llamada MyInternetRoute asociada con las rutas MyVPCSub1 son:

|Dest        |Targ  |  
|10.0.0.0/16 |local |
|0.0.0.0/0   |igw   |

Tengo una tabla de rutas llamada MyPrivate asociada con MyVPCSub2. Las rutas son:

|Dest        |Targ  |
|10.0.0.0/16 |local |

Tengo una ACL de Red llamada MyWeb asociada a MyVPCSub1 con reglas:

Entrante:

| #   | Type | Protocol | Ports | Source     | A/D
| 99  | HTTP | TCP      | 80    | {My IP}/32 | D
| 100 | HTTP | TCP      | 80    | 0.0.0.0/0  | A
| 200 | HTTPS| TCP      | 443   | 0.0.0.0/0  | A
| 300 | SSH  | TCP      | 22    | {My IP}/32 | A
| *   | ALL  | ALL      | ALL   | 0.0.0.0/0  | D

Saliente:

| #   | Type   | Protocol | Ports      | Source     | A/D
| 50  | ALL    | ALL      | ALL        | 0.0.0.0/0  | A
| 100 | HTTP   | TCP      | 80         | 0.0.0.0/0  | A
| 200 | HTTPS  | TCP      | 443        | 0.0.0.0/0  | A
| 300 | Custom | TCP      | 1024-65535 | 0.0.0.0/32 | A
| *   | ALL    | ALL      | ALL        | 0.0.0.0/0  | D

Tengo una ACL de red llamada MyPrivate asociada a MyVPCSub2 con reglas:

Entrante:

| #   | Type | Protocol | Ports | Source    | A/D
| 100 | ALL  | ALL      | ALL   | 0.0.0.0/0 | A
| *   | ALL  | ALL      | ALL   | 0.0.0.0/0 | D

Saliente:

| #   | Type | Protocol | Ports | Source    | A/D
| 100 | ALL  | ALL      | ALL   | 0.0.0.0/0 | A
| *   | ALL  | ALL      | ALL   | 0.0.0.0/0 | D

Respuesta1

Lo primero es definir qué significan algunos de los términos.

NACLS - Listas de control de acceso a la red, son un estado-menosfiltro de paquetes aplicado a nivel de subred. Es importante tener en cuenta el aspecto "sin estado", esto significa que debe ser explícito para todo el tráfico que entra y sale de la subred. Por ejemplo, con un enfoque de regla de "estado completo" (que es lo que aplica el grupo de seguridad en AWS), simplemente puede especificar el tráfico entrante de TCP/22 para SSH y automáticamente permitirá el tráfico saliente. Con NACLS este no es el caso; deberá especificar una regla en cada dirección para permitir el paso del tráfico.

Grupos de seguridad - estos son grupos de estado-llenoreglas que se pueden aplicar a una o más instancias en una VPC. Tenga en cuenta que se aplican a nivel de instancia. El grupo de seguridad se puede comparar con un firewall tradicional de estado completo, pero debido a que se aplica a nivel de instancia individual, puede segregar instancias entre sí incluso dentro de la misma subred, lo cual es bueno. Y debido a que tienen estado completo, si desea permitir el tráfico hacia un servidor (por ejemplo, TCP/22 para SSH), no tiene que preocuparse por crear una regla de salida correspondiente, la plataforma se encarga de eso automáticamente, por lo que son mucho más fáciles de gestionar, lo que también significa menos posibilidades de error.

Hay una bonita tabla que compara estos dos:Comparación de seguridad de VPC

También hay un bonito diagrama en esa página que muestra el orden de las cosas que se aplican al tráfico dependiendo de la dirección del flujo... así que compruébalo.

Luego en términos de subredes tenemos:

Subred pública: en términos de AWS, es simplemente una subred que tiene una tabla de rutas adjunta que tiene una ruta 0.0.0.0/0 a través de una puerta de enlace de Internet adjunta.

Subred privada: esto es lo contrario, es decirnotener una ruta 0.0.0.0/0 a través de una puerta de enlace de Internet adjunta. Tenga en cuenta que aún puede tener una ruta 0.0.0.0/0 a través de una puerta de enlace NAT o un proxy similar en su entorno, pero no directamente.

La pregunta es, cuando tienes NACLS y grupos de seguridad, ¿cuáles usas? AWS describe las NACL como una "capa de seguridad opcional para su VPC". Y es cierto que en general los Grupos de Seguridad son suficientes, son más flexibles y brindan la misma protección. Sin embargo, en mi experiencia, hay algunos casos típicos en los que veo que se utiliza NACLS:

  1. Agujeros negros para malos actores conocidos: si ha sido atacado desde un rango de IP en particular, es un enfoque fácil simplemente agregar una NACL que bloquee la fuente de IP/subred por completo.
  2. Como forma de delegar el control a los equipos, el equipo de seguridad aplica configuraciones NACL generales (por ejemplo, solo permite el tráfico de redes corporativas confiables) y luego permite que los equipos de operaciones y desarrollo configuren sus propias reglas de grupo de seguridad. De esa manera, incluso si el ingeniero intenta abrir el grupo de seguridad de su instancia a Internet para realizar pruebas, la NACL lo bloqueará. Puede usar IAM para restringir quién puede modificar las NACL, pero otorgar acceso a los equipos para controlar todo lo demás; actúa como un excelente respaldo para errores de configuración en entornos más grandes.

AWS también proporciona orientación sobre una serie de escenarios de configuración disponibles aquí:Reglas ACL de red recomendadas para su VPC

Sin embargo, mi consejo es que los grupos de seguridad proporcionen una protección adecuada, sean más fáciles de entender y configurar y sean más flexibles y granulares en su aplicación. Las NACL le brindan ese respaldo adicional para errores humanos o configuraciones más avanzadas, pero para uso básico no se usan normalmente. Por lo tanto, supongo que AWS se refiere a ellos como "opcionales".

Dejaría las NACL en su configuración predeterminada (permitiría todo el tráfico de entrada y salida) y, por ahora, me centraría en los grupos de seguridad, ya que usar las NACL como segunda capa solo agregará una capa adicional de complejidad que tal vez no sea necesaria en su escenario. Desde una perspectiva de aprendizaje, es bueno saber que están ahí, que no tienen estado, que se aplican a nivel de subred y se aplican después de la decisión de enrutamiento y antes de los grupos de seguridad en el tráfico que ingresa a una subred.

En lo que respecta a su situación específica, debido a que está utilizando NACL, debe recordar que son estatales.menos. Por lo tanto, es necesario tener en cuenta todos los flujos de tráfico que entran y salen de la subred: la razón principal por la que los grupos de seguridad son mucho más sencillos. Entonces en tu caso tienes:

  • Tráfico a su servidor público en TCP/22 desde su IP - sí - regla #300 entrante
  • Tráfico de retorno desde su servidor público en un puerto alto para el tráfico SSH de retorno - sí - regla #50 saliente (pero no regla #300 - ver más abajo)
  • Tráfico desde su subred pública saliente a su subred privada en TCP/22 - sí - regla #50 saliente
  • Tráfico entrante en la subred privada desde la pública - sí - regla #100 entrante
  • Devuelve el tráfico desde tu servidor privado al servidor público en la subred privada - sí - regla #100 saliente
  • Devuelve el tráfico de tu servidor privado al servidor público en elpúblicosubred - ah - no, no existe ninguna regla que permita el puerto alto (el puerto efímero que el cliente ssh está usando en el servidor público para iniciar la conexión al privado) nuevamente desde el servidor privado.

Debe agregar una regla como la regla n.° 300 (pero tenga en cuenta que ha formateado la IP de origen ligeramente incorrectamente; consulte a continuación) en su ACL de subred pública saliente, pero vinculada, con una fuente de la subred privada. Luego, suponiendo que sus grupos de seguridad estén bien configurados, debería estar listo para comenzar.

Espero que ayude.

Para agregar, según la otra respuesta, la regla n.° 300 en el conjunto de reglas de salida de la subred pública tiene un formato incorrecto. Debería ser 0.0.0.0/0 y no 0.0.0.0/32; sin embargo, en su caso no estaba cumpliendo con eso, ya que la regla n.° 50 se aplica primero y permite todo el tráfico de todos modos, por lo que, si bien no funcionaría, sí. En realidad no está causando tu problema.

Respuesta2

Las ACL no tienen estado.

Su subred "pública" probablemente esté bloqueando la ruta de retorno de su conexión SSH desde la subred privada. También necesita una regla equivalente a su salida para todos los puertos en el lado entrante, aunque podría restringirla al rango de subred 10.0.2.0/24.

Editado para agregar: Además, la regla de salida para 0.0.0.0/32 es simplemente incorrecta. A menos que su IP sea exactamente 0.0.0.0, no funcionará.

información relacionada