v21 Third Party Feeds

I think this would be interesting for everyone to see what (free) feeds may be useful here... But we have to be careful because posting links may lead to account blocks for spamming here in forum... so just add the https to the links (I hope this will work now)

I found this lists in a Sophos KB-Article:

    rules.emergingthreats.net/blockrules/compromised-ips.txt
    check.torproject.org/torbulkexitlist

URLs

    osint.digitalside.it/Threat-Intel/lists/latesturls.txt
    urlhaus.abuse.ch/downloads/text/

Domains

    raw.githubusercontent.com/disposable-email-domains/disposable-email-domains/master/disposable_email_blocklist.conf
    osint.digitalside.it/Threat-Intel/lists/latestdomains.txt

regards

I found outgoing system generated traffic of the firewall itself is also blocked by Threat Feeds when the Firewall tries to communicate with a listed IP.

I'm unsure if this is good or bad.

[I posted what I'm using in another post, just adding on to LHerzong's point in this post.]

EDIT: Sophos folks went above and beyond and found that the "random probes" that I was seeing weren't the usual random probes, but were in fact all for the VPN service (which is running). So in the past, these were not actually dropped as Appliance Access, since they literally are directed at the appliance. (Not sure where they might've shown up in the logs, but I had overlooked them.)

So there were a small number of VPN probes and I hadn't noticed they weren't included in my monthly report about Appliance Access (tens of thousands off probes to the ports-of-the-month). And that part of my original report (incoming probes) is incorrect and is working as expected. I believe that the outgoing connections -- which show up as High Severity C&C contacts -- are still to be addressed.

ORIGINAL:

I've also found that if you're probed by a random IP addresses, they used to be considered Device Access and were dropped and logged in Firewall logs. But if those IPs appear on a third-party IP block list, you now get a block event instead, which shows up more prominently. Not sure that it's a good idea, but not sure what could be done about it. (The ideal would be that the block occurs after Device Access drops, so it only blocks incoming that have a valid internal destination, but I imagine that's easy to say and hard to implement.)

Also, third-party lists are often crowd-sourced and over-generous -- unlike Sophos' excellent and focused internal list -- so they can include targets like githubusercontent which no doubt has some bad stuff but mostly not. If one of your machines reaches out to one of these IPs, it registers as a High Severity and the textual description talks about a C&C server. (Still figuring it all out and there may also/alternatively be a Medium Severity event that talks about C&C or something else.)

Sophos is looking into the latter issue. So I'm just putting it out there that this is also a bit tricky: a mechanism that used to be for highly-sophisticated and polished Sophos block lists is now open for open-source, crowd-sourced lists that don't reflect the same kind of threat and so they may have to complexify some of the logic/labeling, or maybe just warn that free third-party block lists may result in warnings that are more severe than they should be.

The question is also: Do Sophos use also some of these (free) list for their own internal list so that some entries would be used double? It would be not necessary if Sophos already use this feeds for their own list...

Wayne Folta said:

I've also found that if you're probed by a random IP addresses, they used to be considered Device Access and were dropped and logged in Firewall logs. But if those IPs appear on a third-party IP block list, you now get a block event instead, which shows up more prominently.

Thanks, this seems to describe what's happening now.

e.g. I've seen that yesterday for this IP

www.abuseipdb.com/.../162.216.149.233

It's on the TF list but belongs to a large CDN IP Range

Also, if a TF is now processed before Device Access? Is it possible that an error or misuse of the feed would result in a DoS of your own firewall?

So, if a TF contains "all" IP Addresses including private IPs, will you lose access to all your private IPs and to the firewall itself?

Would be smart enough if the TF would not process private IP ranges or at least to exclude them as admin.

I've updated my post. Sophos dug into this and found that these notifications were not due to a random probe from a now-blocked IP from a third-party list. They were from the third-party list, but they weren't the usual shotgun of probes: they were specifically to the VPN port that is open to the WAN (which is of course how you use a VPN). In that case, it is acting as expected: those probes are not (invalid) Appliance Access but are for a service that is running on the appliance and so are blocked if they're on a block list. (In the past, they would have resulted in a failed VPN login attempt if the probe actually tried to login, or would end up elsewhere if they immediately dropped the connection, I guess.)

I'm a small fish so don't see a lot of what big fish see, but I haven't gotten any blocks by the URLHaus recent block list (one of their small lists). I have gotten blocks based on the FireHOL L3 list, but those were: a) VPN probes from listed IPs that I had previously not seen because they don't show up as (invalid) Appliance Access, and b) outgoing IP access that is flagged as C&C communications but the FireHOL list includes IPs that map to sites like "githubusercontent" which is an extremely broad IP.

I'm a small fish so don't see a lot of what big fish see, but I haven't gotten any blocks by the URLHaus recent block list (one of their small lists). I have gotten blocks based on the FireHOL L3 list, but those were: a) VPN probes from listed IPs that I had previously not seen because they don't show up as (invalid) Appliance Access, and b) outgoing IP access that is flagged as C&C communications but the FireHOL list includes IPs that map to sites like "githubusercontent" which is an extremely broad IP.