Open or Closed

[EAP56]

Hi, if I am not mistaken there are only two strategies that can be incoporated in the setup of the classic firewall rules. They are;

- Block specific ports and allow all others
- Allow specific ports and block all others

I attempted to use the "Allow specific ports and block all others" strategy. Basically, I would monitor the traffic that a PC is recieving or sending and create rules that would allow only the traffic that I saw appropriate. What I have noticed is that there are applications that require to use random ports from 1024 to 65534. One such example is a remote control software that we use. All PC's have this software and therefore all PC's need to be able to communicate on all those ports. This almost negates the firewall.

What strategies have you incorporated for your firewall rules?

Thanks.

[northlandboy]

Block everything except that which is explicitly allowed is the only sane approach. Blocking only specific ports is just stupid, and will not protect your network effectively.

Regarding dynamic traffic, you've got two options:
* Use Check Point or similar to perform a deeper inspection of the traffic, so that it is aware of what the dynamic traffic is, and only allows what's required
* Configure the application to use a restricted range of ports. With OpenView e.g., this is quite straightforward.

[EAP56]

Originally Posted by northlandboy

Block everything except that which is explicitly allowed is the only sane approach. Blocking only specific ports is just stupid, and will not protect your network effectively.

Regarding dynamic traffic, you've got two options:
* Use Check Point or similar to perform a deeper inspection of the traffic, so that it is aware of what the dynamic traffic is, and only allows what's required
* Configure the application to use a restricted range of ports. With OpenView e.g., this is quite straightforward.

What you stated in your first paragraph above is precisely what we are doing.

Can you expand on your other two points? We don't have OpenView therefore I imagine we can not restrict the application to a range of ports. Any other suggestions?

Thank-you for your assistance.

[northlandboy]

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?

[EAP56]

What you posted makes perfect sence. However, I don't believe that the Integrity firewall is behaving like you described. At least from my point of you it isn't.

The software I am having problems with is called RADMIN from Sunbelt software (remote adminstration tool). Technical support basically explained something along the lines of what you said. However, they asked whether I can set up the firewall using "Application based security" rather than manage the ports.

Integrity provides the ability to manage applications however the hiarchy for rule evaluation is Classic Firewall Rules -> Restricted Zone -> Program Rule. I'm getting blocked at the Classic Firewall Rules section.

MS Remote Control Agent from MS Systems Management Server gives me the same problems.

Not sure what other type of configuration I can try.

Thanks for your help.

[EAP56]

Correction to the post above.

I was able to get MS SMS remote control agent to work with the Integrity Firewall. I obtained a paper from Microsoft identifying the port requirements for their remote control agent. Two ports is all that was required.

I guess I will not waste any more time to get Radmin to work.

Thanks.

[northlandboy]

Yeah, sometimes you gotta admit defeat with some RPC stuff. The other strategy I meant to mention is that sometimes all you can do is restrict source/destination, and basically allow high ports.