We’re excited to announce that tunnel inspection is now generally available in all commercial regions, with government regions to follow soon. This new feature addresses customer demands for a new use case aimed at utilizing threat detection and analysis capabilities by integrating tunnel inspection with Oracle Cloud Infrastructure’s (OCI) native virtual test access port (VTAP) service. This combination allows for comprehensive traffic analysis through a dedicated out-of-band channel. It enables the detection of malicious sources or destinations, identification of inappropriate crypto traffic, and spotting of SSH sessions targeting known command and control (C2) domains. Additionally, it supports alert activation for various security issues, such as identifying attacks using known exploits and monitoring traffic directed towards inappropriate or malicious destinations and command and control systems.
Enterprises are deploying a greater number of workloads within OCI, each with progressively intricate business demands. Consequently, this transition has resulted in heightened scale, complexity, and security concerns within their cloud networks. The OCI Network Firewall caters to diverse business requirements providing a plethora of network security policy controls using multiple methods including stateful access control, URL-filtering, SSL inspection, and intrusion prevention detection using advanced threat protections. For more detailed information, you can refer to Defense in Depth, Layering using OCI Network Firewall on the Oracle Blogs site.
This blog post provides an overview, delves into practical applications, and explains in detail the use of tunnel inspection for threat detection and analysis.
Overview
In-line traffic flows involve data packets that travel directly through the main data path or network path. These packets follow the same route and are subject to the same processing and forwarding rules as other regular traffic. In-line traffic flows are typically used for most common network communication, such as web browsing, email, and file transfer. Examples of in-line devices include routers, switches, and firewalls that process and forward traffic along the primary network path.
Out-of-band traffic flows involve data packets that are managed and processed separately from the main data path. These packets are typically used for specific purposes such as management, monitoring, or control of the network infrastructure. You can use out-of-band traffic for tasks like network diagnostics, monitoring for security threats, or management of network devices. Out-of-band communication often utilizes dedicated channels or interfaces separate from the primary data path to avoid interfering with regular network traffic. Examples of out-of-band devices include network management systems, intrusion detection systems (IDS), and dedicated traffic monitoring appliances, such as Wireshark. However, in this mode, while the firewall can support intrusion detection, you can’t implement prevention measures because the firewall isn’t positioned within the actual traffic path. Figure 1 highlights the two different traffic flows.
Customers use an out-of-band deployment for traffic inspection for the following use practical applications:
-
Scalability and performance: Out-of-band deployment can be more scalable because it doesn’t directly impact the throughput of network traffic. Thousands of intrusion signatures being checked against each packet as part of the IDS system has an impact on the throughput and latency of applications. When deployed on mirrored traffic customers can still inspect traffic and detect threats without adding any latency or throughput overheard to the original traffic.
-
Easy integration: Customers might find it simpler to incorporate an out-of-band firewall into their current network infrastructure with minimal disruption and without requiring substantial alterations to the network topology or configurations. This method is especially useful for customers to trial or proof of concept in production environments requiring minimal changes for network topology.
-
Testing and monitoring: Out-of-band deployment allows organizations to test and monitor firewall rules and policies without affecting live traffic. This setup is particularly useful for troubleshooting, testing intrusion signatures and fine-tuning false positives for production traffic without impacting application behavior or performance. Deploying the firewall out-of-band initially allows for rigorous testing and fine-tuning of security policies before transitioning to an in-line deployment, ensuring minimal disruption to network traffic and maximizing security effectiveness.
-
Security analysis: By analyzing mirrored traffic, organizations can gain deeper insights into network activity and security threats without relying solely on live traffic data. This offline visibility can help identify trends, anomalies, and potential security breaches by replaying specific traffic patterns into your AI threat models.
-
Dual vendor security strategy: This approach involves security solutions from different vendors, creating a diverse and more robust defense against cyber threats.
Example scenario
Now that we’ve covered the basics, let’s discuss a sample use case. The following example scenario illustrates a common use case: Utilizing tunnel inspection combined with VTAP for out-of-band intrusion detection (IDS) and performing deep packet analysis offline using Wireshark (see figure 2). Mirrored traffic originating from the OCI native VTAP service is encapsulated in VXLAN per RFC 7348 and forwarded to the VTAP target (an OCI Network Load Balancer). Tunnel inspection enables the OCI Network Firewall to inspect mirrored traffic originating from the OCI VTAP service, up to one level tunnel depth, and for VXLAN type traffic only. If the OCI Network Firewall is in the path of a virtual extensible LAN (VXLAN) tunnel, the OCI Network Firewall can inspect the tunnel content. We encourage you to learn more about configuring VTAP in the available VTAP documentation.
In the following example topology, VTAP has been enabled on the web load balancer (with the frontend going to the web servers inside the application subnet) to capture all traffic to and from the internet. The OCI Network Firewall is configured with a firewall policy that includes a tunnel inspection policy and security rules. The tunnel inspection policy includes a match condition for any source or destination IP address with an action to inspect and log. The security rule matches on VXLAN and HTTP traffic. All other traffic is dropped by the default deny any security rule.
Traffic flows through the following steps:
- The client sends malicious HTTP traffic to a web server with embedded malware.
-
Malicious traffic flows are mirrored by VTAP from the VTAP source (in this case, the load balancer).
-
Routing on the web load balancer subnet is configured to steer VTAP source traffic destined to the VTAP target network load balancer to the OCI Network Firewall for intrusion detection.
-
As packets traverse through the OCI Network Firewall and evaluated against the firewall policy, all VXLAN tunnel traffic that includes HTTP in the inner packet is inspected.
-
All traffic flows and any detected threats are logged on the OCI Network Firewall through the OCI Logging service, enabling administrators to track and respond to potential security breaches effectively.
-
Traffic arrives at the VTAP target, the network load balancer, and forwarded to the backend, which in this example is a Wireshark packet analyzer.
-
You can use Wireshark for deep packet analysis for any threats detected and logged by the OCI Network Firewall, allowing for comprehensive scrutiny of network traffic.
Getting started with tunnel inspection
We encourage you to learn more about configuring the OCI Network Firewall and tunnel inspection in the available OCI Network Firewall documentation. This section introduces the new OCI Network Firewall resources for the tunnel inspection feature.
Tunnel inspection policy rule
Tunnel inspection rules configure the OCI Network Firewall to inspect the traffic content of VXLAN cleartext tunnel traffic (see figure 2). They’re evaluated after security rules. Include VXLAN and any extra protocols, ports, IP addresses or URLs. Customers can create a maximum of 500 tunnel inspection rules for each policy. For the most up to date limits, refer to the OCI Network Firewall documentation.
This new resource component contains the following configuration elements:
-
Name: Flexible name for tunnel inspection rule.
-
Match condition: Where the source and destination IPv4 or IPv6 addresses of the original packet that must match for this rule are defined.
-
Rule action: Where either inspect or inspect and log is chosen.
-
Rule order: Where you can deterministically order the rule as being first, last, or inserted in a custom position.
Tunnel inspection logs
With this product, to facilitate customer debugging, we’re also excited to introduce a new log category type for tunnel inspection traffic logs, which you can enable for the OCI Network Firewall under Logs (see figure 5). Each start and end of a VXLAN session is tracked within the tunnel inspection log. Tunnel inspection logs serve as the equivalent of traffic logs, but for tunnel sessions, they display nonencrypted tunnel activities. To avoid redundancy, the firewall exclusively records inner flows in traffic logs, while directing tunnel sessions to the tunnel inspection logs. Like traffic logs, entries in the tunnel inspection logs encompass crucial details (see figure 6), such as the receive time (indicating the date and time of log reception), tunnel ID, monitor tag, session ID, the security rule governing the tunnel session, session byte count, parent session ID (pertaining to the tunnel session), source address, and destination address. You can correlate traffic logs and tunnel logs using the parent session ID and tunnel ID from each log type.
A structured JSON format powers everything for data interchange, which allows easy integration with both existing log management platforms and other OCI services. Data export and streaming capabilities are supported for integrating your OCI Network Firewall tunnel inspection logs. By utilizing Logging connectors, you have the flexibility to either store logs in object storage for compliance and data retention purposes or stream them to your SIEM or log management platform in less than 10 minutes. Furthermore, we offer alerting functionality on event data to address your alerting requirements, complementing the built-in log search capabilities of the Console.
Programmability
Finally, we’re excited to announce the expansion of our RESTful API with this latest tunnel inspection feature, empowering customers to programmatically deploy this critical functionality. With this enhancement, users gain seamless control and integration capabilities, allowing for streamlined deployment and management of tunnel inspection across their networks.
Our commitment to enhancing user programmability experience extends even further with the use of Terraform as the provider. Customers can use Terraform capabilities to effortlessly integrate the new APIs into their infrastructure automation workflows. This expansion marks a significant stride towards providing users with comprehensive tools and resources to optimize their network security posture while simplifying deployment processes.
The following new resource and data source are available with the latest Terraform provider:
| resource “oci_network_firewall_network_firewall_policy_tunnel_inspection_rule” “test_network_firewall_policy_tunnel_inspection_rule_inspect” { #Required name = var.network_firewall_policy_tunnel_inspection_rule_name_1 network_firewall_policy_id = oci_network_firewall_network_firewall_policy.test_network_firewall_policy.id action = var.network_firewall_policy_tunnel_inspection_rule_action_inspect condition { #Optional destination_address = [oci_network_firewall_network_firewall_policy_address_list.test_network_firewall_policy_address_list_ip.name] source_address = [oci_network_firewall_network_firewall_policy_address_list.test_network_firewall_policy_address_list_fqdn.name] } #Optional position { # Optional – Either ‘after_rule’ or ‘before_rule’ parameter should be set. This should be set only if there is an existing rule before this. # after_rule = var.network_firewall_policy_tunnel_inspection_rule_name_1 # before_rule = var.network_firewall_policy_tunnel_inspection_rule_name_2 } } |
| data “oci_network_firewall_network_firewall_policy_tunnel_inspection_rules” “test_network_firewall_policy_tunnel_inspection_rules” { #Required network_firewall_policy_id = oci_network_firewall_network_firewall_policy.test_network_firewall_policy.id #Optional – Either ‘display_name’ or ‘tunnel_inspection_rule_priority_order’ parameter should be set. display_name = var.network_firewall_policy_tunnel_inspection_rule_name_1 # tunnel_inspection_rule_priority_order = var.network_firewall_policy_tunnel_inspection_rule_priority_order } |
Conclusion
Deploying a firewall out of band offers flexibility, scalability, and improved visibility into network traffic, all while minimizing disruptions to network operations and bolstering security posture. Thank you for your interest in OCI and the new tunnel inspection feature. We’re pleased to bring you this new dynamic and flexible solution for your security analysis needs. We look forward to hearing about how this feature improves your user experience and network monitoring, troubleshooting, and security analysis goals.
We encourage you to explore this new feature and all the enterprise-grade capabilities that OCI offers. You can share any product feedback that you have through email to the Virtual Networking group or submit a note in the comments. To further your knowledge, you can learn more about Oracle Cloud Infrastructure virtual networking services in our documentation. We look forward to any product feedback you have!