Icecast - Feb 2020 - admin console

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
--

Good evening,


On Thu, 2020-02-13 at 14:59 +0000, user wrote:
> Philipp Schafft, who allow you to publish my private message?
I could also ask who allowed you to send me unwanted private messages?

In fact I did not notice it was sent privately until after my reply. It
was totally unexpected to be private as it did not contain any hints for
that nor any sensitive information. And it was clearly an reply to an
question I posted on a public list wich clearly asked for a public
reply.

Even more as not replying to the list but privately is a common mistake
I didn't thought much about it. Also keeping in mind that you break
threading. Like here:
> > Remove
> > -Pete
This is not from my mail. So I thought it was just another tiny mistake.


What I feel discomfort about is that this is getting away from the
actual discussion. I don't think the public list is interested in this.
However more interested in your comments on my questions.

I hope that we can get back on-topic. I would be happy to hear from you
about the actual questions and will ignore future meta mails.
If you want to complain about me, feel free to contact
<icecast-owner at xiph.org>.

> [...] 
With best regards and best hopes for this thread,

-- 
Philipp.
 (Rah of PH2)