IPS Protect internal hosts only - recommendation

[Dende]

Hi guys,

I got a question regarding IPS:
Is it useful, or recommended to activate the IPS system only from external to internal, ie:

-------------
Protect internal hosts only:
If you select this option, the gateway protects only the internal network. This does not mean only did internal traffic is inspected. If a network object protected by one of the server-client protections is attacked, IPS inspects the internal to external traffic as well.
-------------

Or would you say for safety it is better to externally to protect internally with IPS, ie:

-------------
Perform IPS inspection on all traffic: the gateway will inspect all traffic Regardless of its origin or destination.
-------------

From intern will anyway surfed via a Sophos firewall with Web proxy and the client is of course a virus scanner on it!

Whats your opinion?

[ShadowPeak.com]

Hi guys,

I got a question regarding IPS:
Is it useful, or recommended to activate the IPS system only from external to internal, ie:

-------------
Protect internal hosts only:
If you select this option, the gateway protects only the internal network. This does not mean only did internal traffic is inspected. If a network object protected by one of the server-client protections is attacked, IPS inspects the internal to external traffic as well.
-------------

Or would you say for safety it is better to externally to protect internally with IPS, ie:

-------------
Perform IPS inspection on all traffic: the gateway will inspect all traffic Regardless of its origin or destination.
-------------

From intern will anyway surfed via a Sophos firewall with Web proxy and the client is of course a virus scanner on it!

Whats your opinion?

I covered this pretty thoroughly in my book, here is the text:

Perform IPS Inspection on all Traffic – This is typically the default setting. All
traffic regardless of direction has IPS inspection applied. This includes traffic passing
from one Internal network (like a DMZ) to another, as well as connections to or from
External interfaces. “Internal” in this context means any interface defined as Internal on
the firewall/cluster object’s topology screen in the SmartDashboard.

This is the default setting; it will essentially force almost all traffic passing through
the firewall into at least the Medium Path. Very little traffic will be subject to throughput
acceleration, and performance will be negatively impacted. There is even a warning
issued if you select this option; something to the effect of “Turning on this option may
have an adverse impact on performance”.

Protect Internal Hosts Only – When selected, IPS protections are only applied to
packets traveling to a network defined as “Internal”. “Internal” in this context means any
interface defined as Internal in the firewall/cluster object’s topology anti-spoofing screen
(DMZs as well). This includes traffic passing from one Internal network (like a DMZ) to
any other Internal network.

It does not matter whether the connection was originally initiated from an External or
Internal interface; any packet attempting to leave the firewall towards an Internal
interface will have IPS protections applied. Traffic whose destination is an External
interface (typically going to the Internet or perhaps a site-to-site VPN utilizing the
Internet) will not have IPS protections applied with Protect Internal Hosts Only set, and
will probably be able to take the Accelerated Path, assuming no other firewall features
are enabled that require Medium Path processing for that same traffic.


From purely a security perspective, one could argue that Perform IPS Inspection on
all Traffic is always the right setting (it is the default after all!). Of course we want the
IPS to prevent attacks against our internal and DMZ systems. But what about traffic
leaving your network bound for a system on the Internet? What about traffic entering a
VPN tunnel bound for a business partner or vendor across the Internet? Shouldn’t your
firewall ensure that possible attacks emanating from your internal network don’t target
your partners? One could assert that the remote parties should take steps to protect
themselves, but try telling that to a key business partner whose network just got crushed
by a worm or attack launched from inside of your own network! Also consider the
positioning of the subject firewall in your network; the correct setting is likely to be
different for a firewall deployed on the perimeter of your organization as opposed to
another firewall buried deep inside your internal network with no direct Internet access.

As with any topic in security, it is a matter of trade-offs. As we all know, the answer
to many security-related questions will very frequently begin with: “Well that
depends...”. This may frustrate upper management decision-makers, but ensures
excellent job security prospects for security administrators. Leaving the default setting
Perform IPS Inspection on all Traffic enabled is pretty common in most environments,
however if your Firewall Worker cores are perpetually overloaded and you can’t allocate
any more Firewall Workers due to a shortage of cores, consider setting Protect Internal
Hosts only for IPS inspection.

