Over-enthusiastic blocking - Leading www in custom ioc domain feed is treated as wildcard?

[mib1185]

Hi 👋

we're using the custom ioc feeds feature (as described in sk132193) - all our gateways are on R81.20 JHF Take 120.
We've organized our feeds by type, so we've one for each type of IP-Address, URLs, Domains and SHA256 (we consume the feeds provided by another corporate entity). The domain type feed contains an entry for www.site which the Anti-Virus blade interprets as block anything which is *.site and site itself, instead of only block the expected www.site indicator. The same also works for any indicator entry like www.blabla.com which results in blocking everything under *.blabla.com and not only the exact match www.blabla.com. So it seems like that www is treated as a wildcard, while I would expect an exact match logic of the domain indicators. Or am I wrong here?

Regards,
Michael

[PhoneBoy]

Certainly seems that way based on behavior.
I haven't found any documentation to say it's expected behavior, though, and it might be worth a TAC case to confirm.

[Vincent_Bacher]

I would not consider myself an expert in the field of IOC feed, but: Perhaps you could consider using it in the URL feed instead of the domain? I have a vague impression that it would be used as an exact match then.

But maybe I'm completely wrong.

[mib1185]

I would expect, that the type domain only acts on the domain name, while the type url also considers all parts of the url (protocol, domain name, path) - therefore we also have different ioc feeds for domain and for url type.

Further, I didn't mentioned it on the OP, any other indicator which not starts with www is considered as exact match - so only www is somehow intepreted as a wildcard.

[Vincent_Bacher]

I would still give it a try.

[mib1185]

I did give it a try and yes, when using the domain feed as an url feed, it is exact match, but then this feed isn't used anymore to check DNS traffic (most likely it is only used for web- and ssl/tls-traffic). So this leads to the situation, that non-web connections can be established to actually forbidden targets.

[the_rock]

FWIW, you can always try using domain objects, as per below.

 

[mib1185]

thanks for the suggestions with the domain objects, but we use the ioc feed feature to make use of dynamic feeds, which the gateways updates on its own.

[Vincent_Bacher]

While I'm reading about domain objects: How about simply specifying the domain in the same way as domain objects, i.e. “.www.lalala.de”.
As I said, we don't use feeds, so I can't say whether this will be accepted, let alone whether it will work.

[the_rock]

I used feeds before in the lab and it did work, let me try it doday.

[the_rock]

I totally get the point Vince is making.

[Roslany]

Domains would be resolved to IP addresses, which would then be blocked.
For example, if blabla.com resolves to a specific IP address, and a subdomain of it (e.g., .blabla.com) resolves to the same IP, both would be blocked.

URLs are blocked based on the URL itself (regex).
The firewall determines the URL by using either SNI (valid for any traffic) or the URL from the GET request. Inspecting the URL from the GET request requires inspection for HTTPS traffic.

[the_rock]

Thats true. Thats why I was thinking it might not be a bad idea to test domain objects.

[mib1185]

but in case of DNS traffic, the Anti-Virus blade also inspects the DNS query itself and blocks queries for domains, which are on the domain feed. In my example the www.site doesn't resolve to any IP (anymore), but is still listed on one of our IoC sources (here). With the current behavior, that www seems to be treated as wildcard, the whole TLD site get blocked, instead of only this specific indicator www.site.