BitTorrent Tracker DDoS?
-
Last Saturday at nearly exactly 12pm Pacific time, our firewall has come under what appears to be a BitTorrent Tracker DDoS. Thankfully, the attack is not strong enough to saturate our T1 and our little ALIX 2c3 pfSense box, but it is still annoying.
We are seeing a couple thousand TCP and UDP packets sent to port 6969 of the firewall a second from random hosts - total traffic from the attack is somewhat cyclic (goes up and down rather smoothly over time) and varies between 500Kbps and 1Mbps. If you google for BitTorrent Tracker DDoS you will find a couple papers which describe the type of attack that we are under.
We were logging all this traffic and our pfSense box, but after adding a rule to drop the traffic without logging lowered CPU utilization from ~50% to ~25%.
Anyone see this before? I'm guessing there's not much we can do except to ask our ISP to block the traffic upstream or just wait it out.
-
You can drop it at your firewall but that won't limit the load of your line as you only can block it after it used bandwidth at your WAN already. If this really starts becoming an issue ask your ISP if they can block it somehow before it hit's your line.
-
A bit more digging:
I set up a NAT rule to forward the traffic to an internal host so I could analyze the type of traffic.
I found that it is indeed BitTorrent tracker scrapes - and apparently ezard.ma.cx now resolves to the IP address of our pfsense box. Googling ezard.ma.cx turns up tons of hits on shady torrent sites so it's pretty clear that the source is not likely malicious.
I am having some trouble tracking down the appropriate people to contact with the abuse complaint. Any suggestions?
Looks like the ma.cx is registered at cocca.cx and uses DNS servers ns(1|2).yourgsm.com.
Further digging shows that ma.cx is a dynamic DNS provider. Could be that someone on our network caused this - digging further…
-
You could look for one of there update clients.
You could mail them and ask to get your ip removed from ezard.ma.cx
maybe a tracker came as spyware. -
Emails sent to the admins of ma.cx, awaiting their reply.
On a related note - when I set up the NAT rule to forward the traffic to an internal host for analysis, the pfSense box quickly went unresponsive. After trying to get into the web-admin interface with no success, I unplugged the WAN connection and was able to connect to the web-admin and remove the NAT rule.
It appears that the connection tracking table filled up (no surprise with a default of 10k connections and getting hit with a couple thousand connections a second) so the DDoS worked. What can we do to avoid this in the future should a real service get hit with a similar attack in the future? Are there some guidelines to setting the size of the connection tracking module?
-
Never used these 2 options but each firewall rule has :
[1] Advanced Options
[2]State TypeYou can use these to help guard against DOS attacks
-
The administrator of ma.cx have disabled ezard.ma.cx for now.
[1] Advanced Options
[2]State TypeYou can use these to help guard against DOS attacks
Yeah, it looks like that would help… but it could be a bit cumbersome if you were trying to make a firewall more resistant to attacks on all ports and destinations. I'd have to think about a good way to handle some sort of global settings.
What I did find helpful was increasing the number of states the firewall could track. I bumped it up from 10k to 40k and then 64k. The higher the setting, the more responsive the firewall itself remained while under attack and with the state tracking table full.
I was watching memory consumping (the ALIX box has 256MB total) and total free memory didn't seem to change much even when tracking 64k connection. In the past I've seen reports of anywhere from 3k to 1k of memory used by each connection tracked. Anyone know if these are still correct?