12-15-2009 04:20 PM - edited 03-11-2019 09:49 AM
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
12-16-2009 10:40 AM
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
01-27-2010 01:22 PM
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)?
01-27-2010 06:01 PM
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
01-28-2010 06:25 AM
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
01-28-2010 06:28 AM
Yes. That is a better idea.
Remember they would need
debug dcerpc events
debug dcerepc error
debug dcerpc packets
-KS
02-25-2010 10:41 AM
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
02-25-2010 10:54 AM
I just got done decoding the crash. Seems like a new one to me.
-KS
02-25-2010 12:35 PM
Hmm,
Perhaps I should sign a NDA and join the Beta Testing crew
Thanks for your help
02-25-2010 12:48 PM
Did 4.1.1 resolve the inspection issues and opens pin holes as expected?
-KS
02-25-2010 12:56 PM
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.
03-09-2010 11:11 AM
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.
03-09-2010 11:19 AM
Glad to hear. Arturo relayed it to me yesterday.
Hope you are not "grumpy" any more
-KS
03-09-2010 11:25 AM
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!
05-01-2012 07:04 AM
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 ...
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide