Icecast Streaming Media Server

[taudas]

i've just started to get all these fserve errors. started 12/4 and now is about 20 probes/minute. it looks like many ips are trying a url that does not exist. (is it really http://floyd.wcbn.org:8000/wcbn-hi.mp3/index.html ?) does anyone have some ideas as to what is going on?

floyd.wcbn.org:/var/log/icecast# tail access.log
87.177.129.118 - - [20/Dec/2009:14:01:27 -0500] "GET /wcbn-hi.mp3/index.html HTTP/1.0" 404 106 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" 0
91.60.184.5 - - [20/Dec/2009:14:01:28 -0500] "GET /wcbn-hi.mp3/index.html HTTP/1.0" 404 106 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" 1
188.99.190.17 - - [20/Dec/2009:14:01:28 -0500] "GET /wcbn-hi.mp3/index.html HTTP/1.0" 404 106 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" 1
79.232.191.46 - - [20/Dec/2009:14:01:28 -0500] "GET /wcbn-hi.mp3/index.html HTTP/1.0" 404 106 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" 0
94.218.68.198 - - [20/Dec/2009:14:01:28 -0500] "GET /wcbn-hi.mp3/index.html HTTP/1.0" 404 106 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" 0
93.209.44.89 - - [20/Dec/2009:14:01:28 -0500] "GET /wcbn-hi.mp3/index.html HTTP/1.0" 404 106 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" 0
87.79.201.36 - - [20/Dec/2009:14:01:28 -0500] "GET /wcbn-hi.mp3/index.html HTTP/1.0" 404 106 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" 0
91.67.155.36 - - [20/Dec/2009:14:01:29 -0500] "GET /wcbn-hi.mp3/index.html HTTP/1.0" 404 106 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" 0
91.66.55.205 - - [20/Dec/2009:14:01:29 -0500] "GET /wcbn-hi.mp3/index.html HTTP/1.0" 404 106 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" 0
91.115.71.5 - - [20/Dec/2009:14:01:29 -0500] "GET /wcbn-hi.mp3/index.html HTTP/1.0" 404 106 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" 0
... many more ips listed

floyd:/var/log/icecast# tail error.log
[2009-12-20 14:02:28] INFO fserve/fserve_client_create checking for file /wcbn-hi.mp3/index.html (/etc/icecast2/web/wcbn-hi.mp3/index.html)
[2009-12-20 14:02:28] INFO fserve/fserve_client_create checking for file /wcbn-hi.mp3/index.html (/etc/icecast2/web/wcbn-hi.mp3/index.html)
[2009-12-20 14:02:29] INFO fserve/fserve_client_create checking for file /wcbn-hi.mp3/index.html (/etc/icecast2/web/wcbn-hi.mp3/index.html)

[DJ-Zath]

hi there!

What you have there is clients/browsers calling for a mount named

/wcbn-hi.mp3

its NOT a portscan or probe.. just players trying to log into a mount.. if thats NOT one of your mounts, I suspect theres been a DNS error or listing error somewhere

theres no harm in that.. you're okay.

-DjZ-

_________________
-DjZ-

[audiorapture]

I have the same problem with these messages filling up the log. They do seem benign, but still seem like a botnet - all of the requests share the same properties:
"GET /wnrn.mp3/index.html HTTP/1.0" 404 105 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)"

But the IPs are from all over the world. I get about 1 request per second now.

And index.html is definitely *not* a mount on the server.

[karlH]

The request are very odd, check to see if you are getting repeats from the same IPs, so is it a group of say 20 IPs issuing the same request over and over? The index.html may be appended to a playlist that is incorrectly formatted.

karl.

[audiorapture]

Doesn't look to come from the same set - here is a sorted list from about 2 minutes:
188.194.84.244
213.3.26.132
217.15.13.15
217.15.13.15
217.233.235.57
217.88.0.211
69.155.89.210
78.34.185.60
78.50.145.165
78.50.145.165
78.94.3.100
79.199.142.207
79.236.33.88
80.129.154.134
80.129.154.134
80.134.38.153
82.93.214.151
84.175.223.100
84.226.52.5
84.44.135.156
84.44.148.224
85.16.215.148
85.177.92.234
85.179.172.129
85.179.172.129
87.150.45.85
87.151.154.236
87.175.68.16
87.54.210.35
88.70.52.119
88.72.192.53
88.79.231.226
91.39.68.106
91.41.121.254
91.43.153.213
91.48.112.243
91.66.166.174
92.227.198.80
92.78.191.215
93.133.153.189
93.212.13.131
94.222.51.33
95.118.124.123
95.119.162.169
95.90.115.42

A few doubles, but they are from all over the world, unlike our typical listeners.

[karlH]

I've asked balbinus to see if it could be some application bug being tripped up by something unusual (but not invalid) on the directory.

karl.

[audiorapture]

Any result on this? Is there a way to exclude these requests from the log?

[karlH]

I haven't heard back yet. icecast doesn't allow for not logging certain entries unless you disable access log completely (eg /dev/null etc). You can of course cycle the logs and filter out those entries with grep -v or similar.

karl.

[adamsilverstein]

i'm having the same issue - tons and tons of requests for the invalid index.html file - any idea how to turn the logging off for these would be great, are these real requests?

[karlH]

They look to be valid requests coming in but I'm unsure of what is triggering it. There was an issue in the m3u format on the stream directory which _could_ of been a trigger for applications to generate these requests but that has been rectified within the last day.

Adding some sort of filter would limit the logging but won't stop the requests coming in. Does the incoming pattern change if you create a dummy html file in a directory under webroot?

karl.

[audiorapture]

What should that file contain? Would a simply "nothing here" suffice?

[karlH]

it could do, after all it's not going to be used for anything, just to see if the usage pattern changes. You could have url auth setup on it (listener_add) and use the script to add the IP to the icecast deny ip list file or even the firewall

karl.

[audiorapture]

One interesting tidbit is that all requests have the same user agent string:
"Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)"
(basically Windows 2000 with IE5).

Of course, the user agent string is most likely bogus in this case, and I am rather sure this is a botnet on some kind of nefarious mission.

[karlH]

Only the kh tree has a useragent filter file but as you say, it could change the content of that easily and use something that is commonly used.

karl.

[audiorapture]

OK, how do I verify that the filter is working?

I have added the following line (kh18):
# grep deny /usr/local/etc/icecast.xml
<deny-agents>/usr/local/share/icecast/auth/deny-agents</deny-agents>
# cat /usr/local/share/icecast/auth/deny-agents
Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

They still show up in the access log. Is that supposed to happen?