Submit a ticketCall us

WebinarDatabase Roundtable – Expert Database Professionals Feel Your Pain

In this video broadcast, Head Geek™ Tom LaRock is joined by Karen Lopez, Tim Chapman, and David Klee. They’ve known each other for many years, so this discussion was like four friends getting together to talk data and databases. They discussed diagnostic data collection, common performance root causes, reactive tuning versus proactive, and more. Join us for an engaging discussion on these topics! Plus, Tom LaRock will be available to answer your questions live.

Register now.

Home > Success Center > Log & Event Manager (LEM) > LEM - Knowledgebase Articles > LEM Looks up a DNS Record from a Known Problem Site

LEM Looks up a DNS Record from a Known Problem Site

Table of contents

Updated: April 9, 2018

Overview

As LEM receives log data that requires a DNS resolution to satisfy the internal rule engine, LEM will perform a DNS lookup. LEM 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 malacious website listings.

This DNS lookup may be picked up by other applications/devices as wanting to access a potentially malacious site. LEM is not trying to go to these potentially malacious sites, but it will look up the hostname for an IP address found in an event, for use in event correlation by the LEM 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 malacious internet sites, and now logged to SIEM/syslog devices like LEM.
Remember LEM is not going to the malacious site, just trying to resolve the IP address within the event.

Environment

LEM version 5.x.x and 6.x.x

Steps

If LEM picks up an event/alert needed for a rule to fire, and LEM does not know the IP address, LEM 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 LEM wants to access a potentially malicious website. LEM 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

 

  1. The LEM receives a log with a IP address in it.
  2. The LEM performs a dns lookup against the IP address

  3. The LEM reaches out to its assigned DNS Server for resolution

  4. The assigned DNS Server reaches out to the ISP DNS Server for lookup

  5. The ISP server asks a Root Level DNS server for the resolution

  6. The root level Returns the Name Servers (Authoritative)

  7. The LEM Queries the Name server for the record  *** this is what generates the alert

 

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

  1. According to Development LEM does a DNS lookup for rule purposes.
  2. Reviewing a sufficient sample from the dns.log file (or equivalent) on the DNS server is critical to establishing what the LEM is resolving.
  3. For example:
    1. In the logs you should see the LEM send (snd) a request for a domain (in this example google.com).
    2. You should then see a matching receive (rcv) answer on the IP or destination for the local server.
    3. Filtering and searching the events from the LEM can help establish the chain to the initial request.
    4. In the below provided logs the LEM 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 LEM 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.

 

This is a difficult situation due to us not being able to interpret the log data for the customer, but the customer often assumes that the DNS request is suspicious or a security issue in some way.

 

 

Last modified

Tags

Classifications

Public