[sebastan_bach]

Thanks for the detailed write-up shadow. So the protect internal hosts is not limited to the interfaces named as internal in the Firewall Objects right. It refers to any interface that has private IP Address assigned like you mentioned for the DMZ interfaces also considered as internal.

I mean if I have an interface called as extranet with an Private Address Space then would it still consider the interface as internal and apply IPS protections to it.

Can you please clarify on the same.

Regards

Sebastan

[ShadowPeak.com]

Thanks for the detailed write-up shadow. So the protect internal hosts is not limited to the interfaces named as internal in the Firewall Objects right. It refers to any interface that has private IP Address assigned like you mentioned for the DMZ interfaces also considered as internal.

I mean if I have an interface called as extranet with an Private Address Space then would it still consider the interface as internal and apply IPS protections to it.

Can you please clarify on the same.

Regards

Sebastan

All that matters is whether the interface is set to Internal or External on the Topology page of each interface. Pretty sure this setting does not care about the IP addressing.

However your query did raise another question in my mind: what happens if the interface is not defined in the firewall's topology at all? I know in the case of APCL/URLF it considers the missing interface as External and part of object "Internet". I assume IPS would do the same but may have to lab that up and test it. So if my assumption is correct, if an interface is missing from the firewall's topology and "Protect internal hosts" is set, there would be no IPS protections applied to traffic leaving on that interface.

[laf_c]

Thanks for the detailed write-up shadow. So the protect internal hosts is not limited to the interfaces named as internal in the Firewall Objects right. It refers to any interface that has private IP Address assigned like you mentioned for the DMZ interfaces also considered as internal.

I mean if I have an interface called as extranet with an Private Address Space then would it still consider the interface as internal and apply IPS protections to it.

Can you please clarify on the same.

Regards

Sebastan

I also suggest you really look for the book. It will worth every penny and make you a better engineer, mate.

[sebastan_bach]

All that matters is whether the interface is set to Internal or External on the Topology page of each interface. Pretty sure this setting does not care about the IP addressing.

However your query did raise another question in my mind: what happens if the interface is not defined in the firewall's topology at all? I know in the case of APCL/URLF it considers the missing interface as External and part of object "Internet". I assume IPS would do the same but may have to lab that up and test it. So if my assumption is correct, if an interface is missing from the firewall's topology and "Protect internal hosts" is set, there would be no IPS protections applied to traffic leaving on that interface.

Thanks a lot Shadow.

Regards

Sebastan

[Dende]

Hey Shadow,

I want to repeat, that I understand it right:

All Traffic came from Extern Interface (Topology = External) to Intern (DMZ or Intern -> Topology = Internal) it will be protected via IPS
All Traffic came from Intern Interface (Topology = Internal) to DMZ (Topology = Internal) or Extern = Internet (Topology = External) wil not protected
All Traffic came from DMZ Interface (Topology = Internal) to Intern (Topology = Internal) will not protected

Regards,
Dende

[ShadowPeak.com]

Not came from (ingress), but leaving on (egress) is what this setting impacts. What interface the traffic arrived on originally is not relevant to this IPS setting. DMZs are considered equivalent to Internal interfaces in this case since their topology setting is Internal.

So to edit your statement when IPS "protect internal hosts only" is set:

All Traffic to Intern (DMZ or Intern -> Topology = Internal) will be protected via IPS

All Traffic to DMZ (Topology = Internal) WILL BE protected by IPS

Traffic to Extern = Internet (Topology = External) will not protected

All Traffic to Intern (Topology = Internal) WILL BE protected

All traffic to an interface not defined in the firewall's topology at all WILL NOT be protected (I'm assuming this one for now, may not be correct).

[jjsilvo]

I found this thread while searching information about IPS - Protect internal hosts only setting. I've have purchased and read that Shadow Peak's Max Power Check Point optimization book. But I'm still wondering, how is reverse packets inspected.

