RPC Dynamic Ports? Windows 2003 with Checkpoint firewall.

Just offer more ports. One port won't be enough.

But, because I see that you're talking about Windows domains, why not considering implementing an encrypted VPN for hosting the complete domain, without filtering in it?

Windows' domain concept is very comfortable because of it's functionality, but it is very unsecure.

Yours, VB.

Fine, sit and back, relax and be happy since you not want machines that can be accessed from the internet - which I aussume to be the case for a machine located in a DMZ - to be part of your Domain/AD.

Wolfgang

Volker Birk ( snipped-for-privacy@dingens.org) wrote: : techcs wrote: : > I have tried the fixes from microsft to limit the rpc port to one port : > but in turn this stopped the domain working correctly internally and as : > I have over thirty servers as well this did not seem a good idea.

: Just offer more ports. One port won't be enough.

: But, because I see that you're talking about Windows domains, : why not considering implementing an encrypted VPN for hosting : the complete domain, without filtering in it?

The OP is discussing how to pass Microsoft RPC from one interface to another within the same checkpoint enforcement module. This is what the enforcment modules are designed to do and there is no reason for a VPN since the traffic is only traversing the module and is never on the net.

To the OP

What is the specific log entries in Smartview tracker. What rules are being invoked. Blindly opening up ports is not the way to resolve this. Instead look at the log and see what is being blocked. What specific elements of Smartdefense have you enabled?

Richard H. Miller, MCSE, CCSE+ Information Security Manager Information Technology Security and Compliance Information Technology - Baylor College of Medicine

Then this type of filtering does not make sense. Why should one filter in between one trusted host and another, when they're connected directly?

Yours, VB.

Thanks for all the replies..

Just to confirm to setup of my DMZ.. I only have a member server in the DMZ and this is to authenticate end users on the internet to access Mailboxes via Outlook Web Access. Now OWA will only work if the domain users are allowed to log on locally at this member server in the DMZ so as a result it needs to talk back to the domain. Two exchange servers are in the internal network.

Checkpoint has a rule to allow all traffic from this member server to talk back to our internal network. Now as all traffice is allowed it is only this smartdefense causing a problem, as this does not have much config to it. Its either on blocking all dynamic ports or off which I can type in a list of ports which I can block ( I would be there days typing in ports!!!)

Basically this smartdefense should interpret MS RPC calls but it is not, now this worked with the 2000 domain?? Would like to know what changed in the way RPC calls are made with 2003?

I much appreciate all the replies...

Colin

To Richard H. Miller

The logs just say Smartdefence has blocked a dynamic port. Deny...

There is only three options in the Smartdefence config.

1 - all ports unfiltered 2 - Deny all Defined services ports 3 - Deny ports listed below

Oh and it is blocking low ports by default ( under 1024)

Currently I have taken the smartdefence off ( number 1 above)

This section is just for dynamic ports might I stress....

Cheers Col

Volker Birk ( snipped-for-privacy@dingens.org) wrote: : Richard H. Miller wrote: : > The OP is discussing how to pass Microsoft RPC from one interface to another within : > the same checkpoint enforcement module. This is what the enforcment modules are : > designed to do and there is no reason for a VPN since the traffic is only traversing : > the module and is never on the net.

: Then this type of filtering does not make sense. Why should one filter : in between one trusted host and another, when they're connected directly?

You do understand the purpose of a 'DMZ' in an enterprise firewall security security setup? You have multiple interfaces, each with a LAN behind it and a different security policy for that interface. The classic is a DMZ in which you have a set of machines that you need to be visible to the internet. They will require some access to specific services that exist on machines that exist in the internal LAN so the policy needs to be written to allow those machines to obtain the specific services. In the case of the OP, he has put a member server into the 'DMZ' and has decided that allowing it to participate in his domain is an acceptible risk so wants the DCE-RPC traffic to pass from that member server to his DC. Other traffic between the two is outside of policy and should not happen.

