Introduction
TCPWave’s DNS Titan End-User Security prevents users from accessing malicious sites. More specifically, it blocks DNS queries for domain names of malicious hosts, queries to malicious DNS servers, and IP addresses of malicious sites in DNS query responses. Also, since this Titan feature provides this protection in DNS servers, it prevents some types of malware from reaching devices. Consequently, there is no need to quickly detect this malware on a device and remove it before it damages or spreads.
The items to block are based on domain and IP reputation data provided by TCPWave’s partner, Spamhaus, a leader in delivering high-quality threat intelligence information. This reputation data consists of a feed of continually updated rules in DNS Response Policy Zones (RPZs). By using this information, Titan End-User Security protects users from accessing malicious sites, including malware, ransomware, phishing, adware, and botnet sites.
To enable users to understand and take advantage of DNS Titan End-User Security, information on the following topics is presented in the sections below:
1. Spamhaus
2. Architecture
3. Configuration in TCPWave
4. Verification of the configuration
5. DNS RPZ reports
Spamhaus
Spamhaus has over twenty years of experience protecting users and networks and is a trusted authority on IP and domain reputation data. Also, they protect over three billion mailboxes globally. Consequently, they are an industry leader for providing threat intelligence data, and leading global technology companies use their datasets. Example customers are provided near the bottom of the page at www.spamhaus.com.
With DNS Titan End-User Security, you benefit from Spamhaus’s high-quality threat intelligence in their RPZ data feeds. The following data feeds from Spamhaus are included in DNS Titan End-User Security:
1. Malware Hosts: Domains identified as hosting malware.
2. Phishing Hosts: Domains identified as hosting phishing sites.
3. Adware Hosts: Domains identified as hosting adware.
4. Bad Reputation Hosts: Uncategorized domains that have a bad reputation. This includes hosts owned by known spammers, payload URLs, malicious tracking domains, and domains associated with low- reputation networks.
5. Botnet Command and Control (C&C) Hosts: Domains identified as hosting botnet C&C malware.
6. Botnet Hosts: Domains identified as hosting botnet resources that are not a botnet C&C.
7. Domain Generation Algorithm: Domains produced by domain generation algorithms. These domains are usually associated with malware.
8. Zero Reputation Domains: Newly registered domains that have been listed for less than 24 hours. Legitimate organizations rarely use a domain immediately after registering it.
9. Bad Nameserver Hosts: Domains used for the host records of nameservers that have a bad reputation.
10. Bad Nameserver IPs: IP addresses of nameservers that host domains and have a bad reputation.
11. Botnet Command and Control (C&C) IPs: IP addresses identified as hosting botnet C&C malware.
12. Bogons IPs: IP addresses that have not yet been assigned to an entity should not have any incoming or outgoing traffic.
13. Do Not Route or Peer: IP addresses that have been identified as being hijacked, belonging to bulletproof hosters, or being leased by professional malicious organizations.
14. Coinblocker: IP addresses and domains that host cryptojacking scripts, which use the resources of an end user’s computer to mine cryptocurrency.
15. Torblocker: List of known Tor Exit Nodes.
Architecture
An overview of the DNS Titan End-User Security architecture is shown in the figure below. As depicted in it, Response Policy Zones (RPZs) are transferred from Spamhaus DNS servers to a TCPWave primary (or lead secondary) DNS caching appliance. Spamhaus also supports transfers to an optional primary DNS appliance for the site and geographic redundancy. Secondary DNS caching appliances are downstream from the primary DNS appliances and get zone transfers from them.
DNS Titan End-User Security Architecture
After zone transfers are complete, if a DNS query contains a name or IP address defined in an RPZ as malicious, the query will be blocked. Also, these blocked queries will be logged and used in DNS RPZ reports.
Configuration
This configuration section explains the steps necessary to use DNS RPZs from Spamhaus in your TCPWave DNS appliances. It describes how to update TCPWave licenses and set up primary (or lead secondary) DNS caching appliances and downstream secondary DNS caching appliances.
Update Licenses
Once purchased, the first step to configuring the new End-User Security feature is updating the IPAM licenses. Do this as follows:
1. Navigate to Administration >> Configuration Management >> License Management.
2.
Select the IPAM to update, then click Update
License 
and
enter the license key provided by TCPWave.
3. Repeat the previous step for other IPAM appliances as needed.
Below is an example of an updated License Information screen. “DNS Titan End User Security Enabled” is “Yes,” and the feed type is “Standard” or “Advanced,” depending on the license purchased.
Create RPZ Templates for Master DNS Appliances
Before applying the End-User Security feature to appliances, you must first create the RPZ template for primary (or lead secondary) DNS appliances. (These appliances receive zone transfers from Spamhaus’s DNS servers).
1. At the top of the GUI, navigate to Network Management >> DNS Management >> DNS Security >> DNS Threat Management.
2. Click the RPZ Templates tab.
3.
Click Add 
to
create a new RPZ template.
4. Select the External Feed box.
5. Select an Organization, and enter a Name for the template.
6. For RPZ Feed Provider, select either “DNS Titan End User Security (Standard)” or “DNS Titan End User Security (Advanced),” depending on which license was purchased.
Result: The configuration options for the template are updated and automatically populated with Spamhaus’s zones and server IP addresses.
7. Keep QName Wait Recurse selected. (It is for a BIND query name policy.) An example screenshot is shown below.
8. Click OK to save the template.
Apply RPZ Templates to DNS Appliances
After creating an RPZ template for master appliances, you must apply it to each master DNS appliance. The next section below explains how to create an RPZ template for secondary DNS appliances, which must be applied to them. The steps for applying an RPZ template are the same for the master and secondary appliances, which are as follows:
1. At the top of the GUI, navigate to Network Management >> DNS Management.
2. Click on an appliance to edit it.
3. For DNS Appliance Type, select “ISC Bind Cache Appliance.”
4. For RPZ Template, select an RPZ template for the master or secondary appliance. An example screenshot is shown below.
5. Click OK to save your configuration.
Result: Your DNS Appliance will be configured for protection using the Spamhaus RPZs after complete initial zone transfers.
Create and Apply RPZ Template for Secondary Appliances
Secondary DNS appliances receive zone transfers from a primary (or lead secondary) appliance. To create and apply an RPZ template for a secondary appliance, follow the steps below:
1. At the top of the GUI, navigate to Network Management >> DNS Management >> DNS Security >> DNS Threat Management.
2. Click the RPZ Templates tab.
3.
Click Add 
to
create a new RPZ template.
4. Select the External Feed box.
5. Select an Organization, and enter a Name for the template.
6. For RPZ Feed Provider, select “DNS Titan End User Security (TCPWave Secondaries).”
Result: The configuration options for the template will be updated and automatically populated with Spamhaus’s zones.
7. For Master Servers, select the IP address(es) of the master DNS Appliance(s).
8. Keep QName Wait Recurse selected. (It is for a BIND query name policy.) An example screenshot is shown below.
9. Click OK to save the template.
10. Applying a template to a secondary DNS appliance is done the same way as a master DNS appliance. It is described above in the section Apply RPZ Templates to DNS Appliances.
Note: If you need to apply the RPZ template to many secondary DNS appliances, you may use the setdnsserver CLI command.
Verify Configuration
To verify that the Titan End-User Security feature is functioning, you must first wait 15-30 minutes for the initial zone transfers from the Spamhaus DNS servers to the TCPWave primary DNS appliance(s) wait additional time for zone transfers to downstream secondary appliances. Shown below is an example of a dig command to that sends a query to a DNS server requesting the IP address of a simulated malicious domain:
[root@SpamHausRemoteTesting ~]# dig @10.1.10.122 bad-nameservers-host-dtq.rpzfeeds.com
; <<>> DiG 9.11.32 <<>> @10.1.10.122 bad-nameservers-host-dtq.rpzfeeds.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20323
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: d448dd9bc0d95f2884f96150610953b73b81db19f1bb034e (good)
;; QUESTION SECTION:
;bad-nameservers-host-dtq.rpzfeeds.com. IN A
;; ADDITIONAL SECTION:
bad-nameservers.host.dtq. 60 IN SOA need.to.know.only. hostmaster.deteque.com. 1628001001 300 60 432000 60
;; Query time: 1 msec
;; SERVER: 10.1.10.122#53(10.1.10.122)
;; WHEN: Tue Aug 03 10:33:27 EDT 2021
;; MSG SIZE rcvd: 190
If the Spamhaus RPZ configuration is correct and the DNS appliances are working, then the dig query will be blocked. In specific, as shown above in the dig output in the HEADER section, the DNS server returns an “NXDOMAIN” (non-existent domain) response to prevent users from accessing the simulated malicious site. (If the Spamhaus RPZ rules were not functioning, then the dig output would contain the IP address for the requested domain.)
The record in the Spamhaus RPZ file that causes the dig query to get blocked is as follows:
bad-nameservers-host-dtq.rpzfeeds.com.bad-nameservers.host.dtq. 3600 IN CNAME .
This record, which is an RPZ rule, is in the bad-nameservers.host.dtq zone, which is one of the zones that Spamhaus transfers to TCPWave primary DNS appliances.
DNS RPZ Reports
TCPWave IPAM provides two reports of blocked DNS queries, which help security personnel and others understand trends in security threats and better protect users. Also, both of these reports are based on RPZ log files. The Top Queried RPZ Logs Report displays the most frequent DNS queries resolved by RPZ rules. The DNS RPZ Logs Report displays the history of DNS queries that were resolved by RPZ rules. Also, in the second report, you can filter it to see just the queries for a specific appliance or a specific client. To run one of these reports, do the following:
1. Navigate to Reports >> DNS Reports.
2. Search for “RPZ” in the Search Pages box.
Result: Two options appear: “DNS RPZ Logs Report by Appliance” and “Top Queried RPZ Logs Report.”
3. Select one of the reports to view.
4. If you selected “Top Queried RPZ Logs Report,” enter a range of dates.
5. Click Generate. Example screenshots of the reports are shown below.
Top Queried RPZ Logs Report
DNS RPZ Logs Report by Appliance
Advantages
DNS Titan End-User Security provides multiple advantages, including the following:
1. It prevents users (and applications) from accessing malicious sites, including malware, ransomware, phishing, adware, and botnet sites.
2. It prevents some types of malware from reaching devices, so there is no need to quickly detect this malware on a device and remove it before it does damage or spreads.
3. It protects without having to install and continually update the software on the many DNS clients that exist.
4. It protects by using high-quality threat intelligence data from Spamhaus, a trusted authority on IP and domain reputation data and an industry leader for providing threat intelligence data.
TCPWave sets a high-security standard by offering scalable, enterprise-grade, and integrated protection of DNS infrastructure. For more information on how TCPWave and its extensive security features can meet your needs, contact the TCPWave Sales Team.