DCE RPC Inspection not Working on FWSM

Unanswered Question
Dec 15th, 2009
User Badges:

Hi there,

We have enabled inspection of RPC on TCP Port 135, to inspect the MS RPC response and dynamically open the ports.



We have created a DCERPC Map with te following settings:


Pinhole Timeout : 00:15:00

Endpoint-mapper service:enforced

Endpoint-mapper service lookup: enabled

Endpoint-mapper service lookup timeout: 00:10:10


We can succesfully connect throught the firewall on 135 , but it blocks any dynamic high ports which follow..


Any thought on this?


Cheers


Dion

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Panos Kampanakis Wed, 12/16/2009 - 10:40
User Badges:
  • Cisco Employee,

Dion,


Please check what "debug dcerpc" show.

There was 1-2 defects on DCERPC in early 3.2 versions, what FWSM version are you running?


PK

GrumpyBear Wed, 01/27/2010 - 13:22
User Badges:

I'm running 3.2(6) and having the same problem.


I've just added "inspect dcerpc" to the default inspection class map.


sh service-policy lists:


"Inspect: dcerpc, packet 17017069, drop 11825, reset-drop 0"


I really don't want to have to open all the ephermal ports to the server.


Anyone have a fix or workaround (I've tried using an established command but no luck there)?

Kureli Sankar Wed, 01/27/2010 - 18:01
User Badges:
  • Cisco Employee,

CSCsx26083 resolved in 4.1 ENH: FWSM DCERPC inspection doesn't support 'Remote Create Instance' msg


CSCsk34368

Inspect DCERPC failure. Packet too small error - resolved in 3.2.3



4.0.1 release notes:

DCERPC inspection enhancements

Numerous enhancements were added.

You can now use an inspection policy map to configure special actions for inspection traffic; this method replaces the application map.


I am not sure what the reason is to see the drop in the sh service-policy.


If you are open to upgrade I'd suggest an upgrade to 4.0.8 and test otherwise,


we need to collect debug dcerpc packet

http://www.cisco.com/en/US/docs/security/fwsm/fwsm32/command/reference/d1.html#wp1722034


If you could open a TAC case that would be better for this issue.


-KS

GrumpyBear Thu, 01/28/2010 - 06:25
User Badges:

kusankar wrote:


CSCsx26083 resolved in 4.1 ENH: FWSM DCERPC inspection doesn't support 'Remote Create Instance' msg


CSCsk34368

#

Inspect DCERPC failure. Packet too small error - resolved in 3.2.3



4.0.1 release notes:

DCERPC inspection enhancements

#

Numerous enhancements were added.

#

You can now use an inspection policy map to configure special actions for inspection traffic; this method replaces the application map.


I am not sure what the reason is to see the drop in the sh service-policy.


If you are open to upgrade I'd suggest an upgrade to 4.0.8 and test otherwise,


we need to collect debug dcerpc packet

http://www.cisco.com/en/US/docs/security/fwsm/fwsm32/command/reference/d1.html#wp1722034


If you could open a TAC case that would be better for this issue.


-KS

Thanks,


I'm in dependancy hell right now as we're also starting to implement CSM so I have to ensure the code on my firewalls meet the supported versions in CSM.


Right now I'm just having problems with a Archiving service but we're staring to move Exchange 2007 mailbox and CAS servers behind this firewall so I really need to get this working as I'm not keen to open all the ephermal ports.


I'm a little leery of turning debug on on this firewall during working hours as it is in our data centre.  I'll run the "debug dcerpc events" and use "logging buffered" and "logging ftp-bufferwrap" so I can capture the output and see any error messages pertinant to the service we are having problems with then open a TAC case.


Regards, The Grumpy FW administrator

Kureli Sankar Thu, 01/28/2010 - 06:28
User Badges:
  • Cisco Employee,

Yes. That is a better idea.

Remember they would need


debug dcerpc events

debug dcerepc error

debug dcerpc packets


-KS

GrumpyBear Thu, 02/25/2010 - 10:41
User Badges:

Sigh,


I miss my direct TAC access.


Finally after three weeks of dealing with a PICA I was asked for a sh tech so I know they have finally escalated it to the TAC.


Latest suggestion is to try 4.1(1) but it seems to be reloading the FWSM every 15 minutes


Good thing my very nice Support Engineer at the local Cisco Office lent me a FWSM so I'm not irritating my clients using services in the Data Centre. - Thanks Louis!


I think we're getting closer ....


Sometimes you'd just like to meet these application developers and ask they just why, with 64534 ports available, they felt the need to use RPC.


The even Grumpier Firewall Administrator

Kureli Sankar Thu, 02/25/2010 - 10:54
User Badges:
  • Cisco Employee,


I just got done decoding the crash.  Seems like a new one to me.


-KS

GrumpyBear Thu, 02/25/2010 - 12:35
User Badges:

Hmm,


Perhaps I should sign a NDA and join the Beta Testing crew


Thanks for your help

Kureli Sankar Thu, 02/25/2010 - 12:48
User Badges:
  • Cisco Employee,

Did 4.1.1 resolve the inspection issues and opens pin holes as expected?


-KS

GrumpyBear Thu, 02/25/2010 - 12:56
User Badges:

We didn't have time to test that as the System Admin had to leave for a meeting.


I sent the syslog output (with the debug o/p from dcerpc) to the Partner and that looked promising with respect to other services (AD, Exchange & SQL) as I was seeing more pinholes for those than in the past but I'm getting weird IPv6 messages even though the Sys Admin assures me that the IPv6 Stack is disabled.


"DCERPC-ERR: Unrecognized address/port format. Supports only IPv4 address. Skipped pinhole creation and translation for this address"


Rumour has it that to completely kill IPv6 on Server 2003 you have to apply registry hacks.


God Bless Microsoft - they keep me employed.


There is also some RFC3550 addresses floating around so I'll have to have a look at the system further.

GrumpyBear Tue, 03/09/2010 - 11:11
User Badges:

Yes,


I am happy to report that the bugfix 4.1(0) 18 code we received did open the Pinholes as expected for the Symantec eVault Archving service.


So the test was a sucess but we decided to stick with the 3.2 code for now and take other steps to mitigate the risk until the 4.1 is a little more mature and is supported by CSM.


Thanks to the TAC for all their help.

Kureli Sankar Tue, 03/09/2010 - 11:19
User Badges:
  • Cisco Employee,

Glad to hear. Arturo relayed it to me yesterday.


Hope you are not "grumpy" any more


-KS

GrumpyBear Tue, 03/09/2010 - 11:25
User Badges:

Well ...


I'm opening another TAC case.  Our Primary FWSM in the DataCentre spontaneously reloaded last week!


I know what triggered it (probably) - rolling out a new Nessus server on a dual quad-core processor with a GigE connection then pointing it at an Exchange server turned out to be bad for the Exchange Server and worse for the firewall.


Thank goodness the failover worked!

GrumpyBear Tue, 05/01/2012 - 07:04
User Badges:

So we finally bit the bullet and upgraded to 4.1(7).  The DCERPC inspection appeared to work for that traffic which we noted previously was broken.  Only problem is that WMI queries which used to work are now broken.


Opened a case with our PICA back in December and still haven't heard back from them.  So we have DCERPC disabled and a buch of ephermal ports enabled.  Sigh.


Hopefully the support folks will eventually escalate this to the TAC so we can get some resolution.


Still Grumpy ...

Actions

This Discussion

Related Content