Extremely High Data Transfer

mikedunn · 23rd February 2016, 00:44

See the Shoutcast log entry below. A client connection transferred 2GB+ of data in 19 minutes (and appears to be spoofing the user agent, as "Chrome" and "Safari" are both listed in the same user agent string). This has been happening sporadically since I installed Shoutcast a week ago. Considering I'm on Amazon EC2 and paying per GB for outbound data transfer, this is frustrating. I'm streaming at 96k, so I can't even imagine how this much data transfer would be possible.

Obviously this is malicious behavior. Other than blocking IPs that do this stuff, is there anything in the Shoutcast config to deal with this?

Thanks,
Mike

2016-02-22 20:17:16 INFO [DST 91.210.147.72 sid=1] Kicked [Agent: `Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36', UID: 35, GRID: 0]
2016-02-22 20:17:16 INFO [DST 91.210.147.72 sid=1] SHOUTcast 1 client connection closed (1140 seconds) [Bytes: 2029453920] Agent: `Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36', UID: 35, GRID: 0

neralex · 25th February 2016, 22:55

This sounds really strange... Which software you are using to build the source? I guess you have wrong settings for your output. If the source is providing only 96kbit/sec then is it not possible that someone can recieve more in the same time.

2029453920 bytes in 19 minutes

106813364,21 bytes per minute

1780222,74 bytes per second == 14241,78 kbit/sec (1,78 mb/sec)

mikedunn · 26th February 2016, 13:35

Exactly, it's very odd. I use Nicecast at 96k, however I went back to the logs and noticed that the times that this occurred, Nicecast was not connected and Shoutcast was serving a backup file, which is a ~100MB mp3 of a podcast -- which was recorded from a 96k Nicecast stream (so the mp3 itself is also 96k). Me and many other users stream that just fine when the source is not connected.

I assume pulling this much data would not be possible if Nicecast were streaming at the time, but I'm not clear how Shoutcast could be pushing this much data even with a 100MB mp3 backup file.

In the meantime, I've banned these subnets (more than one) and also changed my Amazon Elastic IP.

Thanks,
Mike

neralex · 26th February 2016, 15:57

SHOUTcast server IS NOT an encoder! So check your backup file, maybe it has a higher bitrate and then encode it to 96kbit! sc_serv is using the bitrate of the file which is provided.

dopelabs · 16th March 2016, 02:07

does the reported bandwidth usage from amazon match what shoutcast has reoorted?

23rd February 2016, 00:44	#1
mikedunn Junior Member Join Date: Feb 2016 Posts: 7	Extremely High Data Transfer See the Shoutcast log entry below. A client connection transferred 2GB+ of data in 19 minutes (and appears to be spoofing the user agent, as "Chrome" and "Safari" are both listed in the same user agent string). This has been happening sporadically since I installed Shoutcast a week ago. Considering I'm on Amazon EC2 and paying per GB for outbound data transfer, this is frustrating. I'm streaming at 96k, so I can't even imagine how this much data transfer would be possible. Obviously this is malicious behavior. Other than blocking IPs that do this stuff, is there anything in the Shoutcast config to deal with this? Thanks, Mike 2016-02-22 20:17:16 INFO [DST 91.210.147.72 sid=1] Kicked [Agent: `Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36', UID: 35, GRID: 0] 2016-02-22 20:17:16 INFO [DST 91.210.147.72 sid=1] SHOUTcast 1 client connection closed (1140 seconds) [Bytes: 2029453920] Agent: `Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36', UID: 35, GRID: 0

26th February 2016, 15:57	#4
neralex Major Dude Join Date: Mar 2011 Posts: 576	SHOUTcast server IS NOT an encoder! So check your backup file, maybe it has a higher bitrate and then encode it to 96kbit! sc_serv is using the bitrate of the file which is provided. Last edited by neralex; 26th February 2016 at 18:11.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Switch to Linear Mode Hybrid Mode Switch to Threaded Mode

25th February 2016, 22:55	#2
neralex Major Dude Join Date: Mar 2011 Posts: 576	This sounds really strange... Which software you are using to build the source? I guess you have wrong settings for your output. If the source is providing only 96kbit/sec then is it not possible that someone can recieve more in the same time. 2029453920 bytes in 19 minutes 106813364,21 bytes per minute 1780222,74 bytes per second == 14241,78 kbit/sec (1,78 mb/sec)

26th February 2016, 13:35	#3
mikedunn Junior Member Join Date: Feb 2016 Posts: 7	Exactly, it's very odd. I use Nicecast at 96k, however I went back to the logs and noticed that the times that this occurred, Nicecast was not connected and Shoutcast was serving a backup file, which is a ~100MB mp3 of a podcast -- which was recorded from a 96k Nicecast stream (so the mp3 itself is also 96k). Me and many other users stream that just fine when the source is not connected. I assume pulling this much data would not be possible if Nicecast were streaming at the time, but I'm not clear how Shoutcast could be pushing this much data even with a 100MB mp3 backup file. In the meantime, I've banned these subnets (more than one) and also changed my Amazon Elastic IP. Thanks, Mike

16th March 2016, 02:07	#5
dopelabs Major Dude Join Date: Oct 2006 Location: Silicon Valley Posts: 536	does the reported bandwidth usage from amazon match what shoutcast has reoorted?