Member Avatar for culp

Hi
I am webmaster of a small website called The site is a way for unsigned bands in the Northeast of England to get their music heard and promoted and as such stores around 100 MP3 files of different band's songs. On Friday lunch time the site traffic suddenly spiked with the following file
being uploaded 9136 times in one hour?
mp3Player does exactly what it says on the tin and is embedded in another PHP generated page that has other information about the track and the band. It's not available directly through the site and is not even visible unless somebody looks at the background code on the site? I can find no errors in the code that would continually download the song, just downloads once using about 7mb of bandwidth

The attack appears to have originated in the network of Orange UK in StAlbans but I'm getting no help from them at all.

Does anyone know how I could go about establishing what caused the attack, and how I can prevent direct access to these MP3 files used in the site? I've tried preventing directory browsing but this doesnt prevent access to the individual files.?

  • 2 Contributors
  • 6 Replies
  • 93 Views
  • 9 Hours Discussion Span
  • Latest Post Latest Post by shovels

Dani AI

Generated

A few practical points that build on suggestions and help with immediate triage and longer-term hardening.

The traffic pattern you describe is typical of an automated client hitting a public playback endpoint that accepts a filename parameter. Short term, stop the bleeding: take the hot file offline or change its URL, and block the most aggressive IPs or ranges at the firewall/webserver while you investigate. When you contact the upstream/ISP for abuse help, include sample log lines (timestamp, request URI, source IP, user agent, byte count and request frequency) so they can validate and act quickly.

For a reliable fix, require server-side authorization before any raw media URL is usable, but avoid streaming large blobs directly through application code. After the app validates the request, hand delivery to the webserver (server-level file handoff) so transfers are efficient. Use short-lived, signed URLs or per-session tokens the player must use; this prevents simple scripted reuse of a public link. Add rate limiting (webserver modules, reverse-proxy limits or firewall rules) and an automated ban system (for example, fail2ban-style parsing of logs) to throttle repeat offenders.

Also review the player itself: a player that accepts arbitrary file parameters can be invoked directly by scripts. If possible, migrate away from an exposed SWF-style endpoint to an authenticated HTML5 player or a streaming/CDN solution with tokenized access. These steps lower bandwidth risk and make future abuse easier to block.

Recommended Answers

All 6 Replies

Member Avatar for shovels

Do people have to be registered to access the files?

If you can get the people to register first you could prevent non-registered members from accessing the files at all.

Another option could be to serve the files using PHP, possibly not the best way of dealing with the files, but it will give you a lot more control as you can place the files below the site root, so the only way to access is via a PHP script.

Member Avatar for culp

Hi

Thanks for the reply

No the users don't have to register for the site they can just play the files. It seems the attack was automated in some way, that is I cant think of anyone pressing the refresh button 7,000 times in one hour?

Can you explain abit further what you mean by "serve the pages in php"

My site root (as provided by the ISP) is public_html, everything's in there. If I place the files below that directory that would prevent direct access to the files?

I appreciate the pointers

Alan

Member Avatar for shovels

Hi Alan,

Files below the root folder (public_html) can only be accessed by your scripts - public access is not possible.

For example:
You can't specify

it just won't work.

However you can specify in your php file (which for this example is in your root folder):

$sMusicSrc = '../folder_below_root/';

You can then use PHP's readfile function to get the specified file from your specified folder.

readfile($sMusicSrc . 'filename.mp3');

Now that you're using a PHP file to 'serve' the file you could place restrictions by logging the IP address for example. too many requests for the same file by the same IP address = block it!

I believe that not all browsers submit the IP address in the header, but this, I would have thought would be a minority.

Having said that I have only used this for downloading files, not for playing from an imbedded MP3 player, but I'm sure it would work.

Within your code you would then specify the source to be:
<embed src="phpfile.php?id=b56fe59d70e65730a69ecdae1ab5eb33.mp3" quality="high" pluginspage="http://www.macromedia.com/go/getflashplayer" type="application/x-shockwave-flash" width="150" height="75"></embed>

Member Avatar for shovels

I forgot to mention, I used this with users having to be members (free), but I could check as soon as the php file was requested if the user was logged in. If not then it wouldn't work. It would take them back to the registration page.

Even if someone has the direct link (in the embed section) of your code it doesn't matter because you have ultimate control over who accesses it.

Member Avatar for culp

Thanks for the help I've gone from tearing my hair out to knowing what I have to do, in an afternoon! :icon_cheesygrin:

Member Avatar for shovels

no problems, glad I could be of help.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.