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

Explain ATP to me, please

I've had the opportunity to use ATM in UTM since it was made available. I have spent time trying to work with it and find value in it and I have come to the conclusion that I have failed utterly.

therefore, I'd like someone to explain it to me.

Here is what I have 99.9% of the time: a an alarm about my DNS server making an (unspecified) DNS query to an (unspecified) DNS server in behalf of an (unspecify) client.

The alarms links to this "document":

C2/Generic-A - Viruses and Spyware - Web Threat, Virus and Spyware Detection and Removal | Sophos - Threat Center - Cloud Antivirus, Endpoint, UTM, Encryption, Mobile, DLP, Server, Web, Wireless Security, Network Storage and Next-Gen Firewall Solutio

What the heck am I supposed to do with that ? There is NOTHING that can be used to identify any offensive clients and the few times I digged though the DNS log and was able to identify the given query, it ended up being a large torrent tracker.

Obviously, someone thought that ATP was providing some level of security (or value) so I must be missing something.


This thread was automatically locked due to age.
Parents
  • ATP in the UTM is in the meanwhile quite effective finding malware in your network and from my experience also relatively silent in view of false positives. In the meanwhile I know a lot of partners and customers who found malware residing in their or customer network thanks to ATP.

    While you can be nearly sure if ATP got triggered by it´s blacklist (IPTABLES) or URLs (Web Proxy or AFCd), you have most likely a real threat in your network.

    DNS as source is more difficult, as:
    a) there may be some obscure domains be listed in ATP pattern list, which besides of malware also may be partly used for legitimate stuff too. Shouldn´t be too many of them, but I assume this absolutely possible.
    b) DNS triggers are difficult to resolve back to the originating internal client, as usually in your networks the DC´s should be the only devices doing external lookups for your network, so always your DC, and not the originating client in the network gets listed. And as the blocked Malware lookup from the client gets blocked/not resolved, there´s also no following outgoing connection to a C&C server or Malware URL (which would originate directly from a compromised client).

    I thought little about that issue, as I got contacted by partners searching the source of those lookups. My best idea is to place another UTM in bridge mode between your DC´s/DNS Servers and the clients. So ATP on that bridged (temporary) UTM should list the real source clients IP doing that DNS lookups. Not a perfect solution, but better than searching windows logs, wiresharkíng on those windows DC´s etc. for days. Better than nothing ;o)

    BTW: As DNS lookups also lists the requested domain, you can weight by yourself, how big the chance is, that this was a real malware. If you have a alert for a human readable domain which makes sense as "mydailynewspaper.com",  it *could* be a malware, but is very likely a FP. If you see domains like "jha89serjha98.ie" or "jaiofddda12.ru" and such senseless strange domains, it´s most likely a real threat trying to access their floating, dynamicly generated C&C domains ;o)
Reply
  • ATP in the UTM is in the meanwhile quite effective finding malware in your network and from my experience also relatively silent in view of false positives. In the meanwhile I know a lot of partners and customers who found malware residing in their or customer network thanks to ATP.

    While you can be nearly sure if ATP got triggered by it´s blacklist (IPTABLES) or URLs (Web Proxy or AFCd), you have most likely a real threat in your network.

    DNS as source is more difficult, as:
    a) there may be some obscure domains be listed in ATP pattern list, which besides of malware also may be partly used for legitimate stuff too. Shouldn´t be too many of them, but I assume this absolutely possible.
    b) DNS triggers are difficult to resolve back to the originating internal client, as usually in your networks the DC´s should be the only devices doing external lookups for your network, so always your DC, and not the originating client in the network gets listed. And as the blocked Malware lookup from the client gets blocked/not resolved, there´s also no following outgoing connection to a C&C server or Malware URL (which would originate directly from a compromised client).

    I thought little about that issue, as I got contacted by partners searching the source of those lookups. My best idea is to place another UTM in bridge mode between your DC´s/DNS Servers and the clients. So ATP on that bridged (temporary) UTM should list the real source clients IP doing that DNS lookups. Not a perfect solution, but better than searching windows logs, wiresharkíng on those windows DC´s etc. for days. Better than nothing ;o)

    BTW: As DNS lookups also lists the requested domain, you can weight by yourself, how big the chance is, that this was a real malware. If you have a alert for a human readable domain which makes sense as "mydailynewspaper.com",  it *could* be a malware, but is very likely a FP. If you see domains like "jha89serjha98.ie" or "jaiofddda12.ru" and such senseless strange domains, it´s most likely a real threat trying to access their floating, dynamicly generated C&C domains ;o)
Children
No Data