Security Compliance

SEM Looks up a DNS Record from a Known Problem Site

SEM looks up a DNS Record from a Known Problem Site - Occasionally SEM will look up a DNS record from a site that is flagged by another product.

First published date

11/1/2018 4:50 PM

Last published date

3/7/2025 4:07 PM

Overview

As Security Event Manager (formerly Log & Event Manager) receives log data that requires a DNS resolution to satisfy the internal rule engine, SEM will perform a DNS lookup. SEM network configurations will be pointed to a DNS server, typically a domain controller, for the network resolution. Because of the way that DNS forwards requests, the resolution can go to the definitive source for resolving the IP, which may be a DNS server on a blacklist or potentially malicious website listings.

This DNS lookup may be picked up by other applications/devices as wanting to access a potentially malicious site. SEM is not trying to go to these potentially malicious sites, but it will look up the hostname for an IP address found in an event, for use in event correlation by the SEM rules engine.

It is fairly common for a firewall to log attacks and other types of access attempts from internet locations, and then log those events to a receiving SIEM or syslog server. The access attempts will come from potential malicious internet sites, and now logged to SIEM/syslog devices like SEM.
Remember SEM is not going to the malicious site, just trying to resolve the IP address within the event.

Product section

Security Event Manager

Resolution

If SEM picks up an event/alert needed for a rule to fire, and SEM does not know the IP address, SEM will perform an nslookup to a DNS server defined by initial configurations (in /etc/resolv.conf). If the DNS server cannot resolve, the request is forwarded to a definitive internet resource to resolve the hostname to an IP address. If the firewall or other network monitoring device see's this request, it appears that SEM wants to access a potentially malicious website. SEM is not trying to go to that website, but rather it just wants to log the hostname and IP-address of the device that it picked up logs for.

A DNS lookup works roughly like this

The SEM receives a log with a IP address in it.
The SEM performs a dns lookup against the IP address
The SEM reaches out to its assigned DNS Server for resolution
The assigned DNS Server reaches out to the ISP DNS Server for lookup
The ISP server asks a Root Level DNS server for the resolution
The root level Returns the Name Servers (Authoritative)
The SEM Queries the Name server for the record *** this is what generates the alert

The key to finding WHAT the SEM is looking for or WHY it is doing the lookup will vary on the situation:

According to Development SEM does a DNS lookup for rule purposes.
Reviewing a sufficient sample from the dns.log file (or equivalent) on the DNS server is critical to establishing what the SEM is resolving.

For example:

In the logs you should see the SEM send (snd) a request for a domain (in this example google.com).
You should then see a matching receive (rcv) answer on the IP or destination for the local server.
Filtering and searching the events from the SEM can help establish the chain to the initial request.
In the below provided logs the SEM was used to ping google.com. The logs are the associated traffic for that DNS related traffic.

2/6/2017 5:57:29 PM 18D4 PACKET  000000BBFB112130 UDP Snd 10.110.7.1      6f12 R Q [0084 A     NOERROR] A      (6)google(3)com(0)

2/6/2017 5:57:29 PM 18D4 PACKET  000000BBFA952230 UDP Rcv 10.110.7.1      624c   Q [0001   D   NOERROR] PTR    (3)119(2)93(3)227(3)173(7)in-addr(4)arpa(0)

2/6/2017 5:57:33 PM 18D4 PACKET  000000BBFA952230 UDP Snd 10.110.7.1      624c R Q [8381   DR NXDOMAIN] PTR    (3)119(2)93(3)227(3)173(7)in-addr(4)arpa(0)

2/6/2017 5:57:33 PM 18D4 PACKET  000000BBFB8C8100 UDP Rcv 10.110.7.1      667e   Q [0001   D   NOERROR] PTR    (3)119(2)93(3)227(3)173(7)in-addr(4)arpa(0)

2/6/2017 5:57:33 PM 18D4 PACKET  000000BBFB8C8100 UDP Snd 10.110.7.1      667e R Q [8381   DR NXDOMAIN] PTR    (3)119(2)93(3)227(3)173(7)in-addr(4)arpa(0)

