Transmisión indirecta del servidor de intranet al mundo exterior

3

Tengo una red interna de cámaras de red IP. Las fuentes de estas cámaras son ingeridas por un solo servidor y presentadas desde una interfaz web unificada tanto internamente como hacia el mundo exterior (ambas después de la revisión de la contraseña).

Hay dos capas de protección, una bastante simple en la barrera de la WAN que designa un segundo enrutador como DMZ (aún limitada). El primero tiene algunos controles básicos en función del tipo de tráfico, que detecta las exploraciones de puertos y los intentos de DoS. Si bien se permite un rango de puertos, se prohíben los claves no deseados y se excluyen explícitamente los puertos que las cámaras están configuradas para usar para la comunicación. El segundo enrutador (que maneja el tráfico interno y su conexión con el mundo exterior) se asigna a servidores internos específicos con tráfico no intencional bloqueado allí. Las cámaras de red pueden verse y controlarse desde la interfaz web dentro de lo razonable: hay una serie de ubicaciones predeterminadas y configuraciones de escaneo para cada una. Para comunicarse directamente con cualquiera de las cámaras se requeriría piratear cada uno de los enrutadores, y están configurados para permitir solo los inicios de sesión desde la red interna.

Las cámaras contienen su propio servidor y servicios http, y el servidor al que accedo desde el exterior se conecta a esas cámaras y transmite imágenes, flujos de archivos jpeg, etc. al mundo exterior. Quiero poder proporcionar opcionalmente un servicio de retransmisión a las interfaces de administración de esas cámaras sin proporcionar directamente enrutamiento a esas cámaras desde el mundo exterior (simplemente porque puedo controlar qué software está en el host de retransmisión pero tengo relativamente poco control sobre el firmware de la cámara) . Hay una variedad de funciones administrativas de las cámaras (control por infrarrojos, cambio de ángulos preestablecidos, etc.) que preferiría evitar tener que escribir interfaces alternativas y me gustaría poder proporcionar sus interfaces a través de un relé que podría monitorear y El filtro debe aprovecharse para que las cámaras se conozcan. Sobre todo, me preocupa que, dado que las cámaras en sí son servidores web bastante sofisticados, que, si se revelan directamente al exterior, podrían desplegar la alfombra de bienvenida para interferir en la red interna. He hecho mucho para limitar mi exposición (y así, permítame concentrar mis esfuerzos de seguridad). El hardware opaco de terceros no debería ser mi punto débil.

Un retransmisor http no sería completamente oneroso de escribir (he hecho una buena cantidad de codificación a nivel de puerto en el pasado) pero las soluciones maduras y existentes serían agradables.

Entonces, la pregunta es: ¿existe un enfoque para implementar un retransmisor http existente que satisfaga mis requisitos?

(Tenga en cuenta que actualmente estoy usando VPN para entrar en la red desde fuera cuando necesito modificar algo, pero no es la experiencia del usuario que estoy buscando)

    
pregunta EddieOffermann 23.01.2014 - 00:48
fuente

2 respuestas

1

Dado que el acceso ha sido suficientemente restringido, el enlace más débil es la solicitud HTTP. Esto es especialmente cierto en base a los comentarios sobre las interfaces pobres de las cámaras IP. Es probable que no les vaya bien si se envían solicitudes irregulares. Por lo tanto, considere un Servidor de seguridad de aplicaciones web (WAF) como ModSecurity, ya que proporcionará más flexibilidad sobre qué tráfico se permite al definir las reglas de cómo debería ser realmente una solicitud.

    
respondido por el anon 25.10.2014 - 22:05
fuente
1

Hacer proxys como lo propones hacer te da la posibilidad de agregar autenticación y cifrado adicionales, pero nada más.

Las cámaras IP tienen interfaces terribles y código terrible. Si simplemente envía las solicitudes, estará procesando cada posible exploit en la cámara. Si las sesiones de usuarios autenticados se consideran un posible vector de ataque en su evaluación de riesgos, no debería simplemente ser un proxy, sino que necesita al menos validar todas las solicitudes que se esperan.

Si las sesiones de usuarios autenticados no se consideran un vector de ataque en su evaluación de riesgos, entonces ese es un problema que debe solucionar primero.

    
respondido por el Ben 28.01.2014 - 17:19
fuente

Lea otras preguntas en las etiquetas