¿Los protocolos de conmutación son una medida de seguridad que vale la pena implementar?

Question

¿Los protocolos de conmutación son una medida de seguridad que vale la pena implementar?

#1 de Steffen Ullrich (5 votos)
#2 de IGotAHeadache (0 votos)

3

Implementamos nuestras aplicaciones de Internet en múltiples vlans y hay una regla que dice que hablar de una vlan a la siguiente debe hacerse en otro protocolo o en otra implementación del protocolo.

Por ejemplo,

[Internet] --https-> [apache@VLAN1] --ajp--> [tomcat@VLAN2] --jdbc--> [pgsql@VLAN3]

Vs.

[Internet] --https-> [apache@VLAN1] --https--> [apache@VLAN2] --https--> [apache@VLAN3]

Vs.

[Internet] --https-> [apache@VLAN1] --https--> [tomcat@VLAN2] --https--> [nginx@VLAN3]

El motivo es que si hay una vulnerabilidad en una de las implementaciones de protocolo, no puede utilizar la misma vulnerabilidad para ingresar al host en la próxima VLAN.

Esto a veces es difícil de lograr si todos los servicios proporcionan API REST.

¿Hay alguna literatura donde pueda leer sobre esto? O enfoques que logran la misma protección.

http rest vlans

pregunta n3utrino 17.04.2018 - 16:29

fuente

2 respuestas

Lea otras preguntas en las etiquetas http rest vlans

Certificaciones de desarrollador de AppSec ¿Puede la verificación de los encabezados HTTP proteger contra CSRF? [duplicar]

score 5 · Answer 1

Los protocolos de conmutación que usted describe requieren esencialmente analizar la sintaxis y la semántica de los datos transferidos para traducir los datos a un nuevo protocolo. También significa que debe tener una semántica claramente definida en primer lugar. Tener una semántica claramente definida ya puede mejorar la seguridad. Y el hecho de que esta semántica se aplique implícitamente cuando se traducen los datos a un nuevo protocolo también reduce la capacidad de un atacante para explotar al destinatario.

La definición y el cumplimiento de la semántica también se podrían hacer sin traducir a un nuevo protocolo. Pero para traducirlo a un protocolo diferente. se necesita una definición más estricta de sintaxis y semántica y es más difícil hacer atajos para omitir algunas comprobaciones. En la medida en que requiera un cambio de protocolo es una buena idea para asegurarse de que los desarrolladores realmente sepan cómo deben ser los datos en primer lugar y que también lo hagan cumplir.

Por supuesto, esto solo funciona si hay una traducción real necesaria. En su ejemplo, este sería el caso entre HTTP y JDBC, pero no entre HTTPS y HTTP. Dado que HTTPS es solo HTTP sobre TLS y sería suficiente para eliminar la capa TLS en lugar de aplicar la semántica de protocolo.

score 0 · Answer 2

Esto pretende ser un comentario. Me gustaría poder comentar (aún no del todo), pero en base a el ejemplo anterior , diría que no parece haber muchos beneficios al pasar de un protocolo cifrado (https) a otro protocolo de texto simple (http) dentro de su red a uno (posiblemente) sin cifrar (jdbc). Que está encriptado para empezar si es bueno! jajaja Y no siempre es posible forzar protocolos. Puede estar atascado con JDBC.

Pero si rompen cualquier parte de la cadena alimenticia allí, obtienen los datos, incluso si cada segmento está cifrado de manera diferente, como si, cuando tienes VLAN1, en realidad es un equilibrador de carga que realiza la descarga de SSL y la conexión aún es HTTPS a VLAN2, pero diferentes claves y sesión SSL, luego se encriptan desde el nivel de la aplicación con un JDBC seguro (que desde el nivel de la Aplicación probablemente no sea una gran cantidad de protocolos).

De extremo a extremo cifrado, sí. Siempre deseable, pero me pregunto si eso es lo que querían decir.

[Internet] - descarga de http: > [VLAN1] --https nueva sesión - > [VLAN2] --secure jdbc - > [VLAN3]

Eso detendría a mitm.