[Icecast] 8000 security risk?

Fri May 10 21:04:07 UTC 2019

TBR,

Thanks for the clarification. Where can I read more about security - related to http(s), online streaming and websites? Where do I start?

In the past I’ve seen the anything but 80 and 443 blocking thing, especially in government offices. Haven’t experienced those complaints in while, but it is a good suggestion! I assume I can add the ports in the icecast.xml, open them in the various places (computer/dns), and be ok? No need to answer, I’ll look it up! I’m running on Centos 7.

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 1:29 PM, Thomas B. Rücker <thomas at ruecker.fi<mailto:thomas at ruecker.fi>> wrote:

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> <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>
<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> <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<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=OD-PDzRTQcORzIDkfdfm9ZArtiOmESX8sYcnDnJyJuw&s=-vGj3IVe8I7JCpXxfhkMRgsyItHncb8nWnWA2Fz5p1U&e=

_______________________________________________
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=OD-PDzRTQcORzIDkfdfm9ZArtiOmESX8sYcnDnJyJuw&s=-vGj3IVe8I7JCpXxfhkMRgsyItHncb8nWnWA2Fz5p1U&e=

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20190510/478ed174/attachment.htm>