Minecraft DDOS protection part 2: Cloudflare

So we’ve set up our GRE tunnels and redirected all of the minecraft traffic hitting our VPS’s down their respective tunnels. The only problem is that there’s nothing to distribute players between all our VPS’s, which is where DNS records come into play. And while we’re at it we’ll protect our website too.

Before we continue, I don’t work for cloudflare, I’m not getting paid by them, and I’m not too keen on some of their slightly over the top marketing. With that said, here’s why I’m using them:

Why cloudflare?

Fast

Cloudflare use an anycast DNS network so the nearest DNS server to you is the one that responds, you can read more about it here

Free

Their basic plan covers everything we need to do, and is completely free.

Easy to use

I’ve bought domains from a few companies, and cloudflares web interface has to be the nicest I’ve seen, their API is also well documented and easy to work with.

Extras

Cloudflare performs some caching, lowering the bandwidth and resource usage of your site, provides analytics for you with zero setup, and if your site goes down, it will host a static cache of your web pages where possible.

Website Setup

There are a few options for website protection setup depending on your web server location:

Hosting website on the same server as minecraft:

Cloudflare isn’t required here, you can simply duplicate your VPS’s iptables rules and replace 25565 with 80, forwarding the web requests through the tunnel to the protected server. With that said I’d still recommend going with cloudflare for the reasons above.

Hosting with another provider:

Since you’re using a different connection and IP, attacks on the minecraft server won’t affect the site and don’t expose the MC server IP. However your website could still be attacked, and if your host doesn’t provide and DDOS protection, you may as well use cloudflare’s.

Hosting on another server on the same connection

This is the situation I’m in, my webserver sits behind a firewall, on the same LAN and internet connection as my MC server. I can’t use my tunnels to forward traffic as their endpoints sit on the wrong server, and leaving the webserver on the global IP will leave that IP exposed to attackers.

Moving to cloudflare

To use cloudflare for your domain you need to need to change your nameservers with your registrar, cloudflare has covered how to do this with the most common registrars here.

Once that’s done it will take a while to move over, in the mean time cloudflare will provide you with a list of subdomains it’s picked up automatically, and it allows you do decide whether or not to use cloudflares network to protect them. It also adds an extra “direct” subdomain which is set to bypass their network. I would recommend removing this since anyone that knows you’re using cloudflare, or simply guesses that you might be, can use it to try and get your real IP. Everything else on their site is well documented so I won’t go over it again.

Adding records

Adding A Records

To start with, we need to add an A record for each VPS, so that instead of IP’s, we have a nice readable subdomain we can point our SRV records to, for example “minecraft.itschr.is”. This is as easy as clicking “Add” and then entering the new subdomain name and IP.

Adding SRV records

Since the domain pointing to our website is now sitting behind a cloudflare IP and not our server IP, and cloudflare doesn’t support forwarding MC traffic, we need to add extra information to tell the players’ Minecraft client what to do when trying to connect to our domain.

SRV records enable us to point our domain to an alternative A record, and even tell the players’ client an alternative port to use to connect.

Wikipedia’s description covers SRV records better than I can, so I’ll just focus on what’s important to us.

  • name

This is location that the client must connect to to receive this SRV record: if set to “@” it will be the domain (itschr.is,) if set to anything else it will be a subdomain (minecraft.itschr.is.)

  • target

Where the SRV record redirects the client to, in this case our VPS’s A record

Result

Now if we add multiple SRV records with the same name, cloudflare will rotate through each target, serving up a new one every time the TTL expires.

Lets say we have 2 VPS’s in the US, and 2 in Europe. We can create an SRV record for each VPS, and player connections will be distributed across all of them. On top of that, we can also pair the US servers together under under a “us.itschr.is” subdomain, and the EU servers together under “eu.itschr.is.” This then allows the players to use a server nearer to them for general use (faster ping but lower attack-redundancy) and still use the main domain if they have issues connecting.

If an attacker takes out a single VPS, it will only affect players connected via that VPS, or players being served that VPS address through SRV records (which will change after the 5 minute TTL)

