voipmeister.com voip stuff matters and more

DNS forwarding on the Ubiquiti EdgeRouter X

Today I wanted to properly set up DNS forwarding on my Ubquiti EdgeRouter X. More specifically, I wanted to use the OpenDNS FamilyShield DNS servers:

208.67.222.123

208.67.220.123

This means that you if you want to use other nameservers, you should substitute those IP addresses for the ones you prefer.

Setting

  • Ubiquiti EdgeRouter X (EdgeOS 1.9.0)
  • eth0 is the WAN port
  • WAN IP is obtained via DHCP
  • LAN DHCP settings are already in place (DNS points to the LAN gateway IP and DNS listening on the interface is configured)

Steps

First, we enter configuration mode and delete existing nameservers:

configure
delete system name-server

Then, we set the system nameservers (note that these will be used by the system, not for forwarding):

set system name-server 208.67.222.123
set system name-server 208.67.220.123

If the WAN IP adres is obtained via DHCP, you need to tell the router not to update the nameserver configuration:

set interfaces ethernet eth0 dhcp-options name-server no-update

Finally, here”s the most important part:

set service dns forwarding name-server 208.67.222.123
set service dns forwarding name-server 208.67.220.123

The round-up is as follows:

commit
save
exit
release dhcp interface eth0
renew dhcp interface eth0

The last 2 statements make sure that the provider IP settings are being refreshed. On my device, it took some time for the settings to take effect.

Verification

There are multiple ways to verify the setup.

1. Check the configuration

You can check the setup on the router with this statement:

show dns forwarding nameservers

The output should be something like:

-----------------------------------------------
   Nameservers configured for DNS forwarding
-----------------------------------------------
208.67.222.123 available via ''statically configured''
208.67.220.123 available via ''statically configured''
2. Surf for some inappropriate content

When surfing for some inappropriate content, the result should be:

Mission accomplished :)

Use ssh keys with your Ubiquiti user

To secure your Ubiquiti user account, you can add your ssh key to the account.

Assuming your on Linux or macOS, these are the steps (make sure you use the IP address of your EdgeRouter):

On your system

cd ~/.ssh
scp ~/.ssh/id_rsa.pub 192.168.1.1:/tmp  

On your EdgeRouter

configure
loadkey admin /home/admin/id_rsa.pub
commit
save
exit

Unfortunately, this gave me:

Not a valid key file format (see man sshd) at /opt/vyatta/sbin/vyatta-load-user-key.pl line 96, <$in> line 1.

The solution is to take the key part out of your id_rsa.pub file en specify the key and the key type both in the configuration tree.

configure
set system login user admin authentication public-keys user@host key ***KEY-BODY-HERE***
set system login user admin authentication public-keys user@host type ssh-rsa
set service ssh disable-password-authentication
commit
save
exit

Using the macOS builtin tftp server”

Should you ever need a tftp server on your macOS device, you can use the builtin tftp server:

sudo launchctl load -F /System/Library/LaunchDaemons/tftp.plist
sudo launchctl start com.apple.tftpd

The tftp root folder is /private/tftproot

The file /System/Library/LaunchDaemons/tftp.plist holds the configuration.

Stopping the tftp server is as easy as:

sudo launchctl unload -F /System/Library/LaunchDaemons/tftp.plist

Tested and approved’ on macOS Sierra

Generate a file with a specific size

Recently, I needed a file with a specific size. On a BSD or Linux machine, such a file can easily be created. The 50 in the oneliner below means that a 50MB file will be created:

dd if=/dev/zero of=test.img bs=1024 count=0 seek=$[1024*50]

SSL improvement

The report

Recently I decided to enable SSL for my blog. Of course, I checked the quality of my SSL settings, which weren’t too bad, but not A+ either:

The clue is in the report:

This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B.

The cause

The problem is explained in detail at https://weakdh.org. What it boils down to is that by default, a Diffie-Helman group of 1024 bits is generated, which is considered weak by today’s standards.

This is the main reason for the ‘B’ grade. Other SSL configuration parameters are important as well, so read on :)

The solution

Here’s how I remediated this problem. First, I created a 4096 bit DH group:

openssl dhparam -out /etc/ssl/certs/dhparams.pem 4096

The output would be something like:

Generating DH parameters, 4096 bit long safe prime, generator 2
This is going to take a long time
........................................................................................................................
<snip>
.........+.............................................................................................................++*++*

After generating the 4096 bit DH group, I changed the following parameters in the server block of my nginx vhost config:

server {

    ...

    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
    ssl_prefer_server_ciphers on;
    ssl_dhparam /etc/ssl/certs/dhparams.pem;

    ...
}

The nginx configuration can be checked with

nginx -t

Any problems with the configuration will be reported. If you’ve done it right, it shows something like:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Make sure you include all configuration files the right way, otherwise you might be troubleshooting configuration that isn’t actually active at all!

After reloading nginx, all this resulted in the following report:

Close, but no sigar..!

A few more SSL settings need to be modified in order to get the A+ rating. So, I edited the nginx config again:

server {
    listen 443 ssl default_server;
    listen       [::]:443 ssl http2 default_server;

    ...

    ssl_certificate ""/etc/..../fullchain.pem"";
    ssl_certificate_key ""/etc/..../privkey.pem"";

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers ""EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH"";
    ssl_ecdh_curve secp384r1;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;
    ssl_stapling on;
    ssl_stapling_verify on;

    add_header Strict-Transport-Security ""max-age=63072000; includeSubdomains"";
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;

    ssl_dhparam /etc/ssl/certs/dhparams.pem;

    ...
}

Which resulted in A+ (yay):

A lot of information about these nginx settings can be found here: https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html and here: https://cipherli.st.

Mitigating TLS-FALLBACK-SCSV would be possible, if it weren’t for the openssl version on CentOS 7, which is 1.0.1e. OpenSSL 1.0.1 has TLSFALLBACKSCSV in 1.0.1j and higher though.