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