[Icecast] admin console

[Philipp Schafft]

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)