 Re: Open or Closed
Yep - you are following the right strategy, all good.
By mentioning OpenView, I was just referring to an example of a program that can easily be configured to use a restricted port range - it doesn't change other programs. Each program is different - some you can configure to use a restricted port range, some you can't. You're going to need to consult some documentation, I'm afraid - check with the vendor of this remote control software, to see what their recommendations are for using it in a firewalled environment. Some vendors are clueless about this, others will be able to provide documentation explaining what you need to do.
Sometimes you can restrict the OS itself - e.g. with Windows you can configure it to use a restricted port range for its RPC stuff. I've done this before, with a few regedit hacks. This is documented in Microsoft's knowledge base.
The other strategy depends on Check Point understanding the application. I don't know what your Check Point experience is, but normally you only define rules in one direction - e.g. hostA -> hostB -> ssh.
When the traffic passes through, it sees the session start, and stores that in its connections table. When the reply comes back, to a random port, it matches it, and allows it through.
That's fine for basic applications. But consider FTP. You connect on port 21, and run commands. But then when you go to retrieve a file, it switches to a random high port (for passive FTP), or port 20 (for active FTP). Yet in your rulebase, you only need to enter a rule for the "ftp" service. The key is in the advanced configuration for that service. Check Point supports a range of L-7 protocols - e.g. ftp, rshell, IIOP, Citrix, etc. It also supports RPC services, where you define the Program number, and DCE where you define the Interface UUID.
What happens is that Check Point looks at more than just the packet header - it also inspects the content, sees the dynamic ports being requested/allocated in the control packets, and then allows those dynamic connections when it sees them.
It's not always foolproof, and you will have the odd problem - e.g. if MS changes the way something works. If Check Point doesn't already support the protocol/application you're using, then you could in theory write your own INSPECT code to match it yourself, but that is non-trivial. If this system is using RPC calls, then you may just have to define another RPC service, with the required Program number.
Does any of that make sense?  |