| View previous topic :: View next topic |
| Author |
Message |
WAB
Joined: 29 Aug 2007 Posts: 27
|
Posted: Fri Dec 10, 2010 4:14 am Post subject: How can I limit to n connections/IP? |
|
|
| The title speaks for itself. The answers I've read about authentication are pretty vague. Is there any way or mod to do it with a public server? |
|
| Back to top |
|
 |
karlH Code Warrior

Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Fri Dec 10, 2010 12:36 pm Post subject: |
|
|
Authentication is a more general mechanism which could be used but is a bit over the top for just limiting connections to 1 IP but can be used for limiting the number of connections.
The only option at the moment, directly in icecast is the <ban-client> setting in the kh tree which could be made server-wide however that would affect the display of the xsl pages as browsers issue multiple image requests at the same time and those would block. You can do
<paths>
<deny-ip>/path/to/always/blocked/IPs</deny-ip>
...
<mount>
<mount-name>/stream</...
<ban-client>-1</back-client>
...
</mount>
That will add the client IP requesting /stream to the internal list of blocked IPs enabled with the <deny-ip> setting in <paths>
karl. |
|
| Back to top |
|
 |
WAB
Joined: 29 Aug 2007 Posts: 27
|
Posted: Mon Dec 20, 2010 1:52 am Post subject: Sorry for the late answer |
|
|
and thanks for your concern.
Banned IPs is not the answer as I can't predict what IP will DOS attack me...
Hope to come up with something some day.
You can actually DOS attack any icecast server pretty easy with a simple bash script (I made one to check my clients capacity) |
|
| Back to top |
|
 |
karlH Code Warrior

Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Mon Dec 20, 2010 3:11 am Post subject: |
|
|
There are already DoS type attacks going on, the ban-client option helps in those cases if you give a duration of a few hours. With that setting it prevents the worker threads seeing the request so normal work is done but it still listens on the socket so there is still that point of contention. Over above this you would have to use firewall hooks to drop/ignore connections, that sort of thing could be done via auth but it does depend on how far you want to go..
karl. |
|
| Back to top |
|
 |
boteman

Joined: 04 Dec 2009 Posts: 8 Location: south FLA, USA
|
Posted: Wed Jun 08, 2011 4:48 pm Post subject: user agents behaving badly |
|
|
I have a similar request based on user agents that insist on opening multiple instances to one feed. I have seen this with Leadapps for Android, Dalvik, TuneIn Radio, and others.
They apparently start the first stream, then another stream a few seconds later. Apparently, it is this second (or most recent) stream that actually is used. I don't know why the first stream is maintained. In some cases three streams run concurrently.
With a limited number of listener clients allowed per stream this can consume all available slots if only a few such listeners connect. This is not a DoS attack, this is just bad behavior on the part of the listener clients.
I was hoping there would be a way to allow only one i.p. address/user agent pair per stream without resorting to the ban list, since that would appear to be a brute-force method. I am not using a branch, just the stock 2.3.2 distribution which works swimmingly!
I seriously doubt it will be possible to ask the authors of all these streaming apps to correct their behavior, so it is up to the server to kick the older processes while leaving the most recent ones for the listener.
Thanks. |
|
| Back to top |
|
 |
karlH Code Warrior

Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Wed Jun 08, 2011 5:44 pm Post subject: |
|
|
If you have a sane patch to handle that then by all means send it in, but you really should talk to the people causing the problem rather than to people who have to go out of their way to avoid it. You could use url auth to trigger a killclient request so as you identify the connection you don't want, but does that even allow the playback properly as you may find that it either reconnects or stops playback.
karl. |
|
| Back to top |
|
 |
boteman

Joined: 04 Dec 2009 Posts: 8 Location: south FLA, USA
|
Posted: Wed Jun 08, 2011 6:17 pm Post subject: |
|
|
I was hoping that you could point me in the right direction to research a method to detect duplicate ip/user agent pairs so that I could figure out a way to attack the problem.
I was simply taking the pragmatic way out, since this problem seems to be getting worse as more and more smartphone streaming apps appear on the market. I suspect that the authors are simply using high level language tool kits, so perhaps the underlying libraries are at fault, but that is mere speculation on my part. I don't see this problem getting better in this scenario.
You are correct that the most recent connection that is truly listening to the stream might very well restart itself, but the older zombie connections seem to go away never to return. That made me hopeful that I could do some automated management on my server to keep things under control. |
|
| Back to top |
|
 |
jcr Modérateur français

Joined: 14 Apr 2006 Posts: 544 Location: France, Auvergne
|
Posted: Sun Jun 12, 2011 11:10 pm Post subject: |
|
|
Well, I'm facing the same problem with this proliferation of mobile apps, which sound not cleverly written.
Also searching for a fix for those brainless apps. _________________ Epsilon Friends Radio Icecast Radio on CentovaCast admin panel. Icecast hosting |
|
| Back to top |
|
 |
karlH Code Warrior

Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Mon Jun 13, 2011 1:30 am Post subject: |
|
|
I have no more of an idea on what will get them to work than you, you can try various tests to see if dropping an existing connection from that same IP is enough for example.
A modification to the check_duplicate_logins routine should handle that case. something like
if (strcmp (client->connection.ip, existing_client->connection.ip) == 0)
{
existing_client->connection.error = 1;
return 1;
}
should be enough to try out.
karl. |
|
| Back to top |
|
 |
|