FWSM 3.2 DCERPC inspection

Unanswered Question

Hello all


I read in the release notes, that FWSM 3.2 supports MS DCERPC inspection.

How does it work?

client connects to server:135/tcp

A dynamic tcp port >1024 on the server is mapped

client connects to server:>1024/tcp


As far as I understood, DCERPC inspection should dynamically permit the 2nd part, thus the dynamic connections.

All beautiful... but it doesn't work. And - sorry to say - the documentation on this subject is really null.


I enabled it for a DMZ so that a client in this DMZ could still do RPC connections without opening a lot of static TCP ports.

Problem is the dynamic connections (tcp port >1024 on server) are denied by the final deny any any ACL.

It works when I open all TCP ports.


Configuration:


- added ACL such that client can communicate to tcp port 135 (and some other Windows ports needed).


- class map for DMZ inteface:

gatea/unine#sh run | begin class-map

class-map dmz4-class

match default-inspection-traffic

!

policy-map dmz4-policy

class dmz4-class

inspect dns maximum-length 512

inspect ftp

inspect http

inspect icmp

inspect netbios

inspect sunrpc

inspect tftp

inspect xdmcp

inspect dcerpc

!

service-policy dmz4-policy interface dmz4


(note I also tried to match the DCERPC traffic manually (match tcp port 135 using own class) as described in an ASA example, but it didn't work either).


Here's the "debug dcerpc event" output:

fwsm/context# DCERPC-EV: bind has non-epm uuid 99fcfec4-5260-101b-bbcb-00aa0021347a.

DCERPC-EV: bind with ctx_num:1

DCERPC-EV: retrieve ctx_id: 0, if-uuid: 99fcfec4

DCERPC-EV: bind_ack with ctxnum_result:1

DCERPC-EV: ctxid/result:0/0 accepted, ack_reason:0 tsyn: 8a885d04

DCERPC-EV: valid_ctxid: alt:0 ctxnum:1 j:0 val:0 valid:1

DCERPC-EV: valid_ctxid: alt:0 ctxnum:1 j:0 val:0 valid:1

DCERPC-EV: valid_ctxid: alt:0 ctxnum:1 j:0 val:0 valid:1

DCERPC-EV: bind has non-epm uuid 000001a0-0000-0000-c000-000000000046.

DCERPC-EV: bind with ctx_num:1

DCERPC-EV: retrieve ctx_id: 1, if-uuid: 000001a0

DCERPC-EV: bind_ack with ctxnum_result:1

DCERPC-EV: ctxid/result:1/0 accepted, ack_reason:0 tsyn: 8a885d04

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: 1, if-uuid: 000001a0

DCERPC-EV: alter_context_resp with ctxnum_result:1

DCERPC-EV: ctxid/result:1/0 accepted, ack_reason:0 tsyn: 8a885d04

DCERPC-EV: valid_ctxid: alt:1 ctxnum:1 j:0 val:1 valid:1


Anyone has a working example for this?


Greetings

Rufer

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (2 ratings)
Loading.
jedavis Tue, 05/27/2008 - 12:08
User Badges:

Mathias, did you ever figure this out? I just upgraded a 5510 from 7.1 to 8.0 so that I could get the dcerpc support, but I haven't tried to get it to work yet.

iswift Mon, 10/06/2008 - 06:14
User Badges:

My customer too has a problem on ASA 8.0(3). Suspect the code may be an issue - has anyone tried different versions ?

jedavis Mon, 10/06/2008 - 09:47
User Badges:

What problems? I am running 8.0(3) on a number of 5510s and don't seem to have issues. At least, no one is complaining.

iswift Tue, 10/07/2008 - 01:04
User Badges:

We have one server/app that uses the 'DCOM' protocol that simply times out when trying to initialise to the server. Basic comms exist to the server as we can communicate on other ports. Packet Tracer for tcp/135 passes OK and captures on the firewall interfaces show packets entering & leaving, and the return packets the same, but the app stubbornly refuses to talk. I suspect some kind of inspection or DoS protection, as when the f-w interface was replaced with a 2610 router (with the same NAT cofigured) with a client on the other side, the app. worked OK.

obrenes Tue, 04/28/2009 - 09:19
User Badges:

Hi Mathias:


Any news about this issue? I'm having the same problem described in this post.


Rgds,


Omar


FWSM Firewall Version 3.2(4)

Hello


Yes. We have upgraded to FWSM version 4.0.4 and opened a TAC case for the still not working DCERPC inspection.

The outcome was that the protocol is supported, but _not entirely_!!


In particular the RPC communications used by Exchange 2007 are not supported. And on a side-note, a very simple example, the "tasklist" application of Windows, is not supported either.

I couldn't find a useful application that is fully supported.


Cisco thinks this is not a bug, but an extension request and told us this will probably not be implemented soon. We are ABSOLUTELY NOT HAPPY with this.


Greetings

Mathias Rufer

obrenes Mon, 05/04/2009 - 11:55
User Badges:

Thanks for the reply Mathias.


I'm very disappointed to hear that. It would be nice for Cisco to include in their “plain” documentation that the protocol is not fully supported, and a list of scenarios where the feature works as expected.


Besides that, I found that the feature works well against a Domain Controller (Win2003 server) for biometrical access (Biologon, at least). That's all…


I believe the “inspect dceRPC” feature doesn't work on the following applications/scenarios:


1. Certificate Autoenrollment.

2. ILM/CLM 2007 (Microsoft's Identity Lifecycle Manager, CLM module)


We have had problems on those two scenarios when we enable the feature and close all the ports above 1024.


Rgds,

Omar

iswift Wed, 04/29/2009 - 05:27
User Badges:

Omar,


We had a workaround.


Under the class map you remove


'inspect dcerpc'


This the relies on the 'usual' firewall rlebase to allow estabilished connections as usual.


There did seem to be some documentation about configuring 'pinholes' in the config for dynamic port use.


We did not try this as the client was heavily behind their schedule and would tolerate no further delay while this was investigated.


Ian

obrenes Mon, 05/04/2009 - 12:41
User Badges:

Thank you Ian!


A got the exactly same configuration as Mathias, and got the same debug results. I also used the same link that you provided in this post to configure the feature, but as Mathias replies, the feature seems to work in a few scenarios only...


It worked for the RPC communications against our Domain Controllers. We tried to implement it in our CA without any luck.


Every time that the feature fails to open the ramdomly negociated ports, I get the following log message:


“DCERPC-EV: bind has non-epm uuid...”


You said that, as a workaround, we have to remove the “inpsect dcerpc" command?!?! Then you wrote about some documentation available... Please confirm.


Rgds,

Omar


My Output:


class-map inspection_default

match default-inspection-traffic

!

policy-map global_policy

class inspection_default

inspect dns maximum-length 512

inspect ftp

inspect smtp

inspect netbios

inspect tftp

inspect icmp

inspect dcerpc

!

service-policy global_policy global


Fw# sh service-policy

Global policy:

Service-policy: global_policy

Class-map: inspection_default

Inspect: dcerpc, packet 2612925, drop 236, reset-drop 0

iswift Tue, 05/05/2009 - 00:25
User Badges:

Hello Omar,


Yes - by way of confirmation it is as you have described.


We had to remove the dcerpc inspection from the clas map


config)# class inspection_default

config)# no inspect dcerpc


The documentation link was for the command reference on the FWSM.


Rgds

Ian

Actions

This Discussion