Block incoming malicious IP for VSX

[dianammar]

sk132193 states that in R81, inbound traffic to a host behind a gateway is blocked, not in configurations earlier than R81.

sk103154 states that blocking malicious IP addresses using a custom intelligence threat feed is not supported on VSX gateway. So based on these 2 SKs, is it possible to block inbound malicious IP addresses on the VSX gateway with just upgrading the VSX gateways to R81 or above?

[PhoneBoy]

You can use Custom Intelligence Feed in VSX in R81+ to block incoming connections.
The SKs refer to different mechanisms.
In R81.20, we will have Network Feed objects which can also be used in this way and should support VSX.

[Bob_Zimmerman]

Turns out R81.20 Network Feed objects only partially support VSX. Specifically, when you make a Network Feed object which uses HTTPS, you must test the feed to get the certificate to trust it. It's not possible to test the object from VSX firewalls or from VSs on them, so if you only have VSs available, you can't test it. The VS will fetch the URL in the object as expected, but it won't actually work because it doesn't trust the cert.

I have a management which only has VSX firewalls reporting to it. Went to a fair amount of trouble to of upgrade to R81.20 because we want to use Network Feed objects, and now we find out we can't. Deeply irritating.

[PhoneBoy]

I'll check with R&D to see if there's a CLI workaround for this on VSX.

[PhoneBoy]

In some cases, it appears that VS0 can be used to use the "Test Feed" option.
That was done in the lab by TAC...and I suspect most customers using VSLS won't be able to do that.

Anyway, this limitation is actually documented: https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_ThreatPrevention_AdminGuide/...

There is at least one open task with TAC CFG on this issue.
I'm also seeing if there's another way to establish this trust without standing up a non-VSX gateway.

[Bob_Zimmerman]

It is listed there, but none of my diamond support reps or ATAMs were aware. The task is probably from me. 😉

The only problem is the certificate trust. The network feed log ($FWDIR/log/efo_error.elg) clearly has cURL error codes. We found if we specify the CA bundle $CPDIR/conf/ca-bundle.crt via cURL's --cacert option, the VS is able to fetch the feed on the command line. We just can't figure out how to get the cert bundle to the instance of cURL being used to populate the Network Feed object.

[PhoneBoy]

I didn't check, but it probably is yours 😉
I have a separate thread going internally with R&D on this.