Best way to halt traffic during a malware outbreak...

[eth4_]

Hello CheckMates,

During a recent tabletop exercise during which we assessing our incident response plan, security received a request to shutdown all in-bound and all out-bound traffic.  Given that access to SmartConsole may be impacted, what are your ideas for the best way to handle this request?

Some ideas:

• Power off the gateway
• Admin-down the interfaces
• SAM rules (though I don't know how I could quickly write one to deny 'not RFC-1918 address space')
• Black-hole the traffic using routing
• Install a 'Shields Up' policy

Thank you for your thoughts.

SM

[PhoneBoy]

Probably the easiest thing to do is: cpstop -fwflag -default which is documented here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
This will stop all firewall processes, disable routing, and load the default filter.
Since this will also prevent SSH access to the gateway, you will need to have console access to recover from this, which a simple cpstart will achieve.

[the_rock]

I could be mistaken when I say this, but I believe what @PhoneBoy provided is same as initial policy on the firewall, which is definitely what you would want in this instance. Or if I recall, it may add some default implied rules to default filter policy...

[PhoneBoy]

I believe the initial policy actually allows SSH.
The default filter does not.

[HristoGrigorov]

If by "inbound" and "outbound" traffic they mean coming from and going to Internet then it is probably best to login and shutdown all Internet interfaces on the gateway. That will leave management interface operational.

[Tim_Otis]

Love the 'Shields Up Policy' term.

This often becomes an in-depth discussion when our team conducts IR tabletops for CPIRT customers. The answer is situational but more often than not the "shields up" approach is what most enterprises end up with these days. In addition to the concerns of access to gateways via Smart Console, today there are often other requirements for connectivity that don't permit the old-school approach of a wirecutter/shutdown. Some examples we have come across that make this an interesting problem:
- All logging goes offsite - When using cloud logging/monitoring services (e.g. Datadog) or a cloud SIEM, blocking the internet may cause critical logs to disappear during an incident.
- Managed Detection and Response - When leveraging a 3rd party to triage and respond to endpoint events, blocking the MDR vendors access will likely limit their visibility and ability to assist/respond.
- DR site replication - This is more tricky and runs risks of replicating a malware infection, malicious software, or maliciously manipulated databases but can also save the day depending on timing and scale of infection within a primary site.
- Corporate Infrastructure in the Cloud - Also tricky, it may be required to keep access open for fileshares (did we print our IR plan on paper or is it on a Sharepoint server we can't access) , SSO systems, comms platforms (like cloud email or chat applications), offsite backup infrastructure etc.
- Simple things like NTP and DNS - Depending on network and system configuration, external NTP and DNS may be required to continue logging accurately. 

There are usually several operational considerations that should be taken into account when making an IR plan. It is definitely situational and isn't exactly a one-size-fits-all answer.  Typically, customers nowadays need a 'Shields Up' Policy on standby that only permits access to external services that are absolutely critical (cloud SIEM, MDR Vendor, etc), then blocks all other traffic that would normally be permitted by the everyday policy.