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! 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. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20190510/507faeed/attachment.html>
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
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.html>