[Icecast] admin console

[user]

Philipp Schafft, who allow you to publish my private message?

> Remove
> 
> -Pete
> 
> > On Feb 13, 2020, at 8:46 AM, Philipp Schafft <lion at lion.leolix.org> wrote:
> > 
> > ???Good afternoon,
> > 
> > please have a look into your MUA setup. You keep breaking threading for
> > this thread (In-Reply-To header is set incorrectly).
> > 
> > 
> > On Tue, 2020-02-11 at 13:40 +0000, user wrote:
> >>>> On Thu, 2020-02-06 at 19:20 +0000, user wrote:
> >>>>> 2020-01-08 09:59, Marvin Scholz wrote:
> >>>>> Expectation on malicious activity force me to put icecast behind reverse
> >>>>> proxy. It was not easy, but works very well.
> >>> 
> >>> So, what kind of "malicious activity" exactly? And what exact HTTP level
> >>> software is more robust against those activities than Icecast?
> >>> 
> >>> I'm fully in support that active components on lower levels can be helpful
> >>> in some situations. But I would love to hear about any analysis indicating
> >>> specific request patterns that would be better handled by external
> >>> software. If you would share your information rather than keeping us in
> >>> the dark about specifics it would enable us to improve Icecast for all
> >>> users including you. :)
> >>> 
> >>> With best regards,
> > 
> > Thank you for your answer. I very much appreciate it.
> > 
> > 
> > Sadly I do not see an answer to my question "So, what kind of 'malicious
> > activity' exactly?". And the answer to that question is what all the
> > rest depend on. Without it any discussion is basically voided.
> > 
> > 
> > Still some thoughts on your points:
> > 
> >> 1. First of all I would like to deny access to everything except
> >> "/stream.ogg" depends on client IP.
> > 
> > Icecast will request requests for any unknown target anyway. If you
> > don't like access to the static files in web/ you can just delete them
> > or set <webroot> to an empty path.
> > 
> > admin/ is protected, so unauthed clients will get a reject anyway.
> > 
> > 
> > I don't really see a reason for a reverse proxy here. Icecast already
> > rejects those requests. Plus I hardly see harm that could be caused
> > beside a bit of extra traffic.
> > 
> > allow/deny rules for IPs can be defined with <allow-ip> and <deny-ip>.
> > Plus if you really have a list of "malicious" clients you should likely
> > block them on your border gateway or firewall anyway.
> > 
> > 
> >> 2. Deny everything depends on User-Agent value and User-Agent length.
> > 
> > Without an answer to my question above you can hardly discuss this. But
> > I don't see much point in this generally as the user agent string is
> > basically a freeform user setting. So an attacker can change it at will.
> > 
> > At best it would be helpful to do some matches to avoid getting hits by
> > misbehaving clients. But that is a totally different class than
> > attacking clients.
> > 
> > Also, such a check could be implemented in Icecast as well. Depending on
> > your version in different ways.
> > 
> > 
> >> 3. Deny HTTP 1.0 protocol.
> > 
> > Which is a bad idea as Icecast 2.4.x (stable) IS a HTTP/1.0 server. So
> > if you disable that protocol and you still can connect your filter does
> > not work anyway.
> > 
> > 
> >> Application-Layer DDoS Attack Protection with
> >> HAProxy: "A number of attacks use HTTP/1.0 as the protocol version because
> >> that's the version supported by some bots."
> > 
> > While we move away from Icecast there is nothing inherently wrong with
> > HTTP/1.0 in Icecast context. And again, those bots could be easily
> > updated to use HTTP/1.1 by setting the version to HTTP/1.1 and adding a
> > Host:-header (which they likely send already).
> > 
> > 
> >> 4. Turn on/off anti-DoS protection depends on connection rate.
> > 
> > This is clearly a common firewall feature. Limiting rate or request rate
> > can be done with any firewall. And is totally done best there as it will
> > filter out traffic before it even hits your server.
> > 
> > 
> > Here is another point you should add to your consideration:
> > A reverse proxy adds an additional, complex component to your setup. It
> > therefore increases the attack surface (it has it's own bugs, it's own
> > flaws, ...).
> > A reverse proxy need to process the HTTP level messages an additional
> > time. This requires additional CPU power and time.
> > It also requires additional system resources like sockets, file
> > descriptors, I/O-buffers, scheduling slots, ...
> > 
> > So a reverse proxy always amplifies any *DoS kind of attack as
> > significant more resources are required per request.
> > 
> > 
> > From a business perspective it will add more costs: system resources,
> > maintenance, more skilled admins, ... For a single hour of admin time
> > you can book a VPS at a random provider for a complete year that can
> > handle 10k simultaneous connections or 10k simultaneous "malicious"
> > connections.
> > 
> > With best regards,
> > 
> > -- 
> > Philipp.
> > (Rah of PH2)
> > _______________________________________________
> > Icecast mailing list
> > Icecast at xiph.org
> > http://lists.xiph.org/mailman/listinfo/icecast
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast

--