RSS
 

Posts Tagged ‘how to’

How to Hide your Servers Origin IP Address

23 Apr 2018

Overview

One project I maintain is frequently targetted by DDoS attacks. The power behind each attack ranges from weak attacks (100 Mbps) to very strong attacks (100+ Gbps). This project is essentially a side project and as a result I cannot afford to set up expensive DDoS mitigation solutions with failover servers. I suspect there are many that also face the same situation. A long time ago I decided to do everything I could to hide my servers origin IP in hopes of preventing my cheap web server from being bombarded with malicious traffic. The results from these changes have been fantastic!

Below is a summary of all the changes I made to hide my servers origin IP address for this project.

CloudFlare

Cloudflare Logo

One of the first changes I made was moving over my website to CloudFlare. CloudFlare provided me with many benefits (and all for free!). Not only did CloudFlare mask my servers origin IP by routing requests from users to my server, they also reduced my overall bandwidth costs and provided fast file caching.

The primary reason I signed up to CloudFlare was to mask my servers origin IP. Instead of pointing my domain to my origin server, I instead point my domain towards CloudFlare’s servers. CloudFlare then forwards user request to my origin server and my origin server replies to CloudFlare with a response. Finally, CloudFlare sends the response back to the user. During the initial connection between the user and CloudFlare, CloudFlare can handle malicious traffic it detects and may present users with a CAPTCHA to verify they are human. If the checks fail the request is denied and the traffic never reaches your origin server.

CloudFlare Overview

Firewall Whitelisting

Now that CloudFlare is set up and working, our web server should only be contacted by CloudFlare (and perhaps other services you use). SSH into your server and configure your firewall to only allow CloudFlare IP’s inbound/outbound access. CloudFlare’s IP ranges are available here and rarely change.

HTTPs

Another change you should definitely make is using HTTPs only for the connection between your server and CloudFlare. Make sure you use Full (strict) mode under the Crypto > SSL section in the CloudFlare dashboard. If you didn’t already know, you can get a SSL certificate for free and automate renewal easily using Let’s Encrypt. So there is no real reason to not make this change.

Cloudflare Crypto SSL Dashboard Very Strict

DNS Record

DNS Records can leak the origin IP if the origin IP appears in any records. In my case, I had a A  record called server pointing to the origin IP which had to be changed.

Mail Server

Hosting mail services on the same box as your web server is another problem. Mail servers will not trust mail that fails to pass certain anti-spam checks. Emails that are missing various headers like  X-Originating-IP  will likely not be trusted. Servers that don’t have the correct mail DNS records pointing to the origin server will not be trusted. Servers that fail a reverse DNS lookup will not be trusted. Typically a mail server will lookup the name of your mail server mail.example.com, retrieve its IP and compare it to the connection IP, then perform a reverse DNS lookup on that IP (using the PTR record) and ensure it points to the mail server name.

One solution here is to not run a mail server.
Another is to send your emails knowing they will be untrusted by mail servers (meaning they will always be sent to the spam folder or might not reach their destination at all).

However, if you need proper trusted mail services you must use an external mail service. Unfortunately, almost every external mail provider will include your origin servers IP address in the  X-Originating-IP header field to deter people from using their services to deliver spam. This means an attacker simply needs to get your web server to send an email (via the external mail provider) to retrieve the origin IP by inspecting the RAW email message.

Raw Email Message Origin IP

After some research, I discovered that Amazon Simple Email Service (or Amazon SES) did not include the  X-Originating-IP header field in outgoing mail. However, to ensure email services were not being used for spam, Amazon required you to verify your domain. Furthermore, Amazon monitor your bounce back rate and your complaint rate. If either metric creeps too high then your account status may be in jeopardy which may lead to service termination.

Outbound Requests

A very common issue is that may websites make outgoing requests to user provided endpoints. Making a request to a server you deem safe is fine (i.e. trusted APIs, another server you own) but user input SHOULD NEVER BE TRUSTED! In my case, users on my website could create an account and upload an avatar. Alternatively, they could enter the URL of an image on the web and my web server would fetch the image, store in locally and then use it as that users avatars. The problem here is that its not CloudFlare making the outgoing request, its your origin server. Therefore, an attacker could set up their own web server, enter a link to an image they are hosting, then look at their web server logs to see which IP just accessed their image. That IP is your origin server IP and is now leaked!

The simplest solution here was to not provide the alternative method.

Leaking Client IPs

One additional consideration to make is protecting the IP of your users. If users on your website can make posts and share content that is retrieved separately by the client over HTTP rather than sent by the origin server in the RAW HTML (i.e. images specified in an <img> tag), then they can steal the IP of any user that views that content. A user will load a page with the content on it, they will receive the RAW HTML payload from CloudFlare, next their browser will fetch any external references (i.e. to images in <img> tags) using the clients connection, thus leaking the clients IP to the external server hosting the content.

One solution to this is to use an image proxy which routes all images through your web server.
I ended up using camo as my image proxy which is open source and very easy to set up.

With an image proxy, all links to images are replaced with link that looks like this:

The image URL is then decoded (using a shared secret key) to retrieve the original external image which is then provided to the client via the origin server.

This protects the clients IP but we’ve just leaked the origins server IP.
To solve this, you will need to use a whitelist of trusted external websites that can be used to source images.
For example, you may only allow images be posted from imgur.com.
This may be a slight inconvenience to users but it protects both their IP and the servers origin IP.

Software Vulnerabilities

This is one is pretty obvious but stay up to date with security patches for any software you use and for the box itself.

Changing your Origin IP One Final Time

After making all the above changes, it will likely be necessary to change your origin IP by requesting a new IP from your server provider. This is because there are many websites out there that store historical DNS record information. Some in particular target CloudFlare protected websites. This change is especially required if you were already being attacked as the attackers will already have the servers origin IP and thus your new leakage prevention solution won’t matter.

Keep in mind that clever attacks may still find your new origin server IP using your old origin server IP. If your webserver displays your website when accessed directly by IP, an attacker could assume a newly allocated IP might be on the same /24 or /16 subnet. It would take no time at all to write a web scraper in Python to iterate over all IP’s in that range to search for a server that is responding to HTTP/HTTPS requests and has your logo (or any other identifying information) in the HTML source code. One way to help stop this is by disabling direct IP access to your website or by displaying a simple forbidden page for all direct IP accesses.

Impact

After making all of the above changed, I noticed a massive improvement. Prior to making the changes I received one medium size attack every 3 months. These attacks would take down my website and leave it down for the majority of the day until the attack stopped. After making these changes, I have received almost no significant attacks over the past 3 years. I did receive 1 very large attack that caused some disturbance but the web server still remained online throughout the attack. The best part is I’m only paying $20 for my server a month which is amazing given its overall traffic and the frequency of attacks. On the other hand, a proper DDoS mitigation solution with failover servers would cost hundreds a month and is only really viable for business solutions rather than side projects.

Overall, I’m very happy with the results.

 
1 Comment

Posted in Server Management

 

Creating an Extremely Strong and Unique Password

10 Dec 2015

In this post I’ll give you a method to create a really strong and flexible password.

Now i’ve personally only gone through 5-6 passwords in the last 8 years. The first 2 passwords were insanely weak (6 digit numbers!). I then started picking stronger passwords but unfortunately I’ve had to change my password multiple times due to database leaks on websites i’ve joined.
However, my current password fixes all of these problems!

Desirable requirements for passwords

  • No dictionary words or simple phrases (so no QWERTY or password!)
  • No obvious patterns (ie 12345679, abcdef)
  • No obvious substitutions (ie hello -> he11o)
  • Length greater than 8
  • Length lower than 16 (unfortunately password length limits exist on many services so this is needed)
  • Starts with capital letter
  • Contains 1+ capital letter
  • Contains 1+ number
  • Contains 1+ special characters
  • Easy to remember
  • Unique for every website
  • Can be used with systems that make your password expire (without need for a new password)

The password we will make will meet all of the criteria above!

