Understanding the whole port 80 security issue of shoutcast

[Brutish Sailor]

OK, I need someone with a little more time in streaming experience to help me understand this possible security issue of Shoutcast from the root...

 

 

Right now to run port 80 because of the fears of running SC_serv in root, I have my server set up pretty funky.

 

1) I set up an instance of icecast2. It will let me run true port 80 without running it in the root.

 

2) I have it relaying a SC_serv with SC_trans skinned to autoDJ to Icecast. I suspect that I should be able to stream to that server from my home server as well due to the SC_trans feature.

 

Its a really funky setup, but the easiest way i can think of to do port 80 streaming with SC_trans to Icecast2, and dont get me wrong, Ice2 is better on computer resources anyways.

 

Anyone have a better way to set this up? or is that whole security comprimise with SC a myth?

[Randy]

Although I've never seen any issues with running sc_serv as root (there are no known shell escalation holes), there are a couple work arounds to this limitation.

 

Run it on a high port and use IPtables to forward port 80 onto the higher port (so both ports will work basically).

 

Or, you can remove the os's limitation on binding low ports. The method depends on which OS you're running.

[uberstreaming]

For security sake, i never run sc_serv as root..

 

port 80 will use apache and it will take up quite abit of resources. Not really recommended though.

[Brutish Sailor]

Like randy said, port 80 can be set to not bind to apache.

 

The big problem with forwarding ports is that We (a well trusted, powerful Linux guy and I) noticed that when people try to tune into port 80 forwarded from a higher port, it wants to hand them a file package from the forwarded port to tune in. So it becomes not TRUE port 80.