If I have chosen "Protect internal hosts only" and user is browsing the internet (from internal to external), that outgoing traffic is not inspected with that setting. That's reasonable. But if he/she downloads something, then that traffic is not initiated from the external to internal but it's just reverse traffic to original internal to external traffic. Is it inspected or not?

Based on this I think, it should be inspected:
"...any packet attempting to leave the firewall towards an Internal interface will have IPS protections applied."

And this:
"IPS protections are only applied to packets traveling to a network defined as “Internal”.

But I didn't find anywhere an exact information how reverse traffic is handled.

[ShadowPeak.com]

I found this thread while searching information about IPS - Protect internal hosts only setting. I've have purchased and read that Shadow Peak's Max Power Check Point optimization book. But I'm still wondering, how is reverse packets inspected.

If I have chosen "Protect internal hosts only" and user is browsing the internet (from internal to external), that outgoing traffic is not inspected with that setting. That's reasonable. But if he/she downloads something, then that traffic is not initiated from the external to internal but it's just reverse traffic to original internal to external traffic. Is it inspected or not?

Based on this I think, it should be inspected:
"...any packet attempting to leave the firewall towards an Internal interface will have IPS protections applied."

And this:
"IPS protections are only applied to packets traveling to a network defined as “Internal”.

It will be inspected by IPS.

But I didn't find anywhere an exact information how reverse traffic is handled.

Whether the traffic is reverse (or return), doesn't matter. If the packet is trying to leave towards an interface marked as Internal it will be inspected by IPS.

[jjsilvo]

It will be inspected by IPS.

Whether the traffic is reverse (or return), doesn't matter. If the packet is trying to leave towards an interface marked as Internal it will be inspected by IPS.

Excellent. Thank you for the clarification and quick reply!

[danwestlund]

I covered this pretty thoroughly in my book, here is the text:

Perform IPS Inspection on all Traffic – This is typically the default setting. All
traffic regardless of direction has IPS inspection applied. This includes traffic passing
from one Internal network (like a DMZ) to another, as well as connections to or from
External interfaces. “Internal” in this context means any interface defined as Internal on
the firewall/cluster object’s topology screen in the SmartDashboard.

This is the default setting; it will essentially force almost all traffic passing through
the firewall into at least the Medium Path. Very little traffic will be subject to throughput
acceleration, and performance will be negatively impacted. There is even a warning
issued if you select this option; something to the effect of “Turning on this option may
have an adverse impact on performance”.

Protect Internal Hosts Only – When selected, IPS protections are only applied to
packets traveling to a network defined as “Internal”. “Internal” in this context means any
interface defined as Internal in the firewall/cluster object’s topology anti-spoofing screen
(DMZs as well). This includes traffic passing from one Internal network (like a DMZ) to
any other Internal network.

It does not matter whether the connection was originally initiated from an External or
Internal interface; any packet attempting to leave the firewall towards an Internal
interface will have IPS protections applied. Traffic whose destination is an External
interface (typically going to the Internet or perhaps a site-to-site VPN utilizing the
Internet) will not have IPS protections applied with Protect Internal Hosts Only set, and
will probably be able to take the Accelerated Path, assuming no other firewall features
are enabled that require Medium Path processing for that same traffic.


From purely a security perspective, one could argue that Perform IPS Inspection on
all Traffic is always the right setting (it is the default after all!). Of course we want the
IPS to prevent attacks against our internal and DMZ systems. But what about traffic
leaving your network bound for a system on the Internet? What about traffic entering a
VPN tunnel bound for a business partner or vendor across the Internet? Shouldn’t your
firewall ensure that possible attacks emanating from your internal network don’t target
your partners? One could assert that the remote parties should take steps to protect
themselves, but try telling that to a key business partner whose network just got crushed
by a worm or attack launched from inside of your own network! Also consider the
positioning of the subject firewall in your network; the correct setting is likely to be
different for a firewall deployed on the perimeter of your organization as opposed to
another firewall buried deep inside your internal network with no direct Internet access.

