IoT Security
Firewall Deployment Options for IoT Security
Table of Contents
Expand All
|
Collapse All
IoT Security Docs
-
-
- Firewall Deployment Options for IoT Security
- Use a Tap Interface for DHCP Visibility
- Use a Virtual Wire Interface for DHCP Visibility
- Use SNMP Network Discovery to Learn about Devices from Switches
- Use Network Discovery Polling to Discover Devices
- Use ERSPAN to Send Mirrored Traffic through GRE Tunnels
- Use DHCP Server Logs to Increase Device Visibility
- Control Allowed Traffic for Onboarding Devices
- Support Isolated Network Segments
-
Firewall Deployment Options for IoT Security
Consider if the firewall sees unicast DHCP traffic and whether to use a Tap interface or
Virtual Wire interface.
Where Can I Use This? | What Do I Need? |
---|---|
|
|
When assessing deployment options for IoT device visibility, there are two fundamental
considerations:
- The firewall must see traffic for the IoT application to use network traffic data for classification and analysis and for the enforcement of policy rules on the firewall itself. This includes regular operational traffic in addition to DHCP traffic.
- With the exceptions outlined below, the firewall must see unicast DHCP traffic to generate the data that allows IoT Security to create the required IP address-to-device mappings.
Exceptions to the Unicast Rule
- Virtual Wire: When the firewall has Virtual Wire interfaces with multicast firewalling enabled, it generates Enhanced Application logs (EALs) for broadcast DHCP sessions.
- A DHCP server is configured on the firewall: No workaround is required for the firewall to generate EALs when a DHCP server on one of its interfaces receives broadcast DHCP traffic. Just enable DHCP Broadcast Session at DeviceSetupSession.When the firewall receives DHCP broadcast traffic and applies a policy rule with an Enhanced Application log forwarding profile, it logs the DHCP traffic and forwards it to the logging service. From there, IoT Security accesses the data for analysis.
- A DHCP relay agent is configured on the firewall:
- The firewall generates EALs for broadcast DHCP traffic when a DHCP relay agent is configured on one of its interfaces.
Tap Interfaces
Considerations – If you use a Tap interface to gain visibility into DHCP traffic that the
firewall doesn’t ordinarily see, consider the following:
- Place the tap “north” of any routed boundary where DHCP is configured. This will ensure that the captured traffic is unicast rather than broadcast. (If the firewall with the Tap interface is in the same broadcast domain as the switch that’s mirroring traffic to it, enable DHCP Broadcast Session at DeviceSetupSession.)
- If adding a tap interface to an existing firewall, consider the available capacity on the firewall before implementing. While tap interfaces don’t forward traffic, traffic seen on the tap port still consumes resources for processes such as the session table and packet buffers. For guidance on mitigating performance impact, see Use a Tap Interface for DHCP Visibility.
Use Cases for Tap interfaces
- Evaluations
- Networks where DHCP is configured on a device “south” of the firewall
- Monitor networks that don’t naturally traverse the firewall
Virtual Wire Interfaces
Considerations – You might have to use a Virtual Wire (vWire) interface on the firewall
to gain visibility into DHCP traffic that the firewall wouldn’t normally see. Consider
the following when using a tap interface in this manner:
- Ensure the Virtual Wire has multicast firewalling enabled.
- Ensure the Virtual Wire is in the path for DHCP traffic. This traffic can be either broadcast or unicast.
- Ensure that a security policy rule allowing DHCP exists and that a proper log-forwarding profile is applied to the rule.
- Ensure the firewall has the available capacity to process the additional traffic. For guidance on mitigating performance impact, see Use a Virtual Wire Interface for DHCP Visibility.
Use Case for Virtual Wire interfaces – When the DHCP server and the firewall interface
are on the same network segment, the firewall sees only broadcast DHCP traffic. Placing
the DHCP server behind a Virtual Wire interface enables the firewall to create EALs for
this broadcast traffic.
Layer 2 and Layer 3 Interfaces
Considerations – Layer 2 (L2) and Layer 3 (L3) deployments both require unicast DHCP
traffic to generate EALs. When using a VLAN interface in an L2 deployment, the
considerations are the same as a deployment using Layer 3 interfaces:
- Unicast DHCP packets traversing the firewall generate an EAL.
- When an L3 or VLAN interface is configured as a DHCP relay agent, the firewall generates an EAL.
- When an L3 or VLAN interface is configured as a DHCP server the firewall might generate an EAL. For more information, see DHCP Data Collection by Traffic Type in Firewall Deployment for Device Visibility.