[Icecast] 8000 security risk?

[Thomas B. Rücker]

Hi Patricia,

On 5/10/19 2:48 PM, Patricia Moynihan wrote:
> Yes I meant HTTPS over HTTP, which yes, I’m differentiating by those
> port numbers. Thanks for clarifying! We have been streaming HTTP for a
> long time, but I am at a university and there is a lot of emphasis on
> security. I was never really sure what the certificate did for us in
> this case…but was attempting to comply! 


For you there is no direct security benefit. It does 'comply' with
'tickbox-security' though and gets you the 'security people' off your
neck. Achievement unlocked!

side note: you don't seem to be running any service on port 80 nor 443.
Consider adding those to your Icecast configuration to increase your
client compatibility, especially in terms of Browsers and "corporate
networks that block everything that's not on port 80 or 443 for
'security' reasons". If your server runs Debian or Ubuntu, this will be
a bit more involved, but still fairly easy (there are descriptions found
e.g. in the list archive)



> Over the years we have had a small handful of IPs trying to
> maliciously access our Icecast server over port 8000. I guess the less
> of that I have to deal with, the better. But if there are streaming
> aggregators out there who can’t use the HTTPS over the HTTP, then it
> may be better to deal with the inconvenience once in a while.


I'm sorry, but as an information security professional I MUST
disillusion you on this.

Adding HTTPS does absolutely ZERO for the security of your Icecast
server, *especially* in terms of "IPs trying to maliciously access" it.
This ties into the "threat model" I mentioned. (The only exception would
be legitimate source client connections from the Internet and I strongly
suspect that not to be the case here)

The only thing that you could call a security improvement is on the
client side. It is no longer trivial to intercept data sent by the
server to and from the client, including which resource (stream) is
being accessed.

Security is a complex topic and there are many areas and details and
things tend to turn upside down depending on what your priorities
(threat model) are.


TBR


> Thanks for your help. 
>
> Patricia Moynihan
> Director of Digital
>
> pmoynihan at fsu.edu <mailto:pmoynihan at fsu.edu>
> 850-645-6067
> 850-645-7200
>
>> On May 10, 2019, at 4:04 AM, Thomas B. Rücker <thomas at ruecker.fi
>> <mailto:thomas at ruecker.fi>> wrote:
>>
>> Hi,
>>
>> On 5/10/19 3:11 AM, Patricia Moynihan wrote:
>>> Are there any serious security risks for leaving port 8000 open to
>>> public use on icecast? I had wanted to limit to 8443 but it seems some
>>> radio devices cannot support this protocol.
>>
>>
>> The port number doesn't matter. I guess in your case you mean HTTP vs
>> HTTPS.
>>
>> The proper and terse answer is:
>>
>> It doesn't matter if you use HTTP or HTTPS as long as you have a secure
>> configuration including managed and strong (not bruteforceable)
>> passwords AND you keep your Icecast server up to date wrt security
>> updates (currently Version 2.4.4).
>>
>> From my anecdotal knowledge gained over 18 years of involvement in
>> Icecast, if people would follow the above two, then 99,9% of incidents
>> would not happen.
>>
>> The longer answer is that it will also depend on your 'threat model' and
>> how you rate and address things that you consider 'risks' in this frame
>> of reference. There is no one-fits-all or immediate answer that fits
>> into this email.
>>
>>
>> Hope this helps,
>>
>> Thomas
>>
>>
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org <mailto:Icecast at xiph.org>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.xiph.org_mailman_listinfo_icecast&d=DwIGaQ&c=HPMtquzZjKY31rtkyGRFnQ&r=il3mbeSthlxEJd_b1NtmGe2biSOKp7VwqcXPdl2MdRc&m=X3zh6M4zoa3mkJwmMiZz1f54FZWn_anDeugwt91Y9Uw&s=PddWQ35fNEeUXAPZc9z2OIcjlDRy3lSx_2XgODSskyM&e=
>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast