As you probably saw in our Console and in the other articles, setting up Nooder is quite an easy operation. You usually don't need specific knowledge, as a lot of things work automatically under the hood. But many little mistakes could represent a big risk for your website's security and availability. Let's explore some of them.

Exposing your backend IP address

One of the most common mistake we usually see is exposing the backend real IP to the whole internet. This action could be really dangerous, as grants access to your website to anyone. In fact, a malicious user, could exploit this to make a DoS attack directly to your web server, bypassing all the Nooder features. Our Console will trigger you a warning if you are exposing your IP address (i.e. creating unprotected DNS records with the same target as existings protected records).

But this is not all. Also without exposing your IP address, a malicious user could get it in different ways. Avoiding this is not difficult, and there are many ways to achieve the same goal. Basically, you need to be sure, for each request you get, that comes from the Nooder network. The most convenient method to do this is the rDNS check. As the name states, the rDNS is a PTR lookup for a specific entry of in-addr.arpa domain, which gives back the hostname related to that IP. In our case, the hostname you should check is protected-by.nooder.net.

 #Performing a normal A lookup
 > dig protected-by.nooder.net
 
 ...
 ;; ANSWER SECTION:
protected-by.nooder.net. 600    IN      A       45.138.200.2
protected-by.nooder.net. 600    IN      A       45.138.200.3
...

#Performing a PTR lookup (rDNS)
> dig -x 45.138.200.2

...
;; ANSWER SECTION:
2.200.138.45.in-addr.arpa. 10800 IN     PTR     protected-by.nooder.net.

Now, checking this is not really difficult, but it depends on the web server you are using. We will discuss the basic concept, and then present you some example for the most commons webservers existing.

In short words, for each request you get, you need to perform a double lookup, to be sure it is coming from the Nooder Network. The first lookup should be a PTR one, to check for our hostname (protected-by.nooder.net). It may seem like this is enough, but it is not. In fact, a malicious user can, in some cases, spoof its hostname, making it looks legit while it is not. So, to be sure that the IP address is coming from our network, you should perform an A lookup against the hostname you got from the previous PTR one. If the IP address you get coincides with the IP which made the request, this means it is part of our network, and can be considered safe. Look at this example for a complete recap:

#Got a request from 45.138.200.2
#Performing a PTR lookup (rDNS)
> dig -x 45.138.200.2

...
;; ANSWER SECTION:
2.200.138.45.in-addr.arpa. 10800 IN     PTR     protected-by.nooder.net.

#Seems legit, let's do a forward lookup
> dig protected-by.nooder.net
 
 ...
 ;; ANSWER SECTION:
protected-by.nooder.net. 600    IN      A       45.138.200.2
protected-by.nooder.net. 600    IN      A       45.138.200.3
...

#The IP Address who made the request (45.138.200.2) is part of our network, as
#it is included in this response.

#Got a request from 172.16.10.10
#Performing a PTR lookup (rDNS)
> dig -x 172.16.10.10

...
;; ANSWER SECTION:
10.10.16.172.in-addr.arpa. 10800 IN     PTR     protected-by.nooder.net.

#Seems legit, let's do a forward lookup
> dig protected-by.nooder.net
 
 ...
 ;; ANSWER SECTION:
protected-by.nooder.net. 600    IN      A       45.138.200.2
protected-by.nooder.net. 600    IN      A       45.138.200.3
...

#The IP Address who made the request (172.16.10.10) is NOT part of our network
#as it is NOT included in this response, and should not be trusted.

Now that what to do is clear, let's see how.

In Apache, you can use the mod_access module (for older Apache versions) or the mod_authz_host for the newest ones (2.4+). The documentation is very well explained, but in case you need here are two examples for this last one:

#Example 1
#Let's edit our Apache conf
...
<Directory "/var/www/html">
   ...
   Require host protected-by.nooder.net
   Require local #Enable access from localhost and local IP
   ...
</Directory>
...

#Example 2
#Let's edit our .htaccess (if enabled)
...
<IfModule mod_authz_host.c>
Require host protected-by.nooder.net
Require local #Enable access from localhost and local IP
</IfModule>
...

In nginx, you can use the rDNS module. Unfortunately, this module is not shipped out with vanilla nginx, so you need to compile it yourself. Let's see an example of its configuration:

#Let's edit our nginx conf
...
location / {
    root   /var/www/html;
    
    rdns double; #So a 'double' check is required (PTR + Forward)
    resolver 127.0.0.1; #You can use the resolver you want (i.e. 8.8.8.8)

    rdns_deny ^(?!protected-by\.nooder\.net).*$; #Deny everything is not 'protected-by.nooder.net'
}
...

In Microsoft IIS, you should first add some features:

#From a powershell
> Import-Module ServerManager #Windows Server 2008 R2+
> Add-WindowsFeature Web-IP-Security

And then configure some things from IIS Manager:

  1. Select your website from the connection pane (on the left)
  2. Click on IP Address and Domain Restrictions in the center pane and click EditFeature Settings in the actions pane (on the right)
  3. Check Enable domain name restrictions
  4. Add Allow Entry from the right pane
  5. Specify as domain name: protected-by.nooder.net

So, doing this helped you to secure your website from malicious HTTP traffic. But there's more. Malicious users could also flood your server with other kind of attacks. For this reason, you should not use an IP address which was previously exposed for your website. A good idea, if possible, is to change your IP address, and filter connections with hardware or software tools (i.e. iptables).

Wrongly identifying visitors IP address

Another quite common error, is the way how backend servers identify the visitors IP address. As you may know, Nooder acts as a proxy service, and for your web server it acts as a source for the connections it gets. Here's an example of nginx access log regarding a simple request passed through Nooder Network:

45.138.200.2 - [27/Jun/2020:17:55:29 +0000]
# ClientIP               Date

As you can see, the client IP is an address part of our network, and it does not reflects the visitor one. The real visitor address is stored in a special header, that you can intercept in your application. This header is called N-Real-Ip

Let's print it on our nginx access log:

45.138.200.2 - [27/Jun/2020:17:55:29 +0000] - 172.16.20.20
# ClientIP               Date                   N-Real-Ip

It's right! Now, you can configure you application to take care of this header, or edit your web server configuration, making it "transparent".

In Apache, you can use the mod_remoteip. Here are two examples:

#First of all, we need to activate the remoteip module
> a2enmod remoteip

#Example 1
#Let's edit our Apache conf

<VirtualHost *:80>
...
RemoteIPHeader N-Real-Ip
...
</VirtualHost>

#Example 2
#Let's edit our .htaccess (if enabled)
...
<IfModule mod_remoteip.c>
RemoteIPHeader N-Real-Ip
</IfModule>
...

In nginx, the procedure is a little bit different, and there are also many ways to do so. We would like to redirect you to this great blog post about how to configure it.