Cloud Native Network Segmentation (CNNS)
Cloud Native Network Segmentation (CNNS) is a Layer 4 container- and host-aware virtual firewall and network monitoring tool that enables you to segment your network and compartmentalize communication between the segments as a part of a comprehensive defense strategy.
CNNS works as an east-west firewall for containers and hosts. When enabled, CNNS automatically displays communications in your environment on Radar. Radar has a container and a host view, where you can view the network topology for your containerized apps and hosts respectively. You can then define rules to enforce what traffic to allow or block across the network entities. It enables you to identify and block known and unknown traffic moving laterally through your environment.
For all connections that are monitored using policies, you can set up a alert profile to send it to an external integration such as email.
Get Started with CNNS
CNNS leverages the Defenders that are deployed on your hosts and containers to monitor how your containers and hosts connect and communicate with each other in real-time.
The Defender inspects the connection before it is set up. Defender adds iptables rules to observe the TCP three-way handshake and watch for SYN messages required to set up new connections. When SYN messages arrive, Defender evaluates them to track all connections. After a connection is established, traffic flows directly between the source and destination without any further oversight from Defender.
To get started with CNNS, you begin with the Radar where you can view the connections between your hosts or containers for a typical microservices app.From this view, you can begin to identify how you want to segment your network, create network objects to represent each entity that is a source or a destination for traffic, and define policies to enforce what is allowed, alerted on or blocked between these network objects.
You can then audit the connection events to analyze how the policy is enforced both for CNNS for Containers and CNNS for Hosts.
You must enable CNNS to monitor all connections, including connections across hosts and connections to any configured network objects. By default, CNNS is disabled. When it is disabled, CNNS displays limited traffic flow data on Radar, including outbound connections to the Internet and connections local to the node itself.
- Log in to Prisma Cloud Console.
- Enable CNNS for hosts and containers.EnableContainer network monitoringandHost network monitoring.
Create CNNS Rules
You can create CNNS rules for enforcing access on specific ports or protocols for outbound traffic from hosts and containers on which Defenders are deployed. The actions you can enforce are alert, allow, or deny traffic.
CNNS policies use Network Objects for defining the source and destination in a rule. A network object is an entity or resource that your host or application interacts with and these can be internal or external entities including non-containerized services. For example, a payment gateway might pass information to an external service to verify transactions.
- For hosts--You can configure network objects to enforce traffic destined from a host to a subnet or another host.
- For containers--You can configure network objects to enforce traffic destined from a container (referred to as an image) to a DNS, subnet, or to another container.
When a connection is established between two entities in your environment, CNNS policy evaluates the first rule where both source and destination match. If there are no matching rules, it allows the connection.
- Log in to Prisma Cloud Console.
- Create a network object.After you create a network object, Radar shows any connection established to the network object.
- Select.ComputeRadarsSettingsAdd Network Object
- Enter a Name.
- Select the Type.For containers (referred to as an image) and hosts, you must select the scope from a Collection. Some example network objects are:
- Type: Subnet; Value: 127.0.0.1/32
- Type: Subnet; Value: 126.96.36.199./16
- Type: DNS; Value: google.com
- Type: Image; Value: Name of the containerimage from a collection you have already defined.A subnet network object can reference a range of IP addresses or a single IP address in a CIDR format.If a rule alerts or prevents outgoing connections to a subnet, traffic will be blocked even if you have defined rules that allow some of those ports for containers/hosts that may be running on machines with IPs from the subnet.
- Add CNNS policy on.ComputeDefendCNNSYou can add a maximum of 255 rules.
- To add a rule for containers:
- Select.ContainerAdd rule
- Select aSource.The source for a container rule must be a network object of type "Image".
- Select aDestination.The destination can be another container, subnet or DNS.
- Select a port or range of ports.For example * for any ports, a specific port number such as 80 or 443, or a range of ports such as 10-100.
- Select theEffect. The actions you can enforce are alert to allow the connection and generate an event, allow the connection, or prevent to deny connection and genarate an event from the source to the destination on the specified port or domain name.
- Save the rule.
- To add a rule for hosts:
- Select.HostAdd rule
- Select aSource.The source for a host rule must be a network object of type host.
- Select aDestination.The destination can be another host or subnet.
- SelectPorts.For example * for any ports, a specific port number such as 80 or 443, or a range of ports such as 10-100.
- Select theEffect. The actions you can enforce are alert, allow, or prevent to deny traffic from the source to the destination on the specified port or domain name.
- Save the rule.
Monitor CNNS Audit Events
You can view all connections to the CNNS hosts and containers.
- Filter forCNNS for containersorCNNS for hoststo view the relevant connection attempts.
- Explore more details on the audit event.You can view the runtime model for a container.
View Connections on Radar
Radar helps you visualize the connections for a typical microservices app and view your microsegmentation policy, which is an aggregation of all your rules.
Use the legend to interpret all the information. Some of the main points are outlined here. Radar presents the direction of flow for each connection, and displays the associated port number. An instance count for each node shows how many copies of the image are running as containers. Black bubble indicates that the runtime model is in enforcement mode. Blue bubble indicates that the runtime model is in learning mode.
It also displays attempted connections that generated alerts or were blocked, as well as attempted connections for which you have not defined any rules.
CNNS rules are dotted lines. When you click a line, you can see more information about the traffic between the source and destination objects. When a connection is observed, the dotted line becomes a solid line, and the CNNS policy is evaluated for a match. If there is a matching rule, the color of the port number reflects the matching rule’s configured effect. Yellow port numbers represent connections that raised an alert. Orange port numbers represent connections that were blocked.
If there’s no matching rule, by default the connection is allowed. The port number is in gray to indicate that the connection was observed, but there was no matching rule. As a best practice, review the port numbers in gray to assess the the need to add additional rules for enforcement.
If CNNS is disabled, you cannot view outgoing connections to external IP addresses.
Notifications for CNNS Alerts
, you can add an alert profile to enable alert notifications for CNNS alerts. The first event is sent immediately; all subsequent runtime events are aggregated hourly.
Recommended For You
Recommended videos not found.