This is the entire point, you define a policy to specify the appropriate traffic between host in one zone to another. Bear in mind, Checkpoint with smartdefense is an enterprise firewall implementation

specific services

When I setup RPC I set my rules, in a WatchGuard unit, to allow access from the LAN to the DMZ machine, but then only allow the machine in the DMZ to contact the LAN machines IF the LAN machine made the first contact.

What this means is that the LAN hosts can reach the Server in the DMZ and get data, but the hosts in the DMZ can not contact the LAN without the LAN machines contacting them first.

One other thing - I NEVER, NEVER, NEVER, setup a DC in the DMZ unless it's a stand-alone DC with no accounts in the LAN.

As an example, I put a Exchange server in the DMZ, but it's a stand- alone Domain and is not connected to ANY of the LAN domains.

If you mean "demilitarized zone" with DMZ, a common name for a filtered zone with a middle level of security in a zone concept, yes, I do.

specific services

OK, then we have the error here. It is a very bad idea to have a domain, which is in a high security zone and in a DMZ at the same time.

This should never happen; it's a design flaw, because it breaks the principle of separation, which is the basic idea of a zone concept after all.

Yours, VB.

Good idea.

Yours, VB.

Perhaps it would be a good idea, if you'll have an application gateway, say: a proxy server in the firewall, and have the OWA server inside.

And even better: only offer this service with HTTPS and an authentification for the proxy server first. The best possibility would be a VPN, which ends at the application gateway.

And don't forget to do filtering on the AG, so only what you want to offer is possible being received.

Windows' domain concept is not secure, and it's not a good idea to have it through the zones.

Yours, VB.

techcs ( snipped-for-privacy@blueyonder.co.uk) wrote: : To Richard H. Miller

: The logs just say Smartdefence has blocked a dynamic port. Deny...

: There is only three options in the Smartdefence config.

: 1 - all ports unfiltered : 2 - Deny all Defined services ports : 3 - Deny ports listed below

: Oh and it is blocking low ports by default ( under 1024)

: Currently I have taken the smartdefence off ( number 1 above)

: This section is just for dynamic ports might I stress....

: Cheers : Col

OK...what version of Checkpoint are you running? Do you have the Smartdefense subscription service?

I just checked our dynamic port configuration

Here is what it says

Attack Description: This page allows you to configure which ports are "privileged ports" that will be protected when opening a connection dynamically (for example FTP data connections). These ports are a subset of the ports of the TCP and UDP services defined. In addition, it is possible to explicitly protect low ports (lower than 1024). ==

Now, what this means when we did not have it selected for 'allow' is that anytime a session that used random dynamic ports [which I believe DCE-RPC does] that corresponds to a defined service port [such as say PC Anywhere 5631/TCP] Smartdefense will block it on the assumption that it is trying to open a session to that service even if PC Anywhere is not running on the target but the protocol is simply trying to use that port for a dynamic session opened up. You would see a similar error when trying to use FTP and the serive attempted to use one of these ports for the dynamic data session.

Bear in mind that these dynamic ports are being opened by the inspect engine because it has been monitoring the protocol and the requested dynamic port is one the protocol is expecting.

It is part of the decision you need to make when defining your security policy. If you have things tightly controlled and do not allow arbirary machines to initiate contact with the outside, it is probably not a bad risk to allow all ports on this configuration tag. This

*is not* the same thing as opening all high order ports. These dynamic ports are opened as required for a specific session and close down when the session ends.

Rick

If you set it up that way there is no point in it being in a DMZ - as any account that can authenticate with the server in the DMZ has full access to the LAN - so, if compromised you just let everyone into your LAN.

What you should have done was setup a unique DOMAIN in the DMZ with exchange installed on it - one that is not part of any other domain and definitely not a member of your LAN domain.

Some firewalls allow you to setup so that a LAN to DMZ rule works with their RPC connection to only allow a DMZ connection back through to a LAN initiated connection. Meaing that the DMZ system can't talk to the LAN system until the LAN system contacts the domain system first.