Implementing IP Address Filtering for Azure Event Hubs and Service Bus

Introduction

The Azure Messaging team recently announced support for IP Address filtering for both Azure Event Hubs (Standard and Dedicated plans) and Azure Service Bus Premium plan. Within this article, we will further explore this feature and discuss why this is an important capability.

Why is this feature important?

Azure Event Hubs and Service Bus entities are naturally accessible over the internet. They are protected through Shared access policies that include 3 different claims, including manage, send and listen. If you have a business partnership with a third party who is responsible for publishing messages to a Service Bus/Event Hub entity, you would likely create a shared access policy for them and include the send claim. If they also received messages from the same namespace, you would include a listen claim which provides them with the ability to retrieve messages from a Service Bus/Event Hub entity.

“What happens if this partner does not properly protect their shared access policy which contains a Primary Key and a Secondary Key”?

Consider a scenario where a disgruntled employee at the partner organization obtains the Primary or Secondary Key and starts to send poison or malformed messages to the Service Bus/Event Hub entity from a location outside of your partner’s network? Not only does this reflect poorly on the partner, but it likely creates operational issues for your business as well.

By filtering IP Addresses, you are reducing the attack surface of your Service Bus/Event Hub entities. In the situation where this rogue employee tries sending messages off the partner’s network, those messages can be discarded and an unauthorized response returned to the publisher. But without the IP Address filter, this rogue employee could send malignant messages from any public network.

Implementation of IP Address filtering

Let’s now take a look at what is involved in configuring IP Address filtering for Azure Event Hubs and test the behavior of this capability. There are two parts to this implementation. First, we need to create an Event Hubs Namespace. Subsequently, we need to create an actual Event Hub. Do note that when we create an IP filter rule, it gets applied to the Event Hubs Namespace.

Create Event Hubs Namespace

1. Navigate to the Azure Portal.
2. Click on Create a resource.
3. Type in Event Hubs into the Search the Marketplace textbox.
4. Select Event Hubs.
5. Click on Create
6. We now need to create our Event Hub by populating the following options:
   

   Feature Name	Feature Value	Description
   Name	Name of Event Hub	Must be a unique value
   Pricing tier	Standard	Do note that the Standard tier does cost approximately $22 USD for a million events per month. Also, Note that IP filtering is only available in Standard or Dedicated pricing tiers.
   Subscription	Choose an appropriate Azure subscription
   Resource Groups	Create a new Resource group or select an existing Resource group.
   Location	Choose appropriate Azure Region
   Throughput Units	1	1 Throughput Unit is enough for the purposes of this blog post.

   

7. Within a couple minutes, we will discover our Event Hub has been created.
8. Within our Event Hubs Namespace configuration experience, we will discover a Setting called Virtual networks and IP filters.
9. We can choose to have our Event Hub only accessible to a Virtual Network. For example, you may have a series of Virtual Machines that belong to a specific Virtual Network. By enabling this feature, you can avoid worrying about whether or not a Virtual Machine’s IP address has changed or a different range is being used. But, for this blog post example, we are going to focus on just IP Address filtering. As we want to emulate a trading partner scenario where someone on an external network needs to publish messages to an Event Hub but we want to restrict from what IP Addresses they can do this.Before we configure this setting, there are a few important things to be aware of that the Azure documentation calls out:
   • Only IPV4 Ip Addresses are supported
   • A single IP Address can be provided, but IP Address ranges must be in CIDR. For example, in CIDR notation 70.37.104.0/24 represents the 256 IPv4 addresses from 70.37.104.0 to 70.37.104.255. With 24 indicating the number of significant prefix bits for the range.
   • ipFilterRuleName must be a unique, case-insensitive, alphanumeric string, up to 128 characters long.
   • ipFilterAction is either Reject or Accept as the action to apply for the IP filter rule.

   With this pre-requisite information out of the way, let’s go configure a rule!

10. Click on the + Add IP Filter Rule link
11. We now need to provide an IP Filter Name, IP Range and Action. Once these values have been provided, click on the Add button
    

    Name	Value
    IP Filter Name	Trading-Partner-Network
    IP Range	Your IP Range i.e. 70.37.104.0/24
    Action	Accept

    

Create Event Hub

1. From within the Event Hubs Namespace configuration experience, click on the + Event Hub link.
2. Provide a Name for your Event Hub. For the purposes of this blog post, I have provided a Name of Orders. We can accept the defaults for Partition Count, Message Retention, and Capture. Click Create to proceed.
3. Within a few seconds, we will see that our Event Hub has been provisioned.
4. We don’t want to provide our publisher with “Root” access so we will create a new Shared access policy that has permission to Send, but nothing more. To do this, click on Settings – Shared access policies.
5. Next, click on the + Add link
6. Provide a Policy name, click Send permissions and then click on the Create button.

We now have a configured Event Hubs Namespace with an IP filter rule created. In addition, we added an Event Hub to this namespace and created a Shared Access Policy so our publisher can connect to our Event Hub.

Testing

Let’s start off with a positive test, meaning we will make a connection to our Event Hub using the IP address that we configured as part of our Accept rule. In order to test this functionality, we need to be able to send a message to this Event Hub endpoint. To accomplish this, we will use the code sample provided on the Azure documentation page.

Once you have downloaded the sample from GitHub, you need to make a couple of modifications to the sample code in order to connect to your Event Hub. More specifically, modify lines 14 and 15 to reflect your Event Hub connection information.

Note: You can obtain your connection string by clicking on Shared access policy that you created in a previous step.

When we run this sample, we will send 100 messages (default) to our Event Hub. Since our IP Address has been added to the Accept list, we should see these messages successfully sent.

Let’s now focus on a negative test. In this test, we are going to change our IP filter from an Accept rule to a Reject action. To make this change we need to perform the following steps:

1. Access our Event Hubs Namespace and click on the Virtual networks and IP filters setting.
2. Click on the rule that we previously set up (Trading-Partner-Network).
3. Modify the Action. Change it from Accept to Reject and click the Update button.
4. Once the rule has been updated, let’s run our sample code once again. (You may also want to ensure that your IP Address has not changed either).
5. When we run our sample code, we will discover that we are now receiving errors. The error message returned is IP has been prevented to connect to the endpoint which is the actual error that we would expect to receive after modifying our IP filter rule.