That’s all for now, I’ll come back to this later and talk about how we can lower the TTL further, and automatically remove the SRV record of a VPS under attack.

Expanding a partition on an Ubuntu KVM VM

For next time I need to do this, and forget how, the easiest way to expand a partition inside a KVM virtual machine is to:
1. Boot onto an Ubuntu Live CD.
– Add a virtual CD drive if there isn’t one already, I used an ubuntu desktop iso, but anything with GParted will do.
– Set the boot priority to try the CD drive first.
– Reboot the VM2. Resize the Partition
– Open up gparted
– Move any partitions that may be in the way of the one you want to expand
– Expand the desired partition
– Apply the changes

3. Resize the Filesystem
– Remove the CD drive/change the boot order to boot from the hard drive again
– Reboot the VM back into the Native OS
– Run resize2fs with the drive you need to expand, eg resize2fs /dev/sda1

Done!

RAID on Intel servers

Managed to source a couple of 750gb drives for my server, thought I’d drop them in and run RAID 1, but as usual I faced a number of difficulties:Drives didn’t show up.
The drives didn’t show up after I plugged them in, turns out the server doesn’t support hot swapping so I had to go and reboot it, while I was there I checked out the BIOS to make sure the ports weren’t disabled and to enable RAIDCan’t access the RAID ROM
So this server has an Intel board which has an option in the BIOS to enable RAID on the SATA drives, however after enabling it I couldn’t find any way to actually access the RAID manager, it just went straight to trying to network boot. Turns out that to see the RAID ROM you have to disable Intel Quiet boot in the BIOS first.

Can’t boot from the none RAIDed drive.
So I finally got into the RAID manager, set the two new disks to RAID 1, and restarted. Then I remember that I’d need to set it to boot from RAID in the BIOS, and then choose a boot disk from the RAID ROM. Problem with this is you can’t select the none RAIDed drive as it isn’t a virtual disk, and the only way to make it a virtual disk is to add it to an array. Strangely enough the way to get it working was to set the disk up as a single disk RAID 0 array, and then I could select it as the boot drive.

All this turned out to be in vain as not only was Linux unable to observe the drives as a single RAID array, instead seeing them as separate drives, but the second of the two drives was also dying and useless. Woop!

MineOS on KVM

So after about an hour of trying to work out why I couldn’t see any ethernet adapters in my new Minecraft virtual machine, I eventually discovered that it’s a problem with MineOS not supporting the para-virtualised network adapter that KVM provides. The fix for this was to change the adapter from virtio to e1000, for some reason rtl8139 doesn’t work despite being pretty well supported.

Raspberry Pi getting started.

Finally got my Raspberry Pi today. Installation went surprisingly well, only issue was my complete lack of experience with Linux.

I wanted to try out a few different things with the RPi, the first of which was its feasibility as a thin client. After some quick googling I discovered rdesktop, a program to connect into windows remote desktop sessions.

Here was my first stumbling block, it seem that I needed root privileges to install things, and I had no idea what the password was. Turns out that’s because there was no password, and I needed to set it using:

“sudo passwd root”

Ace.

So I installed rdesktop, ran it, and fairly painlessly logged into my windows remote desktop.
The next issue was the program resolution, which I discovered can quite easily be changed by either specifying a percentage (“-g 90%”) or using fullscreen (“-f”) tags after the server location.

The raspberry pi itself, however, was not using the full resolution of the screen.

After yet more searching, I discovered that the correct mode can be found by typing

“/opt/vc/bin/tvservice –m DMT”

And finding the one that matches your resolution.
This mode can then be added to /boot/config.txt (create it if it isn’t there) as:

“hdmi_mode=58”

Changing 58 to your relevant mode found from the above list.

This, unfortunately, didn’t solve anything, and I still had large black borders around my screen.
After some desperation, I finally added “disable_overscan = 1” to the config file, and low and behold, despite having no other overscan parameters defined, it worked!
Turns out either rdesktop or the RPi is quite laggy, so I’ll be testing a few other programs next.