Skip to main content

DNS Lookups

The purpose of the DNS rule is to control, monitor or restrict any protected application from performing DNS lookups on specifically configured hosts.

Overview

A use case of a DNS Lookup would be creating a rule to prevent a specific protected application from looking up any hostnames for any domains that are not known or trusted and defined in a rule by the Application Security Administrator.  If a protected application can be utilized by malware to send data via DNS requests (thus using DNS to act as a covert Command and Control channel or a path for data exfiltration, especially low and slow exfiltration) it can bypass many firewall configurations.  However, if the application is protected by Waratek, it can have its DNS requests limited by the Waratek Agent, thereby preventing it from communicating out to a malicious external server endpoint.

Attention: If this rule is not configured with the proper forethought, it can drastically affect other rules. For example, certain socket rule types can use DNS names in the rules. If a DNS name is used in a rule, and that rules' DNS lookup fails, then the rule will be discarded for that trigger of the rule. If this DNS rule somehow prevents Agent-protected machines or applications from performing DNS lookups, then it could result in the unintentional consequence of causing the socket rules to fail as well.

Rule Options

DNS Lookup Subject​

Valid entries in this field are a hostname, or an IPv4 address.  You may select a value of all or any by checking the Any checkbox next to the field.

Generally speaking this can be applied in two different ways: you can list a single domain or host that you wish to prevent from being looked up, or you can create two rules where the first DNS rule uses the Any check box option and the Protect action, and the second DNS Rule specifies an address to be whitelisted, and the action is set to Allow (Whitelist).

Any host or domain name entries here will parse on the end of the domain name.  For example, if “www.victim.com/index.html” is entered here, this will automatically be parsed at the domain and only “www.victim.com” will be passed on to the Waratek Java agent.

Restrict Rule to API Endpoints​

You can limit the rule to respond to API requests only.

  • No - Do not restrict the rule response
  • All Endpoints - Restrict the rule response to API requests only
  • Specific Endpoints - Restrict the rule response to API requests on the specified endpoints

You can change the default value No but you can select only one of these options.

Do Not Trust Inputs From​

Protection can be, optionally, limited to lookup that contain untrusted input. If no inputs are selected, protection is applicable to all DNS lookups, no matter how network domain or address was obtained by the Application.

Sources that the strict policy option will treat as untrusted are:

HTTP - Data received by the application from HTTP requests (e.g. from a web browser).

SQL Databases - Data received by the application from a SQL database.

Java Deserialization APIs - Data received by the application via deserialization APIs (e.g. RMI, JMX, Java Object Deserialization, etc.)

It is not possible to create an Allow rule which would only be applicable in the context of processing API requests. Restricting the rule to specific endpoints will remove the Allow action option.

Selecting input(s) not to trust will also remove the Allow action option. The Allow action can only be specified for the DNS Lookup Subject, and it can not be limited to any single trusted input source.

See the API Protect section of the ARMR documentation for further details.

Action​

  • Detect - The Agent will detect the lookup of listed address(es), log the event to the event database, and the event will be viewable on the Security Events pages in the Portal, but the Agent will take no further action
  • Protect - In addition to the Detect actions, the Waratek Agent will also actively prevent the lookup of the address(es) from succeeding.
  • Allow - Acts as whitelist.  This is similar to the Detect action in that no blocking or destructive action will be taken, however the Allow action will supersede the Protect action by whitelisting addresses to be excluded from Protect actions.

If multiple DNS rules are created, the Agent will not allow matching hostnames or wildcards to be specified between rules.

Log Messaging​

The logs provide a message field, which can be customized. Text entered here is the message that will be seen on the log file’s when the rule has been triggered, regardless or the Action. If the field is left blank, then the default logging message will be displayed in the message portion of the event log.

Severity​

The log files allow you to select a custom severity level for the event: Low, Medium, High or Critical.  A severity is required, and there is no default selection.

Advanced Options​

Disable Logging - By checking this option, no logging will be performed when a rule is triggered. Subsequently the Portal will not see these events, and they will not appear anywhere in the Portal, nor will they be searchable in Event Storage.

This option will be greyed out if the rule action is set to Detect.

Enable Stack Trace - By checking this option, when a rule is triggered, the stack trace will be included in the event log, and will be available for viewing in the Portal UI for each triggering security event.