Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

DCERPC inspection on ASA/PIX/FWSM

 

DCE/RPC inspection on ASA/PIX/FWSM

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

 

Microsoft is no longer just using EPM (End Point Mapper)

 

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:

  • return protocol sequences, string bindings and machine id for an object server, given its OXID (ResolveOXID() and ResolveOXID2() (only supported by DCOM version 5.2 and above))
  • respond to ping requests (SimplePing() and ComplexPing() functions)
  • respond to ServerAlive() and ServerAlive2() functions requests

 

NON-EMP support for ASA/FWSM

  • only the RCI (Remote Create Instance) non-EPM message supported
  • only 1 WMI message is supported              
    • RemoteCreateInstance (Opnum 4)
  • Any other message type from IRemoteSCMActivator (eg. RemoteGetClassObject) will not be passed            
    • IOXIDResolver (Opnum 5) that is remotely used to reach the local object resolver and is part of the OXID resolver interface. This Opnum is not supported by us.  Essentially, this is a RPC call from WMI (WMI uses DCOM to handle remote calls) to a non-epm subsystem that is DCOM based. Packets with opnum 5 don't need inspection support unless there is NAT involved, as there is no need for opening pinholes.
  • Opnum 3 & 4, EPM.
  • Opnum=4 RCI
  • Opnum=5, this does not  contain port numbers and FWSM does not inspect this. If there is a NAT  involved, FWSM does not inspect.

Caveats

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

 

Workarounds available

  1. Enable DCERPC inspection, open all higher ports for the servers
  2. Disable DCERPC inspection, permit all traffic

 

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.

 

Config

 

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

 

Troubleshooting

 

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)

 

References

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

MSRPC: http://en.wikipedia.org/wiki/Microsoft_RPC

Version history
Revision #:
2 of 2
Last update:
‎08-28-2017 12:32 AM
Updated by:
 
Labels (1)
Contributors
Everyone's tags (4)
Comments
New Member

Is this fixed, or do we plan to workaround in perpetuity?

Cisco Employee

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

 

New Member

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)
100.13(1.14)
100.13(11.10)
100.13(11.23)
99.1(5.1)
Cisco Employee

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

New Member

Thanks Kevin!

New Member

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? 

 

New Member

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

New Member

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