Icecast - Apr 2013 - Protect Icecast Admin/Run on different port?

On 3 April 2013 02:19, Philipp Schafft <lion at lion.leolix.org> wrote:
> reflum,
>
> On Thu, 2013-03-28 at 14:28 +0000, David Farrell wrote:
> > Hi list,
> >
> > We're new to Icecast and we're looking at securing the admin
functions.
> > I've trawled the docs but it's not clear to me if we are able
to run
> > this on a different TCP port to the streams themselves.
> >
> > Has anyone with a little more experience any insight into this?
>
> Hi Philipp,
Thanks for your reply.

> You can not run the admin interface on a diffrent port.
> I also don't see how that should improve security.
>
> We would not expose the administrative port to the world, rather to a
range of trusted IP addresses.

> Which kind of attac do you try to protect against? Maybe I can help you
> if you tell a bit more about your overall goal.
>
> The goal is just really to restrict administrative access to the systems.
> In general: Use strong passwords. Avoid sending them in plain text.
>
That is a given, I have yet to investigate what external AAA resources we
can use in this case e.g. RADIUS, LDAP.

David.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast/attachments/20130403/8f3a04d3/attachment.htm

On 03/04/13 10:08, David Farrell wrote:
>
>
>
> On 3 April 2013 02:19, Philipp Schafft <lion at lion.leolix.org 
> <mailto:lion at lion.leolix.org>> wrote:
>
>     reflum,
>
>     On Thu, 2013-03-28 at 14:28 +0000, David Farrell wrote:
>     > Hi list,
>     >
>     > We're new to Icecast and we're looking at securing the
admin
>     functions.
>     > I've trawled the docs but it's not clear to me if we are
able to run
>     > this on a different TCP port to the streams themselves.
>     >
>     > Has anyone with a little more experience any insight into this?
>
> Hi Philipp,
>
> Thanks for your reply.
>
>     You can not run the admin interface on a diffrent port.
>     I also don't see how that should improve security.
>
> We would not expose the administrative port to the world, rather to a 
> range of trusted IP addresses.
Feel free to file a ticket at http://trac.xiph.org
It might not be too complicated to add a check that admin requests can 
only come through a certain port. Bonus points for sending patches.
>     Which kind of attac do you try to protect against? Maybe I can
>     help you
>     if you tell a bit more about your overall goal.
>
> The goal is just really to restrict administrative access to the systems.
If you really know what you're doing a light weight reverse proxy is 
currently the only option to filter that.
I can see that restricting requests to either an IP white-list or a port 
would be desirable for production environments.
>     In general: Use strong passwords. Avoid sending them in plain text.
>
>
> That is a given, I have yet to investigate what external AAA resources 
> we can use in this case e.g. RADIUS, LDAP.
Right now for admin access Icecast only supports http basic auth with 
optional SSL transport security. For listener and source connections we 
support forwarding the plain text authentication credentials to a 
back-end for validation.
Tickets and patches welcome.

Cheers

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast/attachments/20130403/10f1e416/attachment-0001.htm

reflum,

On Wed, 2013-04-03 at 14:37 +0300, "R?cker, Thomas"
wrote:
> On 03/04/13 10:08, David Farrell wrote:
> > On 3 April 2013 02:19, Philipp Schafft <lion at lion.leolix.org>
wrote:
> >         On Thu, 2013-03-28 at 14:28 +0000, David Farrell wrote:
> >         
> > Hi Philipp,
> > 
> > 
> > Thanks for your reply.
np. :)
> >         You can not run the admin interface on a diffrent port.
> >         I also don't see how that should improve security.
> >         
> > We would not expose the administrative port to the world, rather to
> > a range of trusted IP addresses.
> 
> Feel free to file a ticket at http://trac.xiph.org
> It might not be too complicated to add a check that admin requests can
> only come through a certain port. Bonus points for sending patches.
We currently support a allow/deny list for IP addresses at connection
layer. Maybe we could port that to the next layer (admin, web, yp,
source, stats). I guess that would solve your problem. See below.
> >  
> >         Which kind of attac do you try to protect against? Maybe I
> >         can help you
> >         if you tell a bit more about your overall goal.
> >         
> > The goal is just really to restrict administrative access to the
> > systems. 
> > 
See above.
> If you really know what you're doing a light weight reverse proxy is
> currently the only option to filter that. 
> I can see that restricting requests to either an IP white-list or a
> port would be desirable for production environments.
This requires (as well as all the other possible solutions) complex
rules as there are some stuff within admin/ that needs special handling:
playlist generation, resources accessable to the source(user) and
resources accessed by the source itself (meta data updates for broken
containers/codecs).

PS: I got like a milion copies of your E-Mail. They all have distinct
message-id. Please check your MUA/MTA/... to avoid this. Thanks!

-- 
Philipp.
 (Rah of PH2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url :
http://lists.xiph.org/pipermail/icecast/attachments/20130403/f7e87bd9/attachment.pgp