Skip to content

Policy Rule

The final step in the security posture is to add a ruleset to the Valtix Gateway. Each ruleset will have a set of policies that defines your security posture. When traffic is inspected, Valtix Gateway will go from top to bottom of the ruleset to identify if traffic matches the policy rule, hence the order of the policy matters. Security profiles can be attached to policy rules for deep packet inspection. Below is a diagram of how each security component is related in a ruleset.

policy_ruleset

HTTP Forward Proxy

Step 1: Create HTTP Proxy Service

  1. Navigate to Manage -> Security Policies -> Services
  2. Click Create
  3. For the Service Type, select Forward Proxy
  4. Provide a name for the service object (e.g. egress-proxy-http)
  5. [Optional] Add a description. (e.g. http egress service)
  6. In the service table, enter the following values:
Parameter Description
Decryption Profile Decryption profile to use for encrypted traffic. For HTTP traffic, this can be empty.
Dst Port Destination port of the egress traffic. For HTTP, the default port is 80.
Protocol: HTTP or HTTPS. Select HTTP

Step 2: Create HTTP policy rule in ruleset

  1. Click Manage -> Security Policies -> Rules
  2. Find the ruleset name that's associated with the Egress Gateway
  3. Click the rule set name
  4. There is already a rule here to allow the health check traffic from the load balancer on port 65534 (this port number was specified during the gateway creation)
  5. Click Create to create a new rule
  6. A new rule editor opens in the slide over panel on the right
  7. Add a name to the rule (e.g. any-egress-http)
  8. In the Type dropdown select Forward Proxy
  9. In the Service dropdown select egress-proxy-http (or the name provided to the http service created)
  10. In the Source dropdown select any (We will look in the later sections on how to restrict the Source by defining source address objects with cloud native attributes like VM Tags etc)
  11. Destination would be hard coded to any as gateway acts as a proxy and Valtix transparently changes the destination to the Gateway
  12. In the Action select Allow Log. This allows the Gateway to accept the traffic and log the flows that can be checked in the Investigate section of the Valtix Dashboard
  13. Leave all the profiles to empty, the rules will be enhanced to use these profiles in the later part of the tutorial
  14. Click Add
  15. You can create more rules if required. In this section of the tutorial you will not add any more rules
  16. Click Save to save all the rules and click Yes in the confirmation
  17. It takes a few seconds to save the policy. Once the rule set is saved, the Gateway instances pull the ruleset from the controller during the regular message exchange process

Step 3: Verify Traffic

Valtix Gateway is now configured to accept traffic on port 80 from any source. Run a sample curl command from the EC2 instance and check the logs

  1. SSH to the EC2 instance created in the spoke1-vpc. Default user is centos. (eg. ssh -i <private_key.pem> centos@<ec2_eip>)
  2. curl http://www.google.com
  3. Note a successful response
  4. Navigate to to Investigate -> Traffic Summary -> Logs
  5. Select the Gateway from the top pulldown
  6. Check that the logs appear in the table.
  7. If you want to see the flow of the traffic, you can navigate to Investigate -> Flow Analytics -> All Events. You would see 2 flows:
    1. EC2 instance ➡ Valtix Gateway
    2. Valtix Gateway ➡ www.google.com
  8. Check the FQDN column and verify that it shows www.google.com
  9. Check the Rule ID column and verify that it show the rule name that was configured (any-egress-http)
  10. Click on the Session ID to see the logs only for this session. (We will use this Session ID later to check more things)

HTTPS Forward Proxy

In the HTTP Proxy section, we setup a HTTP plain text traffic and egressed to http://www.google.com. In this section we will setup a certificate and a decryption profile so that Valtix Gateway can inspect traffic going out on TLS to https://www.google.com

Step 1: Create Certificate

Create/Import a certificate that will be used to sign the certificates from the external hosts and forwards to the clients. This certificate must be installed on all the app/client instances as a trusted root CA to avoid TLS certificate errors. For the tutorial purposes, we will generate a self-signed certificate. We will also ignore the TLS errors on the client machines.

  1. Navigate to Manage -> Certificates
  2. Click Create
  3. Choose Generate (Self-signed) as the Method
  4. Click Generate
  5. Provide a Name (e.g egress-self-signed)
  6. Click Save

Step 2: Create Decryption Profile

  1. Go to Manage -> Decryption
  2. Click Create
  3. Provide a name (e.g egress-tls-profile)
  4. In the Method dropdown choose Select Existing
  5. In the certificate dropdown choose the certificate created above (e.g egress-self-signed)

Step 3: Create HTTPS Proxy Service

  1. Navigate to Manage -> Security Policies -> Services
  2. Click Create
  3. For the Service Type, select Forward Proxy
  4. Provide a name for the service (e.g. egress-proxy-https)
  5. Add a description (e.g. https egress service)
  6. In the service table, enter the following values:
    1. Decryption Profile: Choose the decryption profile created in the previous section (e.g egress-tls-profile)
    2. Dst Port: 443
    3. Protocol: HTTPS
  7. Click Save