Step by Step Guide

  1. First, pick an easy easy to remember dictionary word or a phrase that means something to you. Make sure it is around 5-6 characters long. As an example, I will secure.
  2. Chose a position to split the phrase on. Don’t just split the phrase at its syllables! I’ll decide to split at secu so I have secu and re.
  3. Now capitalize the first letter in the first string. So se becomes Se. (This is so we meet the start with capital requirement on many websites)
  4. Now pick two 2-3 digit numbers. I’ll pick 101 and 42. Add these in between your strings! Thus far we have Secu101re42 (length 11)
  5. Now pick a few other lowercase letters and capitalise them. I go with: SecU101Re42
  6. At this stage, all we need is 1-2 special characters. I decide to go with # and add it in somewhere: SecU101#Re42.
    The password is already a very strong password at this stage but still fails to meet the unique requirement.
  7. For the unique requirement, you have to come up with a system for creating unique passwords for each service you use. I came up with the following, look at the domain of the website you are using and take the first 2 letters from the domain. So on facebook.com you would take fa. Capitalize the first or last letter of this. Then add this to the start or end of your password or put 1 character at the start and 1 at the end. I decide to capitalize the last letter and put the 2 characters at the end of my password. So our password for Facebook is: SecU101#Re42fA ( length 14). The benefit of this is that even if someone manages to get your plaintext password on a service, they are unlikely to notice your system and will be unable to access your other services.
    Note: You can also use a 2 letter prefix that works with many websites so Facebook becomes fb. Furthermore, you can vary the length of the tag for each service as this will also make your password vary in length from service to service which is another bonus!
  8. If your password expires on a service and you are not allowed to reuse the password again, simply add the year, semester, term, quarter or something similar to the start or end of the password. I usually add the year to the end: ie 15 for 2015

Remembering your password…is easy!

I came up with this system in such a way that remembering the password is no issue at all. Most people fail to remember passwords because they have so many different ones across various services. In our case, the domain gives you a tiny bit of the password. All that left to remember is your phrase (in our case secure), the selected split position, the few letters that are uppercase and two 2-3 digit numbers. It turns out that this system is very easy to remember. Simply typing your password over and over again for 2 minutes will get it stuck in your head and then you can begin using it on all of your services.

Password Strength

I put the above password through various password strength websites. The passwords do very well in these tests.

Here are some results from online tests:

The Password Meter

How Secure is my password Dot Net

My1login Password Checker

Final thoughts

Again these passwords are great because they are unique for every service you use (a few may clash but that is generally not an issue, however ensure you keep the number of clashes to a minimum and ensure important websites DO NOT clash). If your password gets compromised on a service you can rest easy knowing all your other passwords are secure.

Just for fun, there are the SHA1 sums for the password we created together below. If one hash gets compromised, the risk is almost nothing. If one plaintext password gets compromised, the risk is low if automated tools are used (often the case with large database leaks for major services). If someone is targeting you specifically, then it will take them a while to figure out your system but chances are they won’t.

Oh and my password isn’t the password above so don’t try to hack me 😀

 SHA1 sums for our password on various services

 
1 Comment

Posted in Security

 

How to get an A+ on Qualy’s SSL Labs Server Test (Apache)

27 Nov 2015

The SSL Server Test by Qualy’s SSL Labs is an easy way to determine how secure your SSL set up actually is.

You can run the test at: https://www.ssllabs.com/ssltest/

This is the score for this domain/server:

MoBeigi.com SSL Server Test

How to get an A+ score on an Apache HTTP server

The default Apache configuration for websites running HTTPs leaves your set up vulnerable to a variety of attacks. So you will need to modify the configuration file for your SSL enabled website.

First navigate to the httpd.conf file and open it in your favourite text editor. In my case this file was located at: /etc/httpd/conf

Navigate to the VirtualHost line that corresponds to the SSL enabled website.

Here is where we add all on configuration options. I’m not going to explain what each option does but do research that if it interests you.

The important configuration options we set are: SSLProtocol (disable SSLv2 and SSLv3), SSLHonorCipherOrder (Beast attack), SSLCipherSuite (support wide range of secure protocols) and HTTP Strict Transport Security. Obviously, replace the placeholder paths, server name (example.com) and file names.

Thats it!
Now restart your apache server ( service httpd restart ) and run the test.

 
No Comments

Posted in Server Management