Vulnerabilidades asociadas con el servidor de transmisión de audio

Question

Vulnerabilidades asociadas con el servidor de transmisión de audio

#1 de Aria (3 votos)

3

¿Con qué vulnerabilidades me enfrentaré durante el uso de un servidor como servidor de transmisión de audio? Por favor explique todas las posibilidades y todo lo que necesita saber.

Lo primero que me hizo pensar en las vulnerabilidades fue que los usuarios y las contraseñas de inicio de sesión no se usan en hash, al menos al usar IceCast , y todo el texto claro! ¿Hay alguna manera de usar hash o no? Si no es así, ¿qué vulnerabilidades puede causar?

¿Qué más puede ser dañino, - puertos y etc. - cualquier cosa? ¿Y qué debo tener en cuenta durante la configuración de mi servidor de transmisión?

Más información sobre lo que estoy usando:

Estoy utilizando IceCast para el servidor, y EZStream como cliente de origen para el servidor de transmisión de Icecast (es decir, cliente / oyente ( s)).

Y estoy ejecutando este proyecto en Debian Jessie y CentOS 7, aún no se ha lanzado, todavía en su versión beta de prueba, por lo que puedo cambiar cualquier cosa.

Estoy abierto a cualquier sugerencia, incluso si se trata de hacer cosas desde cero.

vulnerability linux unix countermeasure audio

pregunta Parsa Samet 03.09.2016 - 14:42

fuente

1 respuesta

Lea otras preguntas en las etiquetas vulnerability linux unix countermeasure audio

Lista de verificación de seguridad básica para usar una biblioteca de código abierto ¿Método seguro para almacenar objetos PHP en la base de datos MySQL?

score 3 · Accepted Answer

Vea el siguiente diagrama de ejemplo. Esta manera es buena porque:

El servidor en el que se empuja el flujo no es el mismo que en la Internet pública, por lo tanto, puede asegurarse de que esté correctamente asegurado, ya que no hay acceso público al mismo, por lo que de esta manera se cierran muchos ataques asociados con el envío de flujos y otros. trucos (es necesario tener las secuencias de publicación habilitadas en este)
En el servidor perimetral no necesita configurar ninguna contraseña ni ningún acceso (como empujar flujos), solo señale el servidor de origen donde se encuentra el flujo de origen
Luego puede usar dos servidores perimetrales y un equilibrio de carga entre ellos mientras usa un servidor de origen único (se puede usar DNS para hacerlo)
Obtuvo una mayor estabilidad de su inserción de audio en caso de que su servidor perimetral se vea inundado, cargado, etc.

Puedes hacerlo de esta manera: - Aloje dos servidores (origen y borde) en la misma caja pero puertos diferentes - El servidor de origen del host en el sistema EZStream y el puerto de configuración reenvían en el enrutador a la dirección IP estática para extraerlo desde allí. Este método es más estable pero requiere una dirección IP estática - En el servidor perimetral, deshabilite tanto como pueda y configure el límite a flujos máximos como a 100MBps o menos para un VPS típico - Si tiene una dirección IP estática en el sistema EZStream, configure el firewall para permitir que solo su EZStream se conecte al servidor de origen. Si no lo tiene, configure la ruta de Firewall para toda su clase en función de WHOIS (quién es su dirección IP).

Este tipo de configuración es más estable y más segura sin hacer mucho. También mantenga SELinux en el cuadro Centos7 y, finalmente, agregue reglas adicionales para IceCast si es necesario (audit2allow). Esto le garantizará un nivel de seguridad muy alto para el daemon de red. Esto es muy recomendable para los servidores IceCast.