DNS Filtering with EMnify Cloud Connect and AWS Route53

20.08.2021
guide-image

IoT devices come in various shapes and sizes. And with that, security can vary from device to device depending on the platform, components, OS, firmware and application. In this post, I will use a mobile phone (Android/ iOS) as a payment terminal and outline how you can use DNS filtering to restrict internet access on all such devices in a centralized way.

The recent pandemic has forced businesses world wide to move to cash-less and contact-less payment options. (Well, maybe Germany didn't get the memo. We love cash here!) This is where mobile devices as a payment terminal come across as a cheaper, quick to implement alternative. Buying generic mobile devices and turning them into payment terminals has its own problems. You have less control over the hardware security aspects. You don't have much control over the software security either unless you write your own OS after wiping the existing one. What you can do though is manage the internet access to and from these devices while making sure that communication to your server is secure and undisturbed.

DNS filtering is a convenient technique to restrict this data access from the mobile devices. Normally you'd have to install standalone DNS filtering services on all of these devices individually. Managing and maintaining these can be a nightmare once they are shipped. With the EMnify Communication Platform, you can manage and maintain this DNS filtering from your SIM network in a centralized way. You do not need to install DNS servers on every device, but can do this by maintaining just one list of the websites you want to filter.

Moreover, DNS servers can otherwise be easily attacked through DDoS  if these endpoints have a public IP. With EMnify Cloud Connect, we are going to establish connectivity to a private DNS server, further securing your network. Let's dig into how exactly this is done.

DNS_Filtering_Architecture

But First..

First things first, get yourself a free EMnify account and an IoT SIM. You can also try this experiment with our developer eSIM.

Step 1 : Set up a Transit Gateway

For implementing web filtering, we will be running a DNS server in your AWS VPC. But you do not want this server to be accessible by all. So as a first step, we will be using a Transit Gateway to create a secure and private connection between the EMnify network and the subnet in your VPC where this DNS server will run. To set-up the Transit Gateway, refer to this integration guide.

Step 2 : Route 53

AWS has recently launched the Amazon Route 53 - its DNS service which can resolve domain names. We will be using this service by redirecting all queries coming from your devices using EMnify SIM cards. You can check the pricing for Amazon Route 53 here. Go to your AWS console and navigate to the Route 53 service page.

Click on Get Started > Configure DNS Resolvers.

Screenshot 2021-08-19 at 11-29-46-png

In the Basic configuration, select the option Inbound only. IMG. We will be forwarding the DNS queries originating in our SIM cards into this resolver. This is why we need to configure an endpoint that allows DNS queries to the resolver in this VPC.
Next give it an appropriate name and select the VPC and subnet and availability zone where you created the Transit Gateway in the previous step. Select the security group that you created in the Transit Gateway step which allows inbound access from the IPs of your EMnify SIM. Let the IP addresses for these endpoints be assigned automatically.
Screenshot 2021-08-19 at 10.39.16
Once submitted, it can take some time to create the end points. Once created, you will find them in the Route 53 portal, under Resolver > Inbound endpoints.
Note down the IP address of these endpoints.

Screenshot 2021-08-19 at 10.44.39

Step 3 : DNS forwarding

Now that we have created these two resolver endpoints we need to assign this resolver as the main DNS resolver for your EMnify SIM card. So login to your EMnify account and under Device Policy, select the policy attached to your devices.

Click on More Options > Custom DNS
Now add the two endpoint IPs you created in the previous step.

Screenshot 2021-08-19 at 10.54.28

Click on Select to select the custom DNS. Reset the connectivity of your devices and check if you can still access the internet. If you are checking this on a Raspberry Pi or a similar device, type the following command in your terminal and it should reply to you with the IPs of the new DNS resolvers.


$ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 172.31.16.124
nameserver 172.31.16.223

Step 4 : Creating a list of domains

Now that you have successfully forwarded your DNS queries to this custom DNS resolver, we need to create a list of websites you want to block. In my use-case, I want to block the usage of YouTube so that the devices don't consume a lot of unnecessary data.
Go back to your Route53 portal and navigate to DNS Firewall > Domain lists
Click on Add domain list. Give it a name and enter the domain names you want to block. Here I have entered "youtube.com" as well as "*.youtube.com" to block any sub domains. Save this list.

Screenshot 2021-08-19 at 11.04.59

Step 5 : Blocking the list

Now that you have created the list, you need to create a rule to block all the domains in this list. Navigate to DNS Firewall > Rule groups and add a new rule group.
Give it a name. Now in this rule group, you can add several rules to block, allow or alert when DNS queries are made.
Create a new rule > call it BlockYouTube > Add my own domain list.
In Actions > select Block and add the rule.

Screenshot 2021-08-19 at 11.39.31

Step 6 : Associate Rule to VPC

Now we need to associate this rule group to our VPC where the resolver endpoints are. So select the rule group you created and click on VPCs associated.
Click on Associate VPC and select the VPC where the DNS resolver is. This could take a minute to associate. Once the status is updated to Complete, you are done.
Screenshot 2021-08-19 at 11.42.21
Open your phone with the EMnify SIM to check whether you can still access YouTube. If you are on the RPi, type the following command and you should get no response.

$ host youtube.com

So you have successfully implemented DNS filtering using the EMnify platform. By doing this just once, you have implemented this filtering for all your SIMs. You can also do this if you want to restrict your devices to only specific domains. In this case, you would create an ALLOWLIST instead of a BLOCKLIST.
Let me know if you were able to implement this or if you have any questions. If you want to suggest new use-cases or read more of them, subscribe to our developer newsletter below.
Stay Connected!

Related Posts

Image for post LwM2M vs MQTT: Which one is the best for IoT Solutions?

LwM2M vs MQTT: Which one is the best for IoT Solutions?

While building IoT solutions, keeping the footprint small is of utmost importance. This requirement influences all design aspects of IoT solutions, including communication. Transferring data from your IoT devices to your application servers efficiently is important, but at the same time, you also need to have a lightweight way of doing so. In this post, I will compare MQTT and LwM2M communication protocols for IoT solutions. What are Communication Protocols? Simply put, communication protocols are rules that define how two connected systems communicate with each other. These protocols cover everything from authentication, signalling, security, data transfer, flow control to error detection and handling. The Internet of Things drives innovation in these protocols to make them more efficient and secure among other things. What is MQTT? MQTT stands for MQ Telemetry Transport where the MQ part comes from an IBM product called the MQ Series. MQTT is a protocol that was specifically built for M2M and IoT message transfer by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom). The protocol helps transfer messages using the publish and subscribe model which enables it to send messages to one or multiple subscribers. What is LwM2M? LwM2M stands for Light Weight M2M. It is a protocol designed by OMA SpecWork’s for device management but is also suitable for data transfer with the objective of attaining reduced power and data consumption. It is built on top of CoAP (Constrained Application Protocol) which increases its bandwidth efficiency. LwM2M has a transport agnostic design which by default uses UDP, but also supports TCP and SMS. Architecture MQTT As mentioned, MQTT has a publisher and subscriber model. There is no direct connection between the sender of the message and the receiver. There are 2 basic components in this architecture. Client Broker Clients can publish messages on topics to the broker. The broker then dispatches these messages to any clients that subscribe to that topic. Thus the broker decouples the publisher and the subscriber. MQTT brokers do not normally store messages, but do offer buffering of messages in some cases. MQTT uses TCP/IP to connect to the broker. The broker authenticates and authorizes the clients and maintains the session data of all active clients. The broker is responsible for receiving all messages, filtering the messages, determining who is subscribed to each message, and sending the message to these subscribed clients. LwM2M In an attempt to standardize device management and telemetry, LwM2M supports device management functions, in addition to data reporting (as MQTT does). Bootstrapping Device Configuration Firmware Update Fault Management Configuration & Control Reporting For all the above functions there are procedures defined, e.g. how the device registers at the server, or how the server initiates a client diagnosis. The common structure under all the above functions is a client - server model. The client initiates the connection with the server. The server then uses REST APIs to perform either of the above functions. Implementation MQTT An MQTT client can be any device that runs the MQTT library and connects to the MQTT broker and can have a very small footprint depending on the library used. An MQTT client usually sends data to the server, such as telemetry data. It contains scripts to publish messages to a topic. There are several MQTT client libraries available depending on your preferred programming language. An MQTT broker is the heart of this protocol and can handle millions of MQTT clients depending on the implementation. An MQTT broker needs to be highly scalable, integrated into your backend systems, and failure-resistant. The broker needs to receive, filter and forward all messages to the clients that subscribe to them. As mentioned earlier, it needs to maintain the data-sessions of all the clients connected to it. There are several implementations of the MQTT broker available as open-source or paid. LwM2M Depending on the function that you are using it for, there can be several implementations of the LwM2M client and server. The LwM2M client initiates a connection with the server. LwM2M uses a simple resource model with the core set of objects and resources defined in the specification. As an example, the device here is an object, with id 3 and the device has resources like firmware version, serial number, etc. which have a fix resource id. So to get information about a particular resource of the object device, the server can send a call like READ 3/3/0. The LwM2M client implementation contains code to initiate the connection with the server with credentials, sending the necessary data requested by the server, callback functions for LwM2M resource executions and send error events. It can also contain other functions depending on the use-case. The LwM2M server on the other hand needs to authenticate LwM2M clients, send correct requests using the REST API and process the requested information. There are several open-source as well as paid implementations available for the LwM2M client as well as server. LwM2M also has a Developer Toolkit which can be used to implement your own versions. Security MQTT MQTT supports various authentications and data security mechanisms. These mechanisms are configured on the broker and the client needs to comply with these mechanisms. MQTT uses TCP/IP and you can also leverage Transport Layer Security (TLS) to use secure the connection. LwM2M LwM2M also supports authentication and data transport security mechanisms. LwM2M uses CoAP which usually uses UDP as the transport protocol. When using UDP, LwM2M supports DTLS. CoAP also supports TCP and TLS accordingly. Use Cases MQTT MQTT is used for sending payload for low-power and constrained applications, thus making it a favorite choice for many IoT applications. MQTT brokers are a big component of Cloud based IoT solutions. Logistics - for connectivity and real-time monitoring of vehicles Manufacturing - For monitoring of manufacturing plants Smart Home - For energy monitoring, home security, home patient monitoring Oil and Gas - The use-case it was first built for, to monitor the oil pipelines Consumer products - Like smart appliances Urban Mobility - For city transportation systems, car sharing etc. LwM2M While LwM2M also supports sending telemetry data, it was built to standardize device management and provisioning, thus making it ideal for the 6 functions that it defines in its implementation. Bootstrapping - Enables headless device management, thus enabling shipping the devices without configuring them in the factory. Device Configuration - Enables device life cycle functionalities like enable, disable and update. Firmware Update - Enables FOTA/ SOTA for devices. Fault Management - Enables monitoring of statuses like battery level, memory, sw/hw version etc. Configuration & Control - Enables setting of APN and other functionalities for cellular connectivity, as well as activating, rebooting and disabling the device. Reporting - Enables error reporting from the devices Conclusion While deciding the right protocol for sending essential data from your connected devices to your application, the question is not whether you use MQTT or LwM2M. From the above description, you can see that both protocols were designed for different and specific purposes. So if your application needs a higher payload of data to be sent, you might choose MQTT and will have to implement functionalities like device provisioning, OTA on top of it. On the other hand, if the application needs to monitor critical statuses on the device, as well as needs the convenience of lightweight device management, you might want to choose LwM2M. Platforms like AWS IoT, Azure IoT Hub have an inbuilt version of the MQTT broker which you can use to send payload through your device. You then only have to configure the MQTT client on the device. The device management in AWS IoT and Azure IoT hub is then done through device shadow and device twins respectively. If you are hosting and managing your own cloud applications, you can use LwM2M for device management and build your own MQTT broker for messaging. There can also be use-cases where you might need to use a combination of both. In any case, it is important to understand that MQTT and LwM2M protocols are not replacements of one another but built for distinct use-cases. Stay glued to this space to see a comparison between MQTT and CoAP next. And if you wish to know more about protocols and IoT check out our Comprehensive Guide to IoT Protocols. Until then, Stay Connected!