Vulnerabilità associate al server di streaming audio

Question

Vulnerabilità associate al server di streaming audio

#1 da (3 voti)

3

Quali vulnerabilità dovrò affrontare durante l'utilizzo di un server come server di streaming audio? Per favore, spiega tutte le possibilità e tutte le cose da sapere.

La prima cosa che mi ha fatto pensare alle vulnerabilità era che gli utenti e le password di accesso non sono usati in hash - almeno durante l'utilizzo di IceCast - e sono tutto chiaro testo! C'è un modo di usare l'hash al posto o no? In caso contrario, quali vulnerabilità potrebbe causare?

Cos'altro può essere dannoso, - porte ed ecc. - qualcosa ?? E di cosa dovrei essere a conoscenza durante la configurazione del mio server di streaming?

Ulteriori informazioni su ciò che sto utilizzando:

Uso IceCast per il server e EZStream come client di origine per il server di streaming Icecast (ad esempio client / listener ( s)).

E sto eseguendo questo progetto sia su Debian Jessie che su CentOS 7 - non ancora lanciato, ancora nella sua versione beta test-like, così posso cambiare qualsiasi cosa.

Sono aperto a qualsiasi suggerimento, anche se si tratta di fare le cose da zero.

linux unix audio vulnerability countermeasure

posta Parsa Samet 03.09.2016 - 14:42

fonte

1 risposta

Leggi altre domande sui tag linux unix audio vulnerability countermeasure

Hash non crittografico per l'autenticazione dei messaggi? Crittografia con Jasypt per Java

score 3 · Accepted Answer

Vedi sotto lo schema di esempio. In questo modo va bene perché:

Il server a cui si spinge lo streaming non è lo stesso di quello pubblico, quindi è possibile assicurarsi che sia protetto correttamente, come se non ci fosse un accesso pubblico, in questo modo si chiudono un sacco di exploit associati a spingere flussi e altro trucchi (è necessario che gli stream di pubblicazione siano abilitati su questo)
Sul server periferico non è necessario impostare alcuna password o accesso (come premere i flussi), basta puntare al server di origine dov'è il flusso di origine
È quindi possibile utilizzare due server periferici e bilanciare il carico tra di loro durante l'utilizzo di un server di origine singola (il DNS può essere utilizzato per farlo)
Hai una maggiore stabilità della tua spinta audio nel caso in cui il tuo server periferico venga sommerso, caricato ecc.

Puoi farlo in questo modo: - Ospitare due server (origine e bordo) nella stessa casella ma porte diverse - Host server di origine sul sistema EZStream e porta di installazione in avanti sul router all'indirizzo IP statico per estrarlo da lì, questo metodo è più stabile ma richiede un indirizzo IP statico - Sul server periferico disabilitare il più possibile e impostare il limite su max flussi come a 100MBps o meno per VPS tipico - Se si dispone di un indirizzo IP statico sul sistema EZStream, configurare il firewall per consentire solo a EZStream di connettersi al server di origine. Se non si dispone, impostare il percorso Firewall per l'intera classe in base a WHOIS (whois il tuo indirizzo IP).

Questo tipo di installazione è la più stabile e sicura senza fare molto. Mantenere SELinux anche sulla casella Centos7 e eventualmente aggiungere ulteriori regole per IceCast se necessario (audit2allow). Ciò garantirà un livello molto alto di sicurezza per il demone di rete. Questo è altamente raccomandato per i server IceCast.