Understanding how MSMQ security blocks RPC traffic
MSMQ makes use of several protocols to do its work, including:
- MSMQ - confusingly the protocol name is the same as the product name (although Microsoft Message Queuing is the preferred alternative. Not as snappy, mind). This protocol is for sending messages to remote destinations.
- RPC - used for pulling data from another queue manager. This information could be whole messages or just properties about messages, queues, services and so on.
- LDAP - required for querying Active Directory about the properties of the various MSMQ objects stored there
This blog post will focus on the main obstacles to using remote operations and RPC.
Over the years, Windows security has been beefed up and this means a lot of unsecured ways to interact with MSMQ have been disabled by default. The three that come to mind are:
- Secured remote read interface enabled
By default, an encrypted channel is required which is not possible with machines in a different forest, running in workgroup or using local (not domain) accounts. This is covered in my MSMQ 3.0 too secure for you? blog post.
- Windows Firewall blocks RPC port 135
To reduce the number of ports exposed to attack, port 135 is blocked by default. Without this port, clients cannot determine what port the server's MSMQ service is listening on. This is covered in my Getting MSMQ messages out of Windows Server 2008 remotely blog post.
- Un-authenticated RPC calls disabled
ReferencesThis is part of the changes made with Windows 2003 sp1. Remote anonymous access to RPC interfaces on the system was disabled and now the authentication of callers is required which reduces the risk of being attacked by means of buffer overruns invoked anonymously and remotely.The user interface for changing this just for MSMQ is covered in my MSMQ 4.0 - what's new in Computer Management? blog post.