Icecast Streaming Media Server

[karlH]

They will show up in the log if they get to the auth engine. The idea was to use the script to add the IP to the denied IP list or firewall, thereby making the banning automatic.

eg
mount-name /*/*.html
a simple series of reads, then echo $IP >> /path/to/IP-denied

karl.

[audiorapture]

Which would work if it was the same set of IPs, right. I will capture the IPs for a day and see if they repeat.

Thanks again for all your help!

[audiorapture]

FYI - I have captured 588 unique IP addresses out of 13,492 requests.
Here's the top10 - curiously all of them out of Germany:
IP CountOfIP
188.193.236.119 341
84.138.213.134 306
84.174.211.65 265
93.133.117.29 253
213.196.200.151 232
95.89.242.138
91.13.61.208 221
95.118.95.117 214
91.16.156.34 214
84.179.110.96 204

There are 237 IPs that only requested once or twice.

UPDATE (2010-01-18): 3,100 unique IPs in the block list.
UPDATE (2010-01-21): 8,829 unique IPs in the block list.
UPDATE (2010-01-25): 26,110 unique IPs in the block list.
UPDATE (2010-02-04): 68,326 unique IPs in the block list.

[jorgosch]

I'm getting these, too, and lots. The network addresses look similiar, and they all have in common the same user agent:

Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

Looks like some kind of bot, maybe this could be blocked by default? If not, what's the correct syntax for the user agent blockfile, does it use Regular Expressions, .htaccess-style?

(I am on Windows)

[karlH]

The kh tree does have a <deny-agents> in <paths>, a file which lists a series of useragent you can prevent connecting (wildcards allowed), not regex but shell wildcard style. The useragent match is not that great for matching these as useragent can change easily.

To achieve quickly, I would extract the IPs from the access log that match the requests being thrown at you and place those IPs in a txt file that icecast will read specified by <deny-ip>. You won't need to restart icecast updating the file, and reloading the xml will allow for you to specify the <deny-ip> setting

Another alternative is to set up an dummy mount using url auth call a web script that collect the IPs for you then just copy that across. Those collected IPs can be used for the firewall or the banned file for icecast

Whatever you think is easier.

karl

[beat]

Hi

We have the same problem here, we get around 120 requests/second for the inexistent index.html on different mountpoints on our servers.
The requests are mainly originated in Germany...

Is this a botnet or a common bad coded player-software?

Kind regards
Beat

[audiorapture]

I am about 90% sure that this is a botnet - simply because we don't see the frequency of hits corresponding with our normal listener numbers.

Not sure what they are trying to achieve, though.

[jcr]

looks like a strange kind of DOS attack. I had this too on 5 of my icecast servers and couls trace same requests on more than 128 others on the same network.
_________________
Epsilon Friends Radio Icecast Radio on CentovaCast admin panel. Icecast hosting

[audiorapture]

I now have 238,657 unique IPs in my blocklist and counting.

Also, it seems that this "large" number causes rebuffering of the stream on occasion with kh21a.

I am really wondering whether I should simply block the user-agent (instead of IPs with a script) as it hasn't changed since I started noticing.

[karlH]

A connection that is banned will not be getting to the worker as the IP can be determined at connection time but a useragent filter has be get to the worker so the headers can be read and only then can it be dropped. I'm assuming you have configured icecast to refer to this file of denied address (it will re-read it every so often and log that fact). If quite a few connect at the same time (not banned) then it could be busy, but the suggestion was to prevent re-offenders.

karl.

[robertut]

[audiorapture]

[audiorapture]

OK - there is a little side issue (as discussed above already):
If I use useragent, my access log stays clean.
If I use auth, each (new) IP will cause an entry in the access log for the non-existent file/stream.

If there was a way to keep those bogus requests from polluting my access log I'd be really happy.

[karlH]

actually, you probably can by doing

<mount>
<mount-name>/*/*.html</mount-name>
....
<accesslog>
<name>/dev/null</name>
</accesslog>
</mount>

karl.

[audiorapture]

Sadly, no.

This is the mount definition (kh21a):
<mount>
<public>0</public>
<hidden>1</hidden>
<mount-name>/wnrn.mp3/index.html</mount-name>
<authentication type="command">
<option name="listener_add" value="/usr/local/share/icecast/auth/deny.sh"/>
</authentication>
<accesslog>
<name>/dev/null</name>
</accesslog>
</mount>

Yet I still get this entries in the access log after reloading the config file:
84.150.104.20 - - [20/Mar/2010:21:31:08 -0400] "GET /wnrn.mp3/index.html HTTP/1.0" 401 119 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" 0
217.238.21.247 - - [20/Mar/2010:21:31:59 -0400] "GET /wnrn.mp3/index.html HTTP/1.0" 401 119 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" 0

Am I doing something wrong, here?