January 28, 2017
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:
This means that you if you want to use other nameservers, you should substitute those IP addresses for the ones you prefer.
- 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)
First, we enter configuration mode and delete existing nameservers:
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 22.214.171.124
set system name-server 126.96.36.199
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 188.8.131.52
set service dns forwarding name-server 184.108.40.206
The round-up is as follows:
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.
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
220.127.116.11 available via ''statically configured''
18.104.22.168 available via ''statically configured''
2. Surf for some inappropriate content
When surfing for some inappropriate content, the result should be:
Mission accomplished :)
January 28, 2017
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
scp ~/.ssh/id_rsa.pub 192.168.1.1:/tmp
On your EdgeRouter
loadkey admin /home/admin/id_rsa.pub
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.
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
January 14, 2017
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
/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
December 07, 2016
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]
September 23, 2016
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 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 :)
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
After generating the 4096 bit DH group, I changed the following parameters in the server block of my nginx vhost config:
The nginx configuration can be checked with
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:
listen 443 ssl default_server;
listen [::]:443 ssl http2 default_server;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
add_header Strict-Transport-Security ""max-age=63072000; includeSubdomains"";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
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.