Bloqueo las conexiones desde AWS hacia mi servicio on-premises
(consulting.m3047.net)- La Internet pública podría dividirse en un ecosistema fragmentado centrado en los grandes proveedores de nube, y el bloqueo del acceso desde AWS hacia sistemas on-premises muestra un caso operativo de esa tendencia
- El bloqueo apunta principalmente a los intentos de conexión TCP que clientes dentro de AWS abren hacia servicios on-premises, mientras que las conexiones salientes desde clientes locales hacia servicios alojados en AWS siguen siendo posibles
- Los servicios on-premises en operación son web, una demo de Trualias, DNS y SMTP; DNS ofrece UDP, fallback por TCP y acceso público limitado a telemetría de seguridad
- El bloqueo de AWS comenzó como respuesta al tráfico excesivo de ping y a crawlers/scanners abusivos, y actualmente se administran 53 CIDR de espacio de direcciones de AWS observados como objetivo o fuente de abuso
- Si los grandes proveedores de nube no publican mejor información forense como reverse DNS, whois, namespace DNS y patrones de abuso, la fragmentación podría fortalecerse sin que los usuarios dentro de la nube casi lo noten
La posibilidad de fragmentación creada por las grandes nubes
- Si los grandes proveedores de nube se vuelven una bulletproof infrastructure “too big to fail”, podrían causar directamente la fragmentación de Internet
- Aún no es un fenómeno completamente materializado, pero se considera algo que ya comenzó o que podría aparecer pronto
- El ecosistema cloud-native tiene una infraestructura a medida en comparación con Internet real, y cada servicio cloud se organiza en torno a capacidades diferenciadas más que a una arquitectura común
- Muchos servicios operan de forma autocontenida dentro de una nube específica, y existen barreras para la interoperabilidad transparente con la Internet general
- La comunidad cloud-native trata a la Internet general como si fuera un recurso externo y se relaciona más con el ecosistema de un proveedor de nube específico que con la propia Internet
La comercialización de la Internet pública
- Antes de 1989, Internet no tenía acceso público general y era una red de carácter privado usada por entidades gubernamentales, militares, de investigación y educativas
- La NSF administraba el núcleo del backbone, y el acceso público inicial se permitía bajo la condición de tráfico no comercial
- No es que los servicios comerciales estuvieran prohibidos por sí mismos, pero el tráfico que cruzaba el backbone de NSFNet no debía ser tráfico de publicidad ni de servicios pagados
- Los operadores comerciales construyeron una Internet comercial separada, y en 1995 NSFNet desactivó el acceso público
- Tras la gran depuración alrededor del año 2000, sobrevivieron los modelos basados en publicidad sustentada por datos de comportamiento y en la venta de esos datos de comportamiento de usuarios
- En la ola actual de IA, destaca la recolección masiva y el lavado de contenido accesible para usarlo en entrenamiento de modelos; la curación y el entrenamiento ocurren sobre todo en la nube, y cada vez más por los propios proveedores de nube
Bloqueo de conexiones desde AWS hacia servicios on-premises
- Se está deshabilitando la mayor parte del acceso entrante desde AWS hacia servidores on-premises
- Técnicamente, el interés está principalmente en el tráfico TCP, ya que el handshake inicial permite distinguir entre cliente y servidor
- Se bloquean los intentos de conexión de clientes dentro de AWS hacia servicios on-premises
- Sí se permite que clientes de la red local se conecten a servicios alojados en AWS
- Se operan localmente varios servicios expuestos a Internet
- Servicio web
- Demo de Trualias
- Servidor DNS
- Servidor de correo SMTP
- Durante años se ha mantenido una política de no crawl, y los recursos ofrecidos están dirigidos principalmente a usuarios individuales en Internet
- El servidor DNS usa UDP y fallback por TCP, y ofrece telemetría pública de seguridad limitada
- Consulta de ejemplo:
dig @131.191.85.30 'fail2ban;*.keys.redis.athena.m3047' txt - También puede ser útil para servicios que corren en la nube, pero si alguien va a depender de él en operación, se espera que primero se ponga en contacto
- Consulta de ejemplo:
reverse DNS y la excepción de SMTP
- Si el problema fuera solo el servicio web, podrían usarse otras mitigaciones, como consultas de reverse DNS
- Los proveedores de nube a menudo gestionan mal el reverse DNS, lo que encaja con la narrativa de que los recursos dentro de la nube son temporales
- AWS lo hace mejor que muchos otros proveedores de nube, y se ha oído que permite configurar el reverse DNS de una instancia, aunque no se ha probado directamente
- Se hace una excepción para SMTP
- Salvo que haya problemas particularmente graves, aunque se bloquee la conexión a otros servicios, se permite la conexión a servidores de correo
- Técnicamente se puede operar SMTP sin reverse DNS correcto, pero en la práctica, si no existe un reverse DNS correcto, el otro lado no aceptará el correo
- Evaluar el reverse DNS permite una valoración inicial sobre si el SYN vino de un servidor de correo legítimo
- Los servicios de reputación pueden puntuar el reverse DNS
- Existen patrones comunes en recursos alquilados y temporales
- Solo por la presencia o forma del reverse DNS ya se puede estimar razonablemente si una dirección pertenece a un proveedor de nube
Por qué empezó el bloqueo de direcciones de AWS
- Comenzó con el bloqueo de netblocks identificables de algunos servicios abusivos y luego evolucionó hacia una prueba de concepto de bloqueo selectivo de pequeños hosters
- En el caso de AWS, el punto de partida fue el tráfico excesivo de ping
- El ping usa un protocolo sin conexión, por lo que se puede falsificar el origen
- Las respuestas a solicitudes de ping falsificadas no van al atacante, sino a la ubicación real falsificada
- Para suprimir respuestas de ping constantes, hay que generar reglas temporales de firewall, pero la escala de Amazon hace que el número de reglas crezca mucho
- Se empezó a recopilar rangos de direcciones de AWS, y actualmente se tienen 53 CIDR que representan espacios de direcciones de AWS observados como objetivo de abuso o como fuente de abuso
- A veces también se observan reglas temporales de firewall que duplican esa cantidad
- Bloquear crawlers y scanners abusivos alquilados en proveedores cloud “too big to fail” es un buen efecto secundario, y no se les extraña si desaparecen de los logs web
Impacto para los usuarios de la nube
- La mayoría de los recursos populares o que probablemente se desplieguen en la nube están alojados en GitHub
- Quienes despliegan otros recursos en la nube tienen que mantener su propio repositorio para staging
- Si el repositorio está en AWS, ya no será posible comprobar actualizaciones
- Habrá que hacerlo desde un escritorio
- Habrá que hacerlo desde un recurso alojado de forma privada
- Se puede conversar un arreglo por separado
- Tener solo un smartphone, un bucket de S3 y una instancia EC2 difícilmente puede considerarse “estar en Internet”, aunque desde un smartphone sí debería poder accederse a esos recursos
Mitigación del robo de datos y usos no intencionados
- El robo de datos, en el que materiales de código abierto se reutilizan sin permiso para fines no previstos, es otra amenaza que requiere mitigaciones propias
- El bloqueo a AWS también funciona como una de esas mitigaciones
- Los materiales sobre cats, bunnies y birds también aparecen en ese contexto de mitigación
- cats y bunnies aparecen porque hay muchísimo video relacionado con ellos y parte de ese material se puede comprar
- birds es más efectivo en la capa 2 del modelo OSI, y está documentado en un RFC como método de transporte de datagramas IP
Información pública necesaria por parte de los grandes proveedores de nube
- Los grandes proveedores de nube deberían ofrecer un sistema de distribución de información forense mejor que el actual
- DNS y whois pueden ser herramientas para distribuir información potencialmente útil
- Un proveedor grande debería ser capaz de operar su propio reverse DNS
- Podría hacer falta whois por dirección individual, información adicional codificada en reverse DNS e información pública separada dentro del namespace DNS
- Un storm center blog que trate patrones actuales de abuso y bloques de direcciones afectados también sería una opción posible
- En SMTP, además del reverse DNS, existe SPF, publicado mediante registros DNS TXT
- Debería ser posible encontrar, a partir de una sola dirección IP, información que responda a estas preguntas
- si el recurso detrás de esa dirección envía ping
- cuánto ping envía
- si crea conexiones TCP salientes
- a qué servicios se conecta
- quién controla el recurso
- si el recurso está siendo atacado
- qué tipo de ataque es
- qué mitigaciones quisieran que ofrecieran otros recursos en Internet
- La mitigación adecuada beneficia a todos, pero una mitigación mal dirigida no
Consecuencias de una Internet fragmentada
- Si este enfoque se expande, podría llevar a una balkanized internet
- Las personas que viven su vida en línea dentro de la burbuja de los grandes proveedores de nube podrían no notar la mayor parte de las molestias
- Incluso las molestias que sí perciban podrían atribuirlas al hecho de haber elegido un proveedor de nube específico
1 comentarios
Opiniones de Hacker News
Todos los principales proveedores de nube publican listas de rangos de IP legibles por máquina
Ej.: https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-rang...
https://www.microsoft.com/en-us/download/details.aspx?id=565...
https://support.google.com/a/answer/10026322?product_name=Un... etc.
No pienso jugar a algo como “probemos bloquear la enorme lista JSON de Amazon”, y solo tengo 53 reglas. Puedo aceptar cierto nivel de efectos secundarios, y los sitios que están en AWS también cargan bien
Hoy en día, en Internet, la velocidad con la que aparece tráfico agresivo apenas publicas infraestructura es una locura
Hace poco anuncié por BGP una subred /23 para una configuración anycast, y apenas se levantó la ruta y empezó a fluir tráfico hacia el router, tcpdump se desbordó con escaneos de puertos a todas las IP del rango
Claro que no fue por la ruta en sí; parece que muchas entidades escanean todos los rangos de IP de forma indiscriminada y permanente. Este rango no se había anunciado durante años, así que tampoco estaba en la lista de servidores activos de alguien
Me sorprende que servicios web internos como GitLab todavía se expongan tal cual a Internet. Como mínimo, creo que debería haber una capa adicional de protección, como una VPN, para que el servicio no pueda descubrirse desde Internet pública
Lo único accesible públicamente es el SSH de un único host bastión, y más adelante también quisiera eliminarlo poniéndole encima una capa de VPN
Así como en el espacio hay radiación de fondo, en Internet existe la radiación de fondo de Internet. Si no ejecutas servicios vulnerables, estos escaneos de puertos implican un riesgo similar al de comerte una banana extra al mes
Solo molesta porque lo estás viendo directamente en la consola. Es como subirte a un avión con un contador Geiger demasiado sensible: puede asustarte, pero si no lo supieras, no te haría daño
A mí también me sorprende exponer servicios internos a Internet, por dos motivos: no confío en los sistemas de autenticación de la mayoría de los programas, y no quiero que desde afuera se sepa qué servicios internos uso. También hay razones más cercanas a la privacidad que a la seguridad técnica pura
En cambio, las cosas que deben estar en Internet y que creo que tienen una puerta principal sólida o están suficientemente aisladas en sandbox pueden quedarse en Internet todo el día
Un escaneo de puertos es la versión de Internet de caminar por una ciudad anotando qué casas tienen la luz encendida. Puede ser un poco acosador, pero es información pública
Como referencia,
ssh -wcrea una interfaz de túnel VPN, pero no configura automáticamente el resto como lo haría un producto VPN realInternet se siente cada vez más como lo que ocurre detrás del blackwall de Cyberpunk
Si activabas los logs de accesos denegados del firewall, entraban permanentemente intentos a puertos conocidos y desconocidos
Si expones algo, incluso un componente web escondido en lo profundo, debes asegurarte de que no se convierta en una puerta de entrada a tus datos e infraestructura
Lo que cambió un poco desde entonces es el origen del tráfico y los criterios para decidir si aceptarlo o bloquearlo. Aumentaron mucho los servidores y servicios legítimos, los proxies del lado de usuarios finales, los proveedores de nube y la cantidad de crawlers
Es una verdadera lástima. Hacer eso implica el riesgo de que su contenido no aparezca en absoluto en los motores de búsqueda, que Marginalia tampoco lo detecte y que tampoco se guarde en Wayback Machine
Si eso es lo que realmente quiere, quizá tenga sentido bloquear todas las nubes y centros de datos. Incluso podría terminar bloqueando a usuarios de algún ISP pequeño, dependiendo de dónde opere ese ISP sus gateways CGNAT. Es poco probable, pero no imposible
Lo único que parece mencionarse en el artículo como abuso real son pings con dirección de origen falsificada. No se puede saber si esos paquetes de ping falsificados vinieron de AWS, porque la dirección de origen es la dirección a la que el falsificador quiere que se envíe la respuesta, no la dirección del falsificador
Una mitigación mucho menos invasiva sería aplicar limitación de velocidad a los pings, a unos 10 por segundo
Internet sí se está balcanizando, pero la causa principal no es tanto el bloqueo de rangos IP, sino la siloización de las redes sociales para obtener ingresos de publicidad y datos, y la tendencia a extraer valor de los datos de entrenamiento de IA. Casos como el acuerdo exclusivo Reddit/Google se acercan más a eso
Me cuesta entender la mentalidad de quejarse de que la conectividad IP se balcaniza mientras se bloquea a un proveedor específico por unos cuantos pings. Quien crea la balcanización es quien bloquea
Hace bastante que no veo blogs personales o pequeños sitios de hobby en los resultados de búsqueda
Si necesito Wikipedia o Stack Overflow, puedo buscar directamente en esos sitios. Ojalá hubiera una opción para excluir a los “candidatos de siempre” y ver contenido de cola más larga
Aun así, el tono general se siente más bien como convertir una picadura de mosquito en una gran narrativa histórica
Operar un gateway CGNAT en la nube traería muchos problemas. Como los suscriptores ya no tendrían IP residenciales, quizá no podrían ver servicios como Netflix, y también es muy probable que se topen más seguido con CAPTCHA antibots de Cloudflare o Google
Me pregunto si hay casos reales conocidos
Hetzner, DigitalOcean, Linode, OVH y Contabo llevan un tiempo bloqueados
Se puede hacer con bloqueo por ASN en pfBlocker NG, y también con reglas de UFW: https://blog.abctaylor.com/ufw-and-firewalld-rules-to-block-...
Por ejemplo, si una organización opera por su cuenta WireGuard u otra solución VPN sobre un proveedor cloud, y la gente se conecta a través de eso, la IP saliente se verá como una IP del proveedor cloud
Incluso se podría automatizar. Así sería justo y cada parte sabría qué está pasando. Si no, en lugar de estos jueguitos de arenero, que usen armas de verdad
Lo primero que pensé fue que podrían quedar bloqueados escritorios reales que corren en AWS, en particular servicios como Amazon Workspaces
Sin embargo, parece que el espacio IP de esos servicios también está documentado públicamente, así que, si hace falta, se podrían permitir esas IP por separado
Aun así, usando un proxy o una VPN es muy fácil evadir este tipo de bloqueo
Hace mucho tiempo, decenas de servidores de Amazon empezaron a ralentizar nuestros servidores on-premise, así que hicimos esto
Quizá era algún intento de SSO o algo parecido, pero nunca logramos rastrearlo por completo. Simplemente escribimos un script que descargaba periódicamente la lista de rangos IP de Amazon y los bloqueaba todos, y seguimos adelante
Lo entiendo. Si quisiera levantar un muro alrededor de grandes zonas de Internet para algo que construí, haría lo mismo. No es muy distinto de bloquear países enteros
También entiendo el deseo de reducir el ruido y permitir solo a un “pequeño grupo de amigos”
Pero yo lo hago solo para servicios específicos, no para todo un dominio. Mi servidor Mumble está abierto solo a los 3 o 4 países donde están mis amigos y excluye proveedores cloud. Mi blog técnico lo dejo visible para cualquiera en el mundo
Estoy firmemente del lado de que el conocimiento compartido beneficia a todos. Si mis notas sobre la cadena de inicialización de módem para un módem C64 de 300 baudios ayudan aunque sea a una sola persona, esa persona no repetirá el sufrimiento que yo pasé y el mundo será un poco mejor
Entiendo que ese deseo surja por muchas razones. Está bien. Que cada quien haga lo suyo
Amazon es demasiado grande como para ignorarlo. Entiendo que mucho del tráfico ICMP y SYN es basura. Yo también quiero ayudar a bloquearlo y, de hecho, tengo mitigaciones básicas preparadas
El problema es que Amazon toca mis mitigaciones “a escala”, y eso lo vuelve un dolor de cabeza. Amazon no ayuda a separar la paja del trigo. Es del tipo “envíenos un PCAP sobre el problema de los pings”
Si le envío datos a Amazon y no recibo ninguna respuesta, no tengo nada que aprender. No necesito el tráfico bueno ni el malo, ni tampoco el tráfico falsificado que los ataca
Si no van a ayudarme a ayudarlos, no necesito nada de ellos. Simplemente estoy manteniendo mi vida sencilla
Ver cosas así me hace extrañar la vieja internet. Es muy difícil explicar lo genial que era internet antes de la comercialización.
La amarga satisfacción de haber acertado exactamente que este sería el resultado no compensa en absoluto lo que se perdió.
AWS es casi como un boy scout en comparación con DigitalOcean, OVHcloud, ColoCrossing, Scaleway, Tencent e incluso Google.
En especial, creo que DigitalOcean cometió un error terrible al hacer marketing dirigido a la comunidad de “ciberseguridad”.
Declaración de conflicto de intereses: AWS es mi empleador actual.
Quizás me estoy perdiendo algo obvio, pero si el autor cree que el tráfico de ping fue falsificado, ¿cómo sabe que el origen es AWS?
Por experiencia, he visto demasiados casos en los que una cantidad abrumadora de tráfico venía de AWS, y en algunos casos se llegó a la misma solución: bloquear todo AWS.
No sé si a AWS no le importa o si responde lento. Tal vez reportarlo sea demasiado difícil.
Lo obvio que te estás perdiendo es esto: AWS es una fuente enorme de tráfico “malo”, y es demasiado difícil suspender a clientes que funcionan mal, mientras que para actores maliciosos es demasiado fácil alquilar capacidades absurdas.
Casi nunca he visto que GCP o Azure sean fuentes del mismo nivel de tráfico disparatado.