Skip to main content
Version: 5.2

Network Rules

Policy: Network Rules​

NeuVector automatically creates Network Rules from your running applications in Discover mode. You can also manually add them in any mode, Discover, Monitor, or Protect. Rules can be added or edited from the CLI or REST API.

NeuVector uses a declarative policy which consist of rules which govern allowed and denied application layer connections. NeuVector analyzes and protects based on not only IP address and port, but by determining the actual network behavior based on application protocols. This enables NeuVector to automatically protect any new application containers regardless of IP address and port.

Network rules specify ALLOWED or DENIED behavior for your applications. These rules determine what connections are normal behavior for your services as well as what are violations. You can delete automatically ‘learned’ rules as well as add new rules to your policy.

important

Network rules are enforced in the order that they appear in the list, from top to bottom. To re-order the rules, select the rule you want to move, then you will see a 'Move to' box appear at the top, and you can move the selected rule to the position before or after a specified rule.

important

If you edit (add, delete, change) rules, your changes are NOT applied until you click the Save button at the top. If you exit this page without deploying your changes, they will be lost.

Adding New Rules Add a rule using the ‘+’ either below another rule in the right column, or using the button in the lower right.

  • ID

(Optional) Enter a number. Network rules are initially ordered from lowest to highest, but rule order can be changed by dragging and dropping them in the list.

  • From

Specify the GROUP from where the connection will originate. Start typing and NeuVector will match any previously discovered groups, as well as any new groups defined.

  • To

Specify the destination GROUP where these connections are allowed or denied.

  • Applications

Enter applications for NeuVector to allow or deny. NeuVector understands deep application behavior and will analyze the payload to determine application protocols. Protocols include HTTP, HTTPS, SSL, SSH, DNS, DNCP, NTP, TFTP, ECHO, RTSP, SIP, MySQL, Redis, Zookeeper, Cassandra, MongoDB, PostgresSQL, Kafka, Couchbase, ActiveMQ, ElasticSearch, RabbitMQ, Radius, VoltDB, Consul, Syslog, Etcd, Spark, Apache, Nginx, Jetty, NodeJS, Oracle, MSSQL, Memcached and gRPC.

note

To select Any/All, leave this field blank

  • Ports

If there are specific ports to limit this rule to, enter them here. For ICMP traffic, enter icmp.

note

To select Any/All, leave this field blank

  • Deny/Allow

Indicate whether this rule is to Allow this type of connection, or Deny it.

If Deny is selected, NeuVector will log this as a violation while in Monitor mode, and will block this while in Protect mode. The default action is to Deny a connection (log violation only if in Monitor mode) if no rule matches it.

Don’t forget to Deploy/Update if you make any changes!

Egress Control: Allowing Connections to Trusted Internal Services on Other Networks​

A common use case for customizing rules is to allow a container service to connect to a network outside of the NeuVector managed cluster’s network. In many cases, since NeuVector does not recognize this network it will classify it as an ‘External’ network, even if it is an internal network.

To allow containers to connect to services on other internal networks, first create a group, then a rule for it.

  1. Create a Group. In Policy -> Groups, click to add a new Group. Name the group (e.g. internal) then specify the criteria for the group. For example, specify the DNS name, IP address or address range of the internal services. Save the new group.

  2. Create a Rule. In Policy -> Rules, click to add a new rule. Select the group representing the container From which the connections will originate, then the To group (e.g. internal). You can further refine the rule with specific protocols or ports, or leave blank. Make sure the selector is set to Allow (green).

Be sure to click Deploy to save the new rule.

Finally, review the list of rules to make sure the new rule is in the order and priority desired. Rules are applied from top to bottom.

Ingress IP Policy Based on XFF-FORWARDED-FOR​

In a Kubernetes cluster, an application can be exposed to the outside of the cluster by a NodePort, LoadBalancer or Ingress services. These services typically replace the source IP while doing the Source NAT (SNAT) on the packets. As the original source IP is masqueraded, this prevents NeuVector from recognizing the connection is actually from the 'external'.

In order to preserve the original source IP address, the user needs to add the following line to the exposed services, in the 'spec' section of the external facing load balancer or ingress controller. (Ref: https://kubernetes.io/docs/tutorials/services/source-ip/)

"externalTrafficPolicy":"Local"

Many implementations of LoadBalancer services and Ingress controllers will add the X-FORWARDED-FOR line to the HTTP request header to communicate the real source IP to the backend applications. This product can recognize this set of HTTP headers, identify the original source IP and enforce the policy according to that.

This improvement created some unexpected issues in some setup. If the above line has been added to the exposed services and NeuVector network policies have been created in a way that expect the network connections are coming from internal proxy/ingress services, because we now identify the connections are from "external" to the cluster, normal application traffic might trigger alerts or get blocked if the applications are put in "Protect" mode.

A switch is available to disable this feature. Disabling it tells NeuVector not to identify that the connection is from "external" using X-FORWARDED-FOR headers. By default this is enabled, and the X-FORWARDED-FOR header is used in policy enforcement. To disable it, go to Settings -> Configuration, and disable the "X-Forwarded-For based policy match" setting.

Special Enforcement for Istio ServiceEntry Destinations​

Egress network policy enforcement functionality was added in version 5.1.0 for pods to ServiceEntry destinations declared with Istio. Typically, a ServiceEntry defines how an external service referred by DNS name is resolved to a destination IP. Prior to v5.1, NeuVector could not detect and enforce rules for connections to a ServiceEntry, so all connections were classified as External. With 5.1, rules can be enforced for specific ServiceEntry destinations. Implicit violations will be reported for newly visible traffic if allow rules don't exist. These rules can be learned and auto-created under Discover mode. To allow this traffic, you can put the group into discover mode or create a custom group with destination addresses (or DNS name) and add a new network rule to this destination to allow the traffic.

Virtual Host Based Network Policy​

Custom groups can support virtual host based address groups. This enables a use case where two different FQDN addresses are resolved to the same IP address, but different rules for each FQDN should be enforced. A new custom group with ‘address=vh:xxx.yyy’ can be created using the ‘vh:’ indicator to enable this protection. A network rule can then use the custom group as the ‘From’ source based on the virtual hostname (instead of resolved IP address) to enforce different rules for virtual hosts.

Split Mode Network Protections​

Container Groups can have Process/File rules in a different mode than Network rules, as described here.

Built-In Network Threat Detection​

NeuVector automatically detects certain network attacks, regardless of protection mode. In Discover and Monitor mode, these threats will be alerted and can be found in Notifications -> Security Events. In Protect mode, these will alerted as well as blocked. Response rules can be created based on threat detection as well.

Note that customized network threat detection can be configured through the WAF rules section.

NeuVector includes the following detections for threats:

  • Apache Struts RCE attack
  • Cipher Overflow attack
  • Detect HTTP negative content-length buffer overflow
  • Detect MySQL access deny
  • Detect SSH version 1, 2 or 3
  • Detect SSL TLS v1.0, v1.1 (requires environment variable to enable)
  • DNS buffer overflow attack
  • DNS flood DDOS attack
  • DNS null type attack
  • DNS tunneling attack
  • DNS zone transfer attack
  • HTTP Slowloris DDOS attack
  • HTTP smuggling attack
  • ICMP flood attack
  • ICMP tunneling attack
  • IP Teardrop attack
  • Kubernetes man-in-the-middle attack per CVE-2020-8554
  • PING death attack
  • SQL injection attack
  • SSL heartbleed attack
  • SYN flood attack
  • TCP small window attack
  • TCP split handshake attack
  • TCP Small MSS attack