Checkpoint Management server on Live IP

[chrisukcov]

We have a Checkpoint NG 55 hardware firewall install with the management server ~(win2k) having a live Ip on the internet. But it runs SecureServer on this box with all services Hardened in Win2k

We had a security audit and they said this should be Static Natted behind the firewall.

The company that installed it is telling us the installs fine and is pefectly secure.

Whats other peoples views on the above?

Chris

 

[wirelesspeap]

Chris,

Are you telling that the Management server (win2k) is sitting out on the Internet and outside of the checkpoint firewall?

If this assumption is correct, your management server is a windows 2k box, it does NOT, by default, has no firewall protection, SecureServer can provide some protections but not ALL. IT IS NEVER A GOOD IDEA TO PUT A WINDOWS BOX OUT THERE ON THE INTERNET WITHOUT FIREWALL PROTECTION.

If you do NOT want to re-IP the windows box and move it behind the firewall, you can put the management server behind the firewall but in a "dedicated" DMZ segment with public IP. That way, you still have public ip on the server and yet it will be protected by the firewall.

wireless

 

[ChrisAC]

I agree with wireless on this one. What's the point in having Firewall-1 and then putting the server that manages it live on the internet. You've basically weakened the security of the whole solution.

It's a bit like locking your front door of your house but then leaving the key under the plant pot.

Chris.

**********************
Chris A.C, CCNA, CCSA
**********************

 

[chrisukcov]

Weve been told it was so that the Management server can communicate with the remote Nokia IP120 boxes we have. The company said they could but it behind the FW and Nat it but its a 2 day job and would cost us just under £2000. Hes absolutely sue that it is secure. It has the firewall module loaded onto the FW-Management server and it gets pushed the same policy as the hardware firewalls. Weve had penetration tests and its been fine also.

Does the above make it any clearer, im thinking its fine but wanted other peoples valued opinions
C

 

[ChrisAC]

Ah, if the management server also has the firewall module as well then that's all together different. I still don't understand why they've built it like that though. We always put the management server behind the main gateway.

Each to their own I suppose.

Chris.

**********************
Chris A.C, CCNA, CCSA
**********************

 

[shaggerTM]

The reason for building the management server with an real Internet address is so that other firewall modules (elsewhere on the Internet) can correctly load their policies on reboot, from the management server, and correctly log to the management server without messy NAT rules all over the place.

NG fundamentally changed the management architecture, in many ways for the better. The one drawback is that using SIC based authentication, the management server object with a private (RFC1918) address will be unreachable for any modules that are not local to it. Many cludgy NAT solutions have been used, by many people to work around this change, but the cleanest, most elegant solution is simply to have the management server with a real Internet address. No NAT solution can work UNTIL the policy is loaded, and the policy cannot load unless the module can reach the management server. (Cached policies notwithstanding and not overly reliable).

As for the security of it, do you really think that a Solaris, Linux or even IPSO based management server without a firewall module installed and CORRECTLY CONFIGURED would be much less vulnerable to attack if it were outside the firewall(s) than Win2k+? Do you believe that simply placing the management server behind the firewall will protect it ? Protection depends on properly written rules, not physical location.

I would agree, that if the management server ONLY controls local firewalls, it would be unneccessary to have the management server on the Public address space at all. Nonetheless, if it's been built with a properly configured Secure Server module, it's a moot point, there is no security implication providing the rulebase properly protects it.

Lastly, is there really any difference, in security terms, between a DMZ with RFC1918 addresses for it's hosts and NAT'd inbound connections, and a DMZ with public addresses on it, with nothing but the firewall rules to protect the hosts ?

Answer: Of course not.. logically it's the same thing, and at the end of the day it's the rulebase in all cases that creates the security.


========================================
Find out about what I do for a living at

http://www.ascltd.co.uk

========================================

 

[ChrisAC]

The reason for building the management server with an real Internet address is so that other firewall modules (elsewhere on the Internet) can correctly load their policies on reboot, from the management server, and correctly log to the management server without messy NAT rules all over the place."