As with any topic in security, it is a matter of trade-offs. As we all know, the answer
to many security-related questions will very frequently begin with: “Well that
depends...”. This may frustrate upper management decision-makers, but ensures
excellent job security prospects for security administrators. Leaving the default setting
Perform IPS Inspection on all Traffic enabled is pretty common in most environments,
however if your Firewall Worker cores are perpetually overloaded and you can’t allocate
any more Firewall Workers due to a shortage of cores, consider setting Protect Internal
Hosts only for IPS inspection.

With R80.10, it looks like the "Internal hosts only" option is gone. I was told by an SE that it is now the default, and that to go back to protecting all with IPS requires using it in legacy mode or something. Is that true? I had been thinking that this would be controlled in the Threat Prevention policy, but that the default was still to protect all IPS both internal hosts and outbound. Thanks!

[ShadowPeak.com]

With R80.10, it looks like the "Internal hosts only" option is gone. I was told by an SE that it is now the default, and that to go back to protecting all with IPS requires using it in legacy mode or something. Is that true? I had been thinking that this would be controlled in the Threat Prevention policy, but that the default was still to protect all IPS both internal hosts and outbound. Thanks!

Not exactly, if you have an R80.10 gateway IPS can be managed in the same TP profile and policy layer as the other four Threat Prevention blades. As such you can use columns such as Protected Scope and Source/Destination/Service (if you unhide these three) to very precisely specify exactly where you want IPS protections applied. So in short with R80.10 management and an R80.10 gateway, it is no longer just "Protect internal hosts" or "Perform IPS inspection of all traffic", but whatever you want it to be via columns in the Threat Prevention policy layer(s). You can also take the opposite approach and define an explicit rule not specifying IPS with a "null" TP profile (as I call it in my book) that excludes certain traffic from IPS inspection at all, thus potentially making that traffic eligible to be fully accelerated by SecureXL and not go PXL, and then inspect all other traffic with IPS in a later TP rule.

[Bob_Zimmerman]

Well that's nice! I have a few firewalls where the "inside" with moderately-well-defined topology is less trusted than the "outside" with the Internet link. Specifically, users are on well-defined networks, and a datacenter with an Internet connection is on the "outside". The users go through the datacenter to get to the Internet, but we want to protect the datacenter from some user finding a thumb drive and infecting everything.

It takes some ridiculous hoop-jumping to get this working passably in R77.30, since a lot of the threat prevention features use the antispoofing topology to define the trusted versus untrusted networks.

[ShadowPeak.com]

Well that's nice! I have a few firewalls where the "inside" with moderately-well-defined topology is less trusted than the "outside" with the Internet link. Specifically, users are on well-defined networks, and a datacenter with an Internet connection is on the "outside". The users go through the datacenter to get to the Internet, but we want to protect the datacenter from some user finding a thumb drive and infecting everything.

It takes some ridiculous hoop-jumping to get this working passably in R77.30, since a lot of the threat prevention features use the antispoofing topology to define the trusted versus untrusted networks.

Yep IPS was at long last fully integrated with the rest of the Threat Prevention blades in R80.10 gateway. Also Geo Protection was renamed Geo Policy and is no longer part of the IPS blade in R80.10, and as such has its own independent profiles that can be specified separately from whatever IPS profile(s) you are using. In R77.30 Geo Protection was just an inseparable part of whatever IPS profile the gateway was using.

[tomersole']

Yep IPS was at long last fully integrated with the rest of the Threat Prevention blades in R80.10 gateway. Also Geo Protection was renamed Geo Policy and is no longer part of the IPS blade in R80.10, and as such has its own independent profiles that can be specified separately from whatever IPS profile(s) you are using. In R77.30 Geo Protection was just an inseparable part of whatever IPS profile the gateway was using.

you guys should really check the IPS features of R80.20 (sorry for plugging CheckMates): auto updates, tagging, auto prevent, picking countries in the access control policy (not IPS but still), https://community.checkpoint.com/thr...r8020-techtalk

[PhoneBoy]

Further, R80.20 was released today, so you can actually start using these features.