Step 4: Create HTTPS policy rule in ruleset

  1. Click Manage -> Security Policies -> Rules
  2. Find the ruleset name that's associated with the Egress Gateway
  3. Click the ruleset name
  4. There is already a rule here to allow the health check traffic from the load balancer on port 65534 (this port number was specified during the gateway creation) and another HTTP proxy rule that was added in the previous sections
  5. Click Create to create a new rule
  6. A new rule editor opens in the slide over panel on the right
  7. Add a name to the rule (e.g. any-egress-https)
  8. In the Type dropdown select Forward Proxy
  9. In the Service dropdown select egress-proxy-https (or the name provided to the http service created)
  10. In the Source dropdown select any
  11. Destination would be hard coded to any as gateway acts as a proxy and Valtix transparently changes the destination to the Gateway
  12. In the Action select Allow Log. This allows the Gateway to accept the traffic and log the flows that can be checked in the Investigate section of the Valtix Dashboard
  13. Leave all the profiles to empty, the rules will be enhanced to use these profiles in the later part of the tutorial
  14. Click Add
  15. Create more rules if required. In this section of the tutorial you will not add any more rules
  16. Click Save to save all the rules and click Yes in the confirmation
  17. It takes a few seconds to save the policy. Once the rule set is saved, the Gateway instances pull the ruleset from the controller during the regular message exchange process

Step 5: Verify Traffic

  1. SSH to the EC2 instance created in the spoke1-vpc
  2. curl https://www.google.com
  3. Since the certificate is not installed as a trusted root CA on the EC2 instance you will see a certificate error. You can install the certificate that is being used on the Gateway as a trusted CA on the EC2 instance or choose to ignore certifcate verification. For this tutorial, we will choose to ignore the error.
  4. curl -k https://www.google.com
  5. Note a successful response
  6. Naviagte to Investigate -> Flow Analytics -> All Events
  7. Select the Gateway from the top pulldown
  8. Check that the logs show in the table
  9. There are two (2) sessions created:
    1. EC2 instance ➡ Valtix Gateway
    2. Valtix Gateway ➡ www.google.com
  10. Check the FQDN column and verify that it shows www.google.com
  11. Check the Rule ID column and verify that it show the rule name that was configured (any-egress-http)
  12. Click on the Session ID to see the logs only for this session. (We will use this Session ID later to check more things)

Step 6:Verify Certificate

  1. run some other commands to see the certificate and verify that the certificate received from Google is signed by the self-signed certificate. Run the following command
curl https://www.google.com -vk 2>&1 | grep -A 5 -i "server certificate"
  1. You should see an output that looks similar to the following

* Server certificate:
*       subject: CN=www.google.com,OU=NetSec,O=Valtix Inc.,L=SantaClara,ST=California,C=US
*       start date: Dec 14 21:09:52 2020 GMT
*       expire date: Dec 15 21:09:52 2021 GMT
*       common name: www.google.com
*       issuer: O=Valtix
Look at the subject and issuer to confirm that the traffic was proxied by Valtix

  1. run this command from another machine or your laptop that accesses Google directly without going via Valtix.
curl https://www.google.com -vk 2>&1 | grep -A 5 -i "server certificate"
  1. You should see output similar to the following:
* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=www.google.com
*  start date: Nov 10 14:41:09 2020 GMT
*  expire date: Feb  2 14:41:08 2021 GMT
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
*  SSL certificate verify ok.

Notice the subject and issuer shows Google. 1. You can repeat these steps on other sites and verify certificate with and without Valtix.

Tech Notes

To install the certificate as a trusted CA on the EC2 instance, check this link

Tag-based Policy

Valtix Controller discovers all the instances and records of IP addresses, tags and other attributes. This allows us to create policy base on various attributes. This section we'll modify our existing policy to allow traffic for instances with certain tags.

Step 1: Create Address Object

  1. Go to the AWS console and add the tags to the EC2 instances
    1. Add a tag to the EC2 instance spoke1-z1-app with key Category and value prod
    2. Add a tag to the EC2 instance spoke1-z2-app with key Category and value dev
  2. It might take a minute or 2 for the Valtix Controller to detect the newly added tag
  3. Navigate to Manage -> Security Policies -> Addresses
  4. Click Create Address.
  5. Select Src/Dest.
  6. Provide a name (e.g vm-tag-dev)
  7. Select the object type as User Defined Tag
  8. Select the Cloud Account, region (e.g us-east-1) and VPC (e.g spoke1-vpc)
  9. Select the Instance Tag as Category and the Instance Tag Value as dev
  10. Click Save to save the address object

Click the address object and notice the addresses detected for the tag. You can see both the private and public IP addresses of the spoke1-z2-app instance in the details.

Step 2: Associate address object to rule

  1. Click Manage -> Security Policies -> Rule Sets
  2. Find the ruleset name that's associated with the Egress Gateway
  3. Click the rule set name
  4. We will be changing the source address for https traffic
  5. Click the table row any-egress-https and click Edit
  6. In the editor panel, set the Source to vm-tag-dev and click Save to save the rule
  7. Click Save to save the ruleset
  8. The rule shows spoke1-z1-apps-subnet as a Source Address in the rules table

Step 3: Validate Traffic

  1. SSH to the EC2 instance spoke1-z1-app created in the spoke1-vpc
  2. curl https://www.example.com -kv -o /dev/null
  3. This should fail for a prod instance as policy rule allows only dev tags
  4. SSH to the EC2 instance spoke1-z2-app created in the spoke1-vpc
  5. curl https://www.example.com -kv -o /dev/null
  6. You should receive a successful response for this dev instance

Go back to the AWS console and change the Category tag on spoke1-z1-app to dev and wait for a minute or two for the Valtix Controller to detect this change.

Check the details of the address object and verify that the IP address of spoke1-z1-app appears.

Re-run the above commands on this instance and verify it is now successful