RENMX | Forum

Posted: **Wed Jan 15, 2014 10:49 pm**

I apologize for the current downtime but the servers internet connection is currently being attacked with over 120Mb/s of data. I do not yet know who is behind it or their motives but our bandwidth use is off the scale right now.

Posted: **Thu Jan 16, 2014 12:42 am**

QQ Pri fix it

Posted: **Thu Jan 16, 2014 1:09 am**

There is nothing I can do unfortunately. It is using thousands of compromised/misconfigured DNS servers all over the globe as part of the attack. Nothing I can do except wait it out.

Posted: **Thu Jan 16, 2014 1:16 pm**

status Update on this?

Posted: **Thu Jan 16, 2014 1:36 pm**

It is back up the moment after his latest post. No suspects of this were identified.

Posted: **Thu Jan 16, 2014 2:29 pm**

The attack is over and I thought I'd give some information about it. Firstly the server has a 120Mb internet line. It can peak to about 133Mb/s but in general it's about 120Mb-125Mb.

The volume of data we received during the two attacks easily surpassed our line speed. So it was over 120Mb. Here is a graph showing the attack while it was ongoing:

Now you can see the bandwidth use was going nice and low and then boom, attack begins (this is the 2nd one of the night) and instantly bandwidth use spikes up to 16,000KB/s which is exactly 125Mb/s - our line speed. This indicates the attack is much larger than our line speed, but I cannot see just how big it is as we're already maxed out at 125Mb/s

At this speed I'm receiving 15.6MB per second / 56GB per hour. So lets look at how much data I received over the two attacks:

Those two large orange spikes, those are the attacks each of which lasted over an hour. You can see in the bottom right that during just the last 24 hours (which is what the graph shows) I received 131GB of data. This is a lot more than usual. I usually receive about 20-30GB so the attackers essentially sent me around 100GB of data during a 3 hour period last night.

Here is the last couple days of data use, remember the first attack began on the 15th of January and the 2nd attack began on the 16th of January so it crosses over the first two dates.

So who is responsible? Well unless they come forward and say it was them we may never know for sure. This attack wasn't very highly sophisticated but it did make use of a well known problem with the internet, misconfigured DNS servers.

On the internet everyone uses a DNS server, it's how when you type in to your browser "google.com" you receive back googles address which is "62.252.169.152" every single website or service where you enter in a name, those names are being looked up in a database for their IP Address and then that is being sent back to your computer.

Even when you use survival.renmx.com in your game client your DNS server (provided by your internet provider unless you've changed it to another DNS server) sends back our servers IP.

Misconfigured DNS servers, vulnerable ones (remember anyone on the internet can setup a DNS server, even in their home on their own PC if they wanted to) sometimes run completely unrestricted meaning they will send out data to anyone that queries them.

So the way attackers abuse this is by sending them a lookup request for a domain but instead of using their own IP Address in the data packet that they send to the DNS Server they use their victims IP instead. They essentially send a letter with the return address listed as their victims.

So the DNS Server receives this request in good faith and tries to reply to it, but because the attacker has used (in this case) my IP, the response from the DNS Server gets sent to me instead. Now multiply this by thousands of DNS Servers all over the globe and my internet connection is quickly swamped with trash data which is overwhelming my internet connection.

To put it another way, imagine you are trying to make a telephone call but 10,000 people are all trying to call your telephone number at the same time, it would be impossible for you to dial your friend. That is what happened to us with all this incoming data not allowing legitimate traffic (from our players and such) to get through.

There are three reasons why this attack is easy to do and why it is used more and more commonly.

Firstly it is much easier to spoof the IP Address of someone else on the internet using a UDP packet than it is a TCP packet. UDP is connectionless and DNS servers use UDP.
---
Secondly DNS Servers are low hanging fruit there are thousands perhaps millions of unsecured ones all over the globe in offices, homes and data centres.
---
Thirdly the return traffic from the DNS Server can be up to 8x larger than the query sent to the DNS server, so by using this method the attacker actually is able to multiply their attack strength by 8 times. (Attacker 1Gb/s -> 8Gb/s once DNS servers reply)

So that is everything there is to know about what happened. The good news is, our Modem, Router and Server were all running fine, nothing crashed and as soon as the attack ended normal service resumed.

Posted: **Thu Jan 16, 2014 2:39 pm**

I thought I'd just follow this up with a small snippet of some of the data we were receiving during the attack, this is from the DNS Servers:

Code: Select all

Jan 15 22:55:55 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=177.154.154.98 DST=94.174.70.105 <1>LEN=896 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=UDP <1>SPT=53 DPT=10522 LEN=876 
Jan 15 22:55:55 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=182.48.40.228 DST=94.174.70.105 <1>LEN=1054 TOS=0x00 PREC=0x00 TTL=50 ID=15931 PROTO=UDP <1>SPT=53 DPT=57806 LEN=1034 
Jan 15 22:55:55 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=205.234.101.99 DST=94.174.70.105 <1>LEN=267 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=UDP <1>SPT=53 DPT=28820 LEN=247 
Jan 15 22:55:55 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=198.145.181.242 DST=94.174.70.105 <1>LEN=1054 TOS=0x00 PREC=0x00 TTL=51 ID=64071 PROTO=UDP <1>SPT=53 DPT=12611 LEN=1034 
Jan 15 22:55:55 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=205.234.101.99 DST=94.174.70.105 <1>LEN=267 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=UDP <1>SPT=53 DPT=28820 LEN=247 
Jan 15 22:55:55 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=91.121.2.200 DST=94.174.70.105 <1>LEN=896 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=UDP <1>SPT=53 DPT=33077 LEN=876 
Jan 15 22:55:55 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=220.231.180.77 DST=94.174.70.105 <1>LEN=896 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP <1>SPT=53 DPT=46679 LEN=876 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=91.121.2.200 DST=94.174.70.105 <1>LEN=896 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=UDP <1>SPT=53 DPT=33077 LEN=876 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=205.234.101.99 DST=94.174.70.105 <1>LEN=267 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=UDP <1>SPT=53 DPT=28820 LEN=247 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=60.248.187.10 DST=94.174.70.105 <1>LEN=214 TOS=0x00 PREC=0x00 TTL=40 ID=0 DF PROTO=UDP <1>SPT=53 DPT=31295 LEN=194 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=121.119.187.49 DST=94.174.70.105 <1>LEN=56 TOS=0x00 PREC=0x00 TTL=43 ID=0 DF PROTO=UDP <1>SPT=53 DPT=44318 LEN=36 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=205.234.101.99 DST=94.174.70.105 <1>LEN=267 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=UDP <1>SPT=53 DPT=28820 LEN=247 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=172.246.128.54 DST=94.174.70.105 <1>LEN=56 TOS=0x00 PREC=0x00 TTL=111 ID=21564 PROTO=UDP <1>SPT=53 DPT=35218 LEN=36 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=205.234.101.99 DST=94.174.70.105 <1>LEN=267 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=UDP <1>SPT=53 DPT=28820 LEN=247 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=202.152.1.74 DST=94.174.70.105 <1>LEN=896 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=UDP <1>SPT=53 DPT=18514 LEN=876 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=212.205.128.2 DST=94.174.70.105 <1>LEN=896 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=UDP <1>SPT=53 DPT=22696 LEN=876 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=60.248.187.10 DST=94.174.70.105 <1>LEN=214 TOS=0x00 PREC=0x00 TTL=40 ID=0 DF PROTO=UDP <1>SPT=53 DPT=31295 LEN=194 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=46.171.38.202 DST=94.174.70.105 <1>LEN=896 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=UDP <1>SPT=53 DPT=2407 LEN=876 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=177.154.154.98 DST=94.174.70.105 <1>LEN=896 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=UDP <1>SPT=53 DPT=10522 LEN=876 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=177.154.154.98 DST=94.174.70.105 <1>LEN=896 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=UDP <1>SPT=53 DPT=10522 LEN=876 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=188.168.8.89 DST=94.174.70.105 <1>LEN=896 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=UDP <1>SPT=53 DPT=33843 LEN=876 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=202.152.1.74 DST=94.174.70.105 <1>LEN=896 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=UDP <1>SPT=53 DPT=18514 LEN=876 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=99.187.110.105 DST=94.174.70.105 <1>LEN=267 TOS=0x00 PREC=0x00 TTL=43 ID=0 DF PROTO=UDP <1>SPT=53 DPT=36060 LEN=247 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=198.145.181.242 DST=94.174.70.105 <1>LEN=1054 TOS=0x00 PREC=0x00 TTL=51 ID=64075 PROTO=UDP <1>SPT=53 DPT=12611 LEN=1034 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=60.248.187.10 DST=94.174.70.105 <1>LEN=214 TOS=0x00 PREC=0x00 TTL=40 ID=0 DF PROTO=UDP <1>SPT=53 DPT=31295 LEN=194 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=182.48.40.228 DST=94.174.70.105 <1>LEN=1054 TOS=0x00 PREC=0x00 TTL=50 ID=15939 PROTO=UDP <1>SPT=53 DPT=57806 LEN=1034 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=202.232.97.130 DST=94.174.70.105 <1>LEN=436 TOS=0x00 PREC=0x00 TTL=50 ID=0 DF PROTO=UDP <1>SPT=53 DPT=57869 LEN=416 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=177.154.154.98 DST=94.174.70.105 <1>LEN=896 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=UDP <1>SPT=53 DPT=10522 LEN=876 
Jan 15 22:55:56 kernel: DROP <4>DROPIN=eth0 OUT= MAC=xx <1>SRC=177.154.154.98 DST=94.174.70.105 <1>LEN=896 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=UDP <1>SPT=53 DPT=10522 LEN=876

Now the reason we know this attack is from DNS Servers is because every single IP in the attack above is an open DNS Server and the port number they are sending data on is 53 and the protocol is UDP. DNS Servers reply on Port 53 with a UDP packet.

The DROP thing in the log simply means that the router detected it was a DDoS attack and so dropped the packets and didn't do anything with them. The DST= address is my IP Address which is where the attack was heading to. The only thing I removed from the log was my ethernet MAC address as it isn't important to the data.

Posted: **Thu Jan 16, 2014 3:10 pm**

damn kids and their e-shenanigans

Posted: **Thu Jan 16, 2014 4:45 pm**

Thanks for all the useful information Pri. I enjoy the way you explain things.

Posted: **Fri Jan 17, 2014 12:35 am**

Aliens? If you print it all out onto 100's or pages of A4 and then arrange them in a pattern on the floor maybe it will be the image of another life form!

RENMX | Forum

Server down due to DDoS

Server down due to DDoS

Re: Server down due to DDoS

Re: Server down due to DDoS

Re: Server down due to DDoS

Re: Server down due to DDoS

Re: Server down due to DDoS

Re: Server down due to DDoS

Re: Server down due to DDoS

Re: Server down due to DDoS

Re: Server down due to DDoS