2/6/2017 5:57:35 PM 18D4 PACKET  000000BBFB112130 UDP Rcv 10.110.7.1      6ad0   Q [0001   D   NOERROR] PTR    (3)119(2)93(3)227(3)173(7)in-addr(4)arpa(0)

2/6/2017 5:57:35 PM 18D4 PACKET  000000BBFB112130 UDP Snd 10.110.7.1      6ad0 R Q [8381   DR NXDOMAIN] PTR    (3)119(2)93(3)227(3)173(7)in-addr(4)arpa(0)

2/6/2017 5:57:35 PM 18D4 PACKET  000000BBFAE941E0 UDP Rcv 10.110.7.1      8b4c   Q [0001   D   NOERROR] PTR    (3)119(2)93(3)227(3)173(7)in-addr(4)arpa(0)

2/6/2017 5:57:35 PM 18D4 PACKET  000000BBFAE941E0 UDP Snd 10.110.7.1      8b4c R Q [8381   DR NXDOMAIN] PTR    (3)119(2)93(3)227(3)173(7)in-addr(4)arpa(0)

2/6/2017 5:57:37 PM 18D4 PACKET  000000BBFB8C8100 UDP Rcv 10.110.7.1      b07e   Q [0001   D   NOERROR] PTR    (3)119(2)93(3)227(3)173(7)in-addr(4)arpa(0)

2/6/2017 5:57:37 PM 18D4 PACKET  000000BBFB8C8100 UDP Snd 10.110.7.1      b07e R Q [8381   DR NXDOMAIN] PTR    (3)119(2)93(3)227(3)173(7)in-addr(4)arpa(0)

2/6/2017 5:57:38 PM 18D4 PACKET  000000BBFB112130 UDP Rcv 10.110.7.1      674c   Q [0001   D   NOERROR] PTR    (3)119(2)93(3)227(3)173(7)in-addr(4)arpa(0)

2/6/2017 5:57:38 PM 18D4 PACKET  000000BBFB112130 UDP Snd 10.110.7.1      674c R Q [8381   DR NXDOMAIN] PTR    (3)119(2)93(3)227(3)173(7)in-addr(4)arpa(0)

2/6/2017 5:57:39 PM 18D4 PACKET  000000BBFAE941E0 UDP Rcv 10.110.7.1      6f23   Q [0001   D   NOERROR] PTR    (3)119(2)93(3)227(3)173(7)in-addr(4)arpa(0)

2/6/2017 5:57:39 PM 18D4 PACKET  000000BBFAE941E0 UDP Snd 10.110.7.1      6f23 R Q [8381   DR NXDOMAIN] PTR    (3)119(2)93(3)227(3)173(7)in-addr(4)arpa(0)

2/6/2017 5:57:40 PM 18D4 PACKET  000000BBFB8C8100 UDP Rcv 10.110.7.1      94e2   Q [0001   D   NOERROR] PTR    (3)119(2)93(3)227(3)173(7)in-addr(4)arpa(0)

2/6/2017 5:57:40 PM 18D4 PACKET  000000BBFB8C8100 UDP Snd 10.110.7.1      94e2 R Q [8381   DR NXDOMAIN] PTR    (3)119(2)93(3)227(3)173(7)in-addr(4)arpa(0)

In this example my SEM IP is the 10.110.7.1 address. You can see the traffic for the google.com resolution and the returned IP address for that information.

Tip: You can use a tool like: nslookup, dig, Resolve-DnsName, and a online DNS lookup tool like(https://mxtoolbox.com/) to get both the hostname and IP of the SIte. You can then use this information to search the Historical Events & Reports in SEM to find which device reported the problematic site to SEM.

Example:

Disclaimer: Please note, any content posted herein is provided as a suggestion or recommendation to you for your internal use. This is not part of the SolarWinds software or documentation that you purchased from SolarWinds, and the information set forth herein may come from third parties. Your organization should internally review and assess to what extent, if any, such custom scripts or recommendations will be incorporated into your environment. You elect to use third-party content at your own risk, and you will be solely responsible for the incorporation of the same if any.