Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 2 subscribers
  • Views 942 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

Revisiting a Strange Snort Message

robertobrinsky
Looking through my IPS logs, I found the following entry:
2012:04:26-09:25:31 lockjaw2 snort[7147]: id="2101" severity="warn" sys="SecureNet" sub="ips" name="Intrusion protection alert" action="alert" reason="BAD-TRAFFIC TMG Firewall Client long host entry exploit attempt" group="500" srcip="8.8.8.8" dstip="192.168.55.55" proto="17" srcport="53" dstport="52165" sid="19187" class="Attempted User Privilege Gain" priority="1"  generator="3" msgid="0"

This was generated by a request from an iMAC that uses 8.8.8.8 directly for DNS queries and does not use the web proxy. I also have an entry from a system that does use the Astaro as the DNS server, and does use the web proxy.

My Astaro is set to use Google's DNS servers as forwarders and this particular DNS server (8.8.8.8) is also listed as a secondary DNS for addresses distributed via DHCP.. Now, I am fairly certain that Google does not use Microsoft OS for their public DNS servers.

So, would this be a false positive with Snort (not the first time that occurred), or is there another system along the route that is causing this IPS rule to trigger?

Thanks in Advance.
Bob


This thread was automatically locked due to age.
Parents
  • 0
    Hi,

    Google is just returning the DNS answer from whatever other DNS server is authoritative for whatever domain was being looked up.

    So, it could have been:

    a. a correct alert, in that the packet contained something which could exploit a TMG.

    or

    b. a false positive

    Either way, if you're not using TMG, you're safe and you can create an exception for that rule

    Barry
Reply
  • 0
    Hi,

    Google is just returning the DNS answer from whatever other DNS server is authoritative for whatever domain was being looked up.

    So, it could have been:

    a. a correct alert, in that the packet contained something which could exploit a TMG.

    or

    b. a false positive

    Either way, if you're not using TMG, you're safe and you can create an exception for that rule

    Barry
Children