I have to disagree with this statement. I always have the management server behind the firewalls and with very simple NAT rules all the remote modules pick up their security policy on reboot with no problems at all. Granted, it was a learning curve at first and we did have SIC issues but now we have the procedure it takes no time at all to configure, is very simple and works perfectly.

I agree with all your other points though. Any firewall is only as good as the security rules on it and the person who configured it. You wouldn't believe how many Checkpoint installations I have seen with one rule (yes, allow any any .... but everything works okay ... *sigh*).

Good points.

Chris.

**********************
Chris A.C, CCNA, CCSA
**********************

 

[rn4it]

Chris
I disagree with Shaggers point that it must be on the public internet for when the remote enforcement modules boot up. Although are mgmt module is internal we only allow the specific port necessary for the enforcement modules to talk to the management module. You could do the same thing were the management module is behind your encforcement modules and you allow the public IP's of your remote enfocement modules to come through your FW on those specific ports to get to your mgmt server. At that price, if you have technical staff I'd spend it on training and have them move it. I'm not sure how much FW related work is done there, or what the monthly maintenance is, but if you have compentant staff why not have them take care of it. Do you every get any reports on rulebase activity? or check up on any rules?, do you know if there are any inappropriate rules? just my 2cents

 

[shaggerTM]

Technically, the issue here is that the module sees the management server by the IP address you use on the General Tab of the managemeht server object.

When this is (correctly) set to an RFC1918 address because the management server is inside a gateway, the remote module will (correctly) attempt to load policy from an unreachable address.

I didn't say that it *must* be on a public address, rather that things are simplest and most reliable when this is the case.

If you revert to the manual 4.1-esque Masters file, then this isn't such a problem. If you use automatic NAT for the management server this may also not be a problem (I've never tried it), but automatic NAT brings it's own problems (and insecurities) and is a tool for the otherwise incompetent IMHO.

If you use NG as it was intended, defining loghosts and masters in the gateway object properties, then the problem I have described does exist and *can* cause problems. The solution I described isn't the only solution, but it *does* solve this problem, elegantly and cleanly, without the overhead of NAT rules on the local gateway, and without adding any insecurity to the perimiter configuration.

rn4it is correct, in that creating rules to allow access to a published address through a gateway (or gateway pair) will work, but only if the remote gateway sees the management server by it's public IP address rather than it's true (internal) address. Yes, you can frig the hosts file, but that isn't reliable on all FP-x or R5x releases (it seems to change from release to release). My suggested solution simply works, that's all. Let's face it, in Check Point terms, £400-£500 for a Secure Server license is not a lot of money, if you already have an Enterprise Management license and at least 2 gateways !

(Oh and rn4it, I don't manage a firewall installation, I design, implement and support *many* firewall installations, from single gateways to large multi-site global VPNs, to e-commerce systems for blue-chips and high street names, where there are multiple layers and technologies, not just a bit of Check Point. We routinely solve problems for our customers when vendors like Check Point have simply overlooked the scenario we are trying to deliver in their core product design, because they can't think of everything. I'm not claiming to know it all... but when I post, it's based on genuine, real-world experience gained over the last 20+ years of doing data security (not just Check Point) in all it's forms. That said, I don't mind a discussion, and I'll even admit I'm wrong when I am... it just doesn't happen very often *grin*. No flame intended...).

shaggerTM

========================================
Find out about what I do for a living at

http://www.ascltd.co.uk

========================================

 

[rn4it]

Sorry Shagger but I took "The reason for building the management server with an real Internet address is so that other firewall modules (elsewhere on the Internet) can correctly load their policies on reboot" as a must. Which I disagreed with and I stated a different view, giving another option. No flame taken, I don't don't offend easy.

 

[shaggerTM]

Just as well.. I was having a bad day yesterday... LOL !

========================================
Find out about what I do for a living at

http://www.ascltd.co.uk

========================================