RPC Dynamic Ports? Windows 2003 with Checkpoint firewall.

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
14 answers Last reply
More about dynamic ports windows 2003 checkpoint firewall
  1. 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"
  2. 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
  3. 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
  4. 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"
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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"
  10. 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"
  11. 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"
  12. 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
  13. 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
  14. 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?
Ask a new question

Read More

Firewalls Windows Server 2003 RPC Networking