[Icecast] admin console

[Rondejavu]

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