01-25-2008 05:02 AM - edited 03-11-2019 04:53 AM
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
01-25-2008 05:19 AM
I forgot how I tested it:
Execute from a Windows XP command line the command:
tasklist /s
Greetings
Rufer
05-27-2008 12:08 PM
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.
05-28-2008 12:10 AM
I couldn't get it to work on the FWSM :-( We also have an ASA, but I didn't try it on this one.
10-06-2008 06:14 AM
My customer too has a problem on ASA 8.0(3). Suspect the code may be an issue - has anyone tried different versions ?
10-06-2008 09:47 AM
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.
10-07-2008 01:04 AM
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.
04-28-2009 09:19 AM
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)
04-29-2009 04:23 AM
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
05-04-2009 11:55 AM
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
04-29-2009 05:27 AM
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
04-29-2009 05:37 AM
Have you seen the URL :
http://www.cisco.com/en/US/docs/security/fwsm/fwsm32/command/reference/i2.html#wp1609242
fairly basic I know but I couldn't see the config :
hostname(config)# dcerpc-map DCERPC_MAP
etc ...
in your output.
Ian
05-04-2009 12:41 PM
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
05-05-2009 12:25 AM
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
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: