RPC Dynamic Ports? Windows 2003 with Checkpoint firewall.

[Guest]

Archived from groups: comp.security.firewalls (More info?)

Hi,

I'm hoping someone can help me with my problem.

I have recently upgraded our 2000 DC's to 2003 and as a result our
member server in our DMZ has now stopped talking to our DC's.

Now this was fine before the upgrade (2000 Domain)... We have a
checkpoint firewall which has SmartDefence which is basically blocking
the RPC traffic as it is trying to open up ramdom ports to talk back to
the member server (Dont know what has changed with 2003 as the firewall
has stayed the same).

If I disable the Smart Defence all is OK.

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.
(There was another fix where I can range the ports but I suspect the
firewall will treat these as dynamic anyway and deny as well...)

I am basically asking if there have been changes to the RPC calls
between 2000 and 2003??

Any help would be appreciated, I'm baffled, and the checkpoint support
is not much good, seem as the software should distinguish that it is a
MS RPC call and allow but it doesn't!!

Cheers
Col

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

techcs <colinsealeaf@blueyonder.co.uk> 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?

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

Yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

techcs wrote:

> Hi,
>
> I'm hoping someone can help me with my problem.
>
> I have recently upgraded our 2000 DC's to 2003 and as a result our
> member server in our DMZ has now stopped talking to our DC's.

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

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

Volker Birk (bumens@dingens.org) wrote:
: techcs <colinsealeaf@blueyonder.co.uk> 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

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

Richard H. Miller <rick@bcm.tmc.edu> 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?

Yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

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

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

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

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

Volker Birk (bumens@dingens.org) wrote:
: Richard H. Miller <rick@bcm.tmc.edu> 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

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

In article <dea13h$stp@gazette.corp.bcm.tmc.edu>, rick@bcm.tmc.edu
says...
> 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

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.


--

spam999free@rrohio.com
remove 999 in order to email me

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

Richard H. Miller <rick@bcm.tmc.edu> 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?

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.

> 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.

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.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

Leythos <void@nowhere.lan> wrote:
> 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.

Good idea.

Yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

techcs <colinsealeaf@blueyonder.co.uk> wrote:
> 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.

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.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

techcs (colinsealeaf@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

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

In article <1124654225.654756.20140@g43g2000cwa.googlegroups.com>,
colinsealeaf@blueyonder.co.uk says...
> 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.

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.


--

spam999free@rrohio.com
remove 999 in order to email me

 

[mike-wasowsky]

Folks, what about the direction of the DCE-RPC? I believe the source network/IP should be the destination IP and the destination should be the source network/IP right?