07-11-2011 07:59 AM - edited 03-08-2019 06:42 PM
"Distributed Computing Environment / Remote Procedure Calls", is the remote procedure call system developed for the Distributed Computing Environment (DCE). This system allows programmers to write distributed software as if it were all working on the same computer, without having to worry about the underlying network code.
DCERPC inspection module is responsible for processing the data portion of the packet and performing inspection related tasks such as applying translations to IP addresses and ports contained in the packet when applicable, opening secondary channel etc., with the help of other modules
Since FWSM version 4.1 the inspectione engine has been redesigned and enhanched by RCI (Remote Create Instance) calls over RPC and the processing of RPC messaging.
As Microsoft switched from using pure RPC to use DCOM (ORPC) calls, those non-epm calls will be used more and more. Windows RPC/DCOM services use the RPC Endpoint Mapper to accept initial communications on port 135 and then dynamically transition to ports for the service.
"The OXID Resolver resides at different endpoints (ports) depending on the transport being used. The OXID Resolver optimally resides at the same endpoints as the DCE RPC Endpoint Mapper (EPM). To accommodate systems where DCOM will coexist with existing DCE RPC installations (i.e., where an EPM and presumably a complete DCE RPC runtime already exists), the DCOM implementation on that system will register its interfaces with the DCE EPM and all DCOM implementations must be able to fall back if they make DCOM -specific calls on the DCE EPM endpoint which fail."
Starting with Windows 2000, the ISystemActivator COM interface is used instead of the IRemoteActivation RPC interface.
The IOXIDResolver RPC interface (formerly known as IObjectExporter) is remotely used to reach the local object resolver (OR). The Object Resolver component is in charge to:
CSCsk97762 - ENH: Allow DCERPC inspect to open pin-holes for WMI queries. non epm map
CSCto43960 - FWSM: DCERPC inspection of packet with multiple segments fail
CSCtl25658 - TEA ENH: FWSM DCERPC inspection doesn't support 'Remote Create Instanc
For FWSM users: We recommand to try the 4.0.x version if you do not want to completely disable the inspection to let the traffic through.
class-map dcerpc
endpoint-mapper lookup-operation
match port tcp eq 135
policy-map type inspect dcerpc dcerpc_map
parameters
timeout pinhole 0:10:00
policy-map global_policy
class dcerpc
inspect dcerpc dcerpc_map
service-policy global_policy global
In some cases when lookup operations are not passing throught use this config:
class-map MSRPC
match-port tcp eq 135
policy-map type inspect dcerpc MSRPC-MAP
description dcerpc inspection for MAP and LOOKUP ops
parameters
endpoint-mapper epm-service-only lookup-operation
timeout pinhole 00:03:00 ! this timeout applies to pinholes from
lookup-operation
policy-map global-policy
class MSRPC
inspect dcerpc MSRPC-MAP
service-policy global-policy global
Debug is available for DCERPC inspection:
debug dcerpc [ packet | error | event ]
no debug dcerpc [ packet | error | event ]
Sample debug:
DCERPC-PKT: bind id:5 - dmz4:saturne/2055 to inside:octans/135.
DCERPC-EV: bind has non-epm uuid 000001a0-0000-0000-c000-000000000046.
DCERPC-EV: bind with ctx_num:2
DCERPC-EV: retrieve ctx_id: 0, if-uuid: 000001a0
DCERPC-EV: retrieve ctx_id: 1, if-uuid: 000001a0
DCERPC-PKT: bind_ack id:5 - inside:octans/135 to dmz4:saturne/2055.
DCERPC-EV: bind_ack with ctxnum_result:2
DCERPC-EV: ctxid/result:0/0 accepted, ack_reason:0 tsyn: 8a885d04
DCERPC-EV: ctxid/result:1/3 rejected, ack_reason:1 tsyn: 00000000
DCERPC-PKT: alter_context id:5 - dmz4:saturne/2055 to inside:octans/135.
DCERPC-EV: alter_context has non-epm uuid 000001a0-0000-0000-c000-000000000046.
DCERPC-EV: alter_context with ctx_num:1
DCERPC-EV: retrieve ctx_id: 0, if-uuid: 000001a0
DCERPC-PKT: alter_context_resp id:5 - inside:octans/135 to dmz4:saturne/2055.
DCERPC-EV: alter_context_resp with ctxnum_result:1
DCERPC-EV: ctxid/result:0/0 accepted, ack_reason:0 tsyn: 8a885d04
DCERPC-PKT: request id:5 - dmz4:saturne/2055 to inside:octans/135.
DCERPC-EV: valid_ctxid: alt:1 ctxnum:1 j:0 val:0 valid:1
DCERPC-PKT: response id:5 - inside:octans/135 to dmz4:saturne/2055.
Very important to collect packet captures if you want to troubleshoot ! This will help for the TAC to gather more information about what kind of DCERPC
communication is passing trough and may be replay on a lab device if it doesn't work or failing.
How to capture, see it here: Packet capture on Firewalls (ASA/PIX/FWSM)
DCOM: http://cybertiggyr.com/nmcom/draft-brown-dcom-v1-spec-03.html
ASA DOC: http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/inspect_mgmt.html#wp1488387
Is this fixed, or do we plan to workaround in perpetuity?
Hi theMethod,
As of 7/9/2014, the enhancement for the ASA code (tracked under bug ID CSCty26747) has yet to be implemented and therefore the workaround must remain in place.
The FWSM software went end of life on September 25, 2013 and therefore the workaround will need to remain implemented in perpetuity for the FWSM platform.
Regards,
Kevin
Hi Kevin,
I saw that the bug has been fixed for the mentioned bug (CSCty26747). Can you see the public release versions where this bug will be fixed?
I
https://tools.cisco.com/bugsearch/bug/CSCty26747/?referring_site=bugquickviewredir
think these are internal versions:
Known Fixed Releases: | (4) |
Hi Sander,
You're correct that those are internal builds. It looks like the bug has been committed to the ASA 9.4 train so I would keep an eye on the bug and once it has been included in a public release then you will see it populated in the bug search tool.
Regards,
Kevin Klous
CCIE #43604 - Security
Thanks Kevin!
Hi,
thank you for this amazing post
we are using dcerpc inspection with default configuration for longer than a year.
So far we got no issue between Client and Domain controllers.
Recently we introduced a private MS CA in our company.
Anyway our clients are not able to enrol a certificate from out MS PKI.
I tried to add tcp range 1024 65535 to the allowed ports toward our CA server but i didn't work.
What I expected was to see connections to the ephemeral ports but the new ace is keeping its hits count to zero. Actually even before adding the new acl entry I did not find any denied traffic on toward high tcp range. Is inspection in any way causing some issue between server and client? That is, does dcerpc inspection drops communication that it is not able to inspect correctly even if ephemeral ports are explicitly authorized?
Hello Marco,
What version of ASA software are you running? You should see issues between clients and domain controllers and Windows servers when using DCERPC inspection. We opened a SR at Cisco (SR 632578395) and Microsoft. According to Cisco TAC, issues may be solved in version 9.5.2.
Answer from Cisco TAC:
We saw some examples like this one and well basically the issue is that since the timeout of the DCERPC pinhole is absolute whenever is reached it will basically close it and it will have to be reopened so if this value is too low will cause performance issues and not a good experience for customers where it has to renegotiate the pinhole creation and start over compared to as what you have already tested if the timeout is high it will let the connection flow freely and with nice performance but the concern is if you get too many of this connections and the ASA will have to maintain them, that could potentially cause performance issues is they are too many, so a better approach for this issue is to actually instead of having an absolute timeout to have an idle one that could be reset every time traffic flows on that connection avoiding this one to expire and not to have all over again to create it.
For that one I have found an enhancement request CSCui79984 that could have the fix for this timeout issue, the link below will provide more details for this enhancement.
https://tools.cisco.com/bugsearch/bug/CSCui79984/?reffering_site=dumpcr
Thank you for the reply and excuse for delay of mine ....
To solve this issue I had to configure on asasms running 9.1(2) a service policy to exclude DCERPC traffic toward the CA Server from DCERPC inspection and explicity allow ephemeral ports. Anyway in the same policy I increased dcerpc pin holes time-out to avoid, so far unknown, issues with other decrcp traffic
On more recent versions (9.1.(6)) I just had to explicitally allow ephemarls ports without need to selectivly disable dcerpcinspection
Regards
MM
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: