Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 17 replies
  • Subscribers 5 subscribers
  • Views 236098 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Strange PTR DNS quaries

NewImage
Hi

My IDS has been reporting strange DNS queries to a malware domain every night at 12:05
BLACKLIST DNS reverse lookup response for known malware domain spheral.ru - Win.Trojan.Glupteba

The IDS says the source is my internal DNS computer, but when I look at the logs on it, it was responding to a PTR request made from the UTM (I have the UTM forwarding to the internal DNS)

I have been trying to find if a client asking for that DNS requests.
For a test, I have disabled other networks (DMZs, phones, wifi) from using the UTM as the DNS host as a test to see if another network was causing the request. The requests still happened.

I checked the logs
Web Filtering: in that minute time frame I did not see any strange requests. The UTM proxy does its own DNS lookup for web browsing) 
IDS logs: catches the internal DNS computer going out, but not the UTM making the request
Firewall logs: Show the DNS requests going out, but not the request going to the UTM (No details just A made a Dns request to B)
TCPDUMP: Running TCP dump over all interfaces for DNS traffic shows the initial request originating from the UTM. (tcpdump udp port 53 -nn -w capture.cap )
Web application: No request made at all around that time

So I guess my question is,
What in the UTM causes it to do PRT lookups on IP addresses, I saw it making a lot of these requests? And is there a log to see the requests made by the UTM, and why?

Thanks for any help, tonight I'm going to try disabling web filter proxy, and turn off all web application servers, see if that can help narrow down the cause. 

UTM 9.213-4


This thread was automatically locked due to age.
  • 0
    NewImage - I have also seen these IPS alerts on a couple of the Astaro's we manage. My experience was also that the IPS alerts seem to come in when the daily executive report is generated.

    In my experience if you look in your /var/log/system/// around the time the IPS alerts are generated it seems to be tied with the "nice -n19 /usr/local/bin/gen_inline_reporting_data.plx" cron job.

    E.g.
    2015:10:22-00:39:46 TEST-UTM ntpd[8923]: Listening on routing socket on fd #24 for interface updates
    2015:10:22-00:40:01 TEST-UTM /usr/sbin/cron[9018]: (root) CMD (/var/mdw/scripts/pmx-blocklist-update)
    2015:10:22-00:40:01 TEST-UTM /usr/sbin/cron[9019]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
    2015:10:22-00:43:01 TEST-UTM /usr/sbin/cron[9245]: (root) CMD (/usr/local/bin/create_rrd_graphs.plx --acc)
    2015:10:22-00:45:01 TEST-UTM /usr/sbin/cron[9745]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
    2015:10:22-00:45:01 TEST-UTM /usr/sbin/cron[9746]: (root) CMD ( /usr/local/bin/rpmdb_backup )
    2015:10:22-00:47:01 TEST-UTM /usr/sbin/cron[9924]: (root) CMD (  nice -n19 /usr/local/bin/gen_inline_reporting_data.plx)
    2015:10:22-00:47:03 TEST-UTM ips-reporter[4267]: [CRIT-852] Intrusion Prevention Alert (Packet dropped)
    2015:10:22-00:47:04 TEST-UTM ips-reporter[4267]: [CRIT-852] Intrusion Prevention Alert (Packet dropped)
    2015:10:22-00:47:06 TEST-UTM ips-reporter[4267]: [CRIT-852] Intrusion Prevention Alert (Packet dropped)


    The CRIT-852 IPS alerts correlate with the DNS IPS alerts. I've been able to confirm this on a couple different devices and I'm curious if you're experiencing the same thing.

    Thanks.
  • 0 in reply to ICWILL
    Yeah same thing here, can those commands be fired off manually to see what is creating the alert?

    2015:10:17-01:02:01 keywest /usr/sbin/cron[7261]: (root) CMD (  nice -n19 /usr/local/bin/gen_inline_reporting_data.plx)
    2015:10:17-01:05:01 keywest /usr/sbin/cron[7576]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
    2015:10:17-01:05:01 keywest /usr/sbin/cron[7575]: (root) CMD (/usr/local/bin/report_render.plx --archive --type yesterday --sendmail)
    2015:10:17-01:05:20 keywest ips-reporter[6588]: [CRIT-852] Intrusion Prevention Alert (Packet dropped)

    I don't know where to go from here
  • 0 in reply to NewImage
    I think I might have figured out what was going on. A loop is occurring, 

    I'm guessing there was an initial incident a few weeks ago. The UTM did a reverse lookup on the IP that attacked it for its nightly reports to associate IPs with domain names. But this lookup caused SNORT to log a hit, this hit was reported the next day and another lookup was done, that caused another lookup/hit that was reported on the next day, and so on and so on.

    I'm guessing turning off the executive report for one cycle should break the loop, I will see tonight.

    Thanks everyone for your help
  • 0

    Hello,

    We have the same thing happening every night around 1am

    If this is really a loop because of the nightly report system what can i do to stop it from happening?

    Edit:

    Oh i didn't read the last line of newimage-s comment mybad

  • 0 in reply to NewImage

    I can confirm, that the logged event is gone, when the Daily Executive Report is disabled for one day.

    Perhaps it is necessary to disable weekly and monthly reports too, since they will toggle the DNS-request again, when summarizing the weekly and monthly events.

    Jan

  • 0

    I was experiencing this behaviour on one of our customer's UTMs.

    I was wondering, if modifying the IPS rule wouldn't be a better solution than turning off the executive reports?
    Under the advanced tab of IPS, I modified rule 31600 to: DROP, no notification.

    Or isn't that possible in your UTM version? I was doing it in the actual release.

  • 0 in reply to kerobra

    Surely, doing so also will help, but then you will get no notifications for this IPS-Event at all.

    I think, temporary disabling the reports is a better solution. The best would be, if SOPHOS releases a fix, anyway ;-)


    Jan.