SSL Decryption: Hidden Threats no More

Why decrypt network traffic?

PREVIOUS      NEXT

SSL Decryption: Hidden Threats no More

Why decrypt network traffic?

More and more traffic is being encrypted. For this reason, for the firewall to inspect all traffic, it must also decrypt it due to high visibility, control, and protection at the highest levels.

SSL uses symmetric and asymmetric encryption.

  1. The client requires an SSL connection
  2. The server responds to the request by sending its certificate containing its identity and public key
  3. The client checks the certificate by looking for it in the list of known certificates. (PKI)
  4. The client generates a random symmetric key and encrypts it using the server’s public key.
  5. The server uses its private key to decrypt the session key (from step 4).

Types of decryption on Palo Alto Firewall

Palo Alto allows 3 types of decryption:

o SSL Forward Proxy

o SSL Inbound Inspection

o SSL Decryption

 

SSL Forward Proxy

 

SSL Forward Proxy decrypts SSL traffic between a host on your network and a server on the Internet. In this scenario, Palo Alto acts as an SSL Proxy that establishes a connection between your host and Palo Alto and separates (but logically related) communication between Palo Alto and the server on the Internet.

An example in which this type of encryption is helpful is when you allow employees in your network to read the Twitter line in your policies in Palo Alto. Still, you want to prohibit them from sending messages and posting content (tweeting). If SSL decryption is enabled, Palo Alto will easily distinguish within the policy whether Twitter traffic belongs to “reading,” “commenting,” or “chatting” and, based on that, defend or allow traffic. If encryption is not enabled, Palo Alto cannot know what type of application is within the SSL connection.

 

SSL Inbound Inspection

 

SSL Inbound Inspection decrypts traffic coming from external users to your internal services. For this decryption, you must have a server private key and certificate. In this scenario, Palo Alto does not act as a proxy but directly forwards the request to the internal server. For that reason, you need the previously mentioned certificates because the connection is formed directly between the host and the server. Security policies are accepted for traffic so that the firewall can block or allow traffic between the host on the public network and your internal server.

 

SSH Decryption

 

SSH Decryption is used to detect and decrypt incoming and outgoing SSH traffic. If an SSH tunnel is detected, the SSH connection is blocked not to be used to tunnel unauthorized applications and other content.

 

Proxy

 

A proxy is an intermediary in communication between a client and a server. The proxy takes the package from the client and recreates it again towards the client. In the case of encrypted communication, a proxy receives an SSL request from a client and instead sends it to a server on the Internet. The same response is downloaded from the proxy server and sent back to the client in the reverse direction. It provides encrypted communication between the client and the proxy and the proxy and server on the Internet.

 

PKI (Public Key Infrastructure)

 

PKI solves the problems of secure identification of the public key, using a digital certificate to verify the public key owner. You can see the components of PKI in the picture below:

 

 

 

PKI is a set of hardware, software, policies, and standards used to create, manage, distribute a certificate. All this is necessary for the certificate holder to publicly confirm that he/she is what he/she pretends to be.

Root CA (Certified Authority) is the supreme Authority and provides services that authenticate devices, services, people by issuing a certificate that confirms their identity and public key.

The Root CA authorizes the Intermediate CA to certify or authorize other lower CAs. Each CA has a database with active certificates, revoked certificates, issued certificates, etc.

On the side of end devices, the devices are themselves that keep the certificates issued to them and the private key. Users refresh the certificate database themselves or with the help of software. If CA’s certificate is not in the user’s database, it will receive an unreliable warning message about the site they are visiting.

 

Configuring decryption

  1. Create 2 self-signed certificates (trusted and untrusted)
  2. Export the trusted certificate and import it to the end-user (computer)
  3. Create a decryption profile (optional)
  4. Create a decryption policy
  5. Check if the traffic is decrypted

 

  1. Creating self-signed certificates

Device> Certificate Management> Certificates> Generate

 

The image below shows the steps to create a self-signed trusted certificate

 

 

The image below shows the steps to create a self-signed untrusted certificate

 

 

  1. Export of self-signed trusted certificate and installation on a client

The image below shows the steps to export a self-signed trusted certificate

 

 

The image below shows the steps to install a self-signed trusted certificate on a client

 

 

 

 

 

 

 

 

  1. Create a decryption profile

Object> Decryption> Decryption Profile> Add

The image below shows the steps to create a decryption profile. The decryption profile serves to let the firewall know how to treat the traffic being decrypted.

 

 

  1. Creating a decryption policy

Policies> Decryption> Add

The image below shows the steps for creating a decryption policy. The policy determines which traffic will be decrypted. The name, source and destination zone, and traffic action (No Decrypt or Decrypt) are defined.

 

 

 

Defining the source of the traffic to be decrypted

 

 

 

Defining the destination to which the decrypted traffic is going

 

 

Defining the type of services.

 

 

Defining the action to be applied to the decrypted traffic as well as the type of decryption and the decryption profile.

 

Find and check decrypted traffic in the log section.

PREVIOUS      NEXT

Before you continue...
Subscribe to our monthly content digest and stay up-to-date on everything industry related!

Automation for Better Company Culture

Ansible Automation Platform Overview

PREVIOUS      NEXT

Automation for Better Company Culture

Ansible Automation Platform Overview

If we want to do it justice, we could not say that Ansible is just an IT automation platform. Also, if we say that it only saves time making repetitive tasks automated, we will reduce the significance of a project like this. Therefore, I like to say that every part of the IT industry should pay close attention to what Ansible offers.

Why is that? Well, Ansible provides a framework for significant improvements in company culture by eliminating points of misunderstanding between different teams, which leads to better communication and greater employee satisfaction over time. Development, testing, and QA teams, for example, being typical consumers of OS builds, can be sure that they are constantly working on proper base OS configurations while doing their jobs. And this is just the start of Ansible benefits.

 

 

So what is Ansible?

 

We can define it as a configuration management, deployment, and orchestration tool. It aims to be a more productive replacement for many core capabilities in other automation solutions. But, I think the most beneficial aspect of Ansible is portrayed in its endeavors to provide clear orchestration of complex multi-tier workflows, unify OS configuration, and unify application software deployment under a single framework.

 

Who can use Ansible?

 

I think anybody who likes elegant solutions on which you can build creatively. This simplicity is shown chiefly in its extremely low learning curve for administrators, developers, and IT managers. Ansible seeks simplicity in building descriptions of IT, and the goal is to make them easy to understand. This practically means that new users can be quickly brought into a new IT project. Likewise, if somebody is away from a project for a long time, longstanding automation content can be easily understood.

Let’s dive into a more in-depth explanation of Ansible architecture!

 

Platform Components

 

Ansible Engine – The engine that moves Ansible, relied on the massive, global community behind the Ansible project. It adds the capabilities and assurance from Red Hat to help businesses adopt automation at any scale across the organization.

 

 

Ansible Tower – The enterprise foundation of Ansible Automation Platform, helping organizations scale IT automation, manage complex deployments, and govern automation. It allows users to centralize and control their IT infrastructure with a visual dashboard, role-based access control, and more.

 

 

Content Collections – Make it easier for Ansible users to get up and running with precomposed roles and modules. Backed by a robust partner network of certified modules, requires less upfront work by the customer.

 

 

Automation Hub – The official location to discover and understand Red Hat-supported Ansible content and Ansible Certified Partner content. Find precomposed content written by Ansible Certified Partner organizations and quickly share that content with other users.

 

 

 

Automation Analytics – runs analytics across multiple Ansible Tower clusters, analyzing usage, uptime, and execution patterns across different teams running Ansible. Users can analyze, aggregate, and report on data around their automation and how that automation is running in their environment.

 

 

How does Ansible look from the inside?

 

The keyword here is Playbook. Ansible uses Playbooks to automate IT ecosystems. Essentially, Playbooks are YAML definition of automation tasks, and they describe how a particular segment of automation should be done, and it is human readable. Playbook clearly states what each individual component of your IT infrastructure should behave but still allows components to react to discovered information and to operate dynamically with one another. This responsiveness of Playbooks plays a significant role when you use Ansible for large-scale automation.

 

 

If we zoom in and look into Playbooks in more detail, they consist of plays that define automation across a set of hosts, and those set of hosts is called inventory. Each play is composed of various tasks that can target one, a few, or all the hosts in the inventory. A task is a call to Ansible modules, and a module is a small piece of code for doing a specific task. Ansible includes hundreds of modules, from simple configuration management to managing network devices and maintaining infrastructure on major cloud providers. This means that tasks can span from placing a simple configuration file to target machines, to spinning up the entire public cloud infrastructure.

Those included modules in Ansible have a specific idempotency feature, and that means that they check if a particular task needs to be done before executing it. It means that if, for example, we want to start a web server, the configuration is only done if the server is not already started. This ensures that the configuration can be applied repeatedly without side effects.

 

 

On top of this, the user can encapsulate the Playbook into a reuseable role. Thus, it can be used if a user wants to apply a standard configuration in different scenarios. I already talked about this at the beginning of this blog. This is the feature that can eliminate a point of misunderstanding between various teams in a company because you can provide the same server configuration role that can be used in the development, test, and production automation. Check out the Ansible Galaxy community site for thousands of customizable roles to build your Ansible Playbook.

 

Additional benefits: performance and security

 

Ansible has one differentiating feature that separates it from other automation tools: agentless architecture. It runs in a “push” model, so no software must be installed on remote machines to make them manageable. Ansible uses remote management frameworks that already exist natively on Linux, Unix, and Windows. And now, we have a performance benefit because no resources are consumed on managed machines when Ansible is not controlling them. This ensures Ansible is a go-to solution for automating large environments with concerns about stability or performance. Additionally, this increases security because only Ansible “modules” are passed to remote machines, and thus those machines can’t see or affect how other machines are configured.

Ansible features remoteness on an even higher level because it has elevated security on a higher level. It leverages sudo, su, and other privilege escalation methods on request when necessary. Additionally, it does not require dedicated users or credentials because it respects credentials user supplies when running Ansible. And this is important because those with access to the control server, for example, cannot make content be pushed out to remote systems without also having credentials on remote systems.

 

 

Advanced user?

 

If you intend to be an advanced user of Ansible and want to use it to automate and orchestrate complex environments, there are a set of features that can make your life easier. To name just a few, I like to mention the conditional execution of tasks, the ability to gather variables and information from the remote systems, the ability to spawn long-running asynchronous actions, the ability to operate in push or pull configuration, a check mode to test for pending changes without applying the change and the ability to tag certain plays and tasks so that only certain parts of the configuration can be applied, etc. The best thing about Ansible is that all these features provide a logical framework for automation and orchestration at scale. It can be understood by anyone from the developers to operators to CIOs.

 

One theoretical example of complex automation

 

Ansible would not be what it is if it could not do more than just one stream automation tool. Complex orchestration with Ansible can be achieved with zero downtime by combining different tasks into a Playbook. For example, let’s say that the infrastructure consists of:

  • Application servers
  • Database servers
  • Content servers
  • Load balancers
  • Monitoring system

For example, we want to update the whole system, a live and running environment, and we can’t afford downtime. In this case, Ansible can be used to implement a complex cluster-wide rolling update consisting of:

  • Consulting a configuration/settings repository,
  • Configuring the base OS on all machines and enforcing the desired state,
  • Identifying a portion needed to update
  • Signaling the monitoring system
  • Signaling load balancers
  • Stopping the web application server
  • Deploying or updating the web application server code, data, and content
  • Starting the server
  • Running tests
  • Repeating this process for other components or tiers
  • Sending email reports and logging

This is, of course, an exemplary model intended to show one possible Ansible use case. The good thing about Ansible is its modular nature, its ability to extend and cover potentially unlimited automation use-cases. So the question is not how to use Ansible correctly; the question is how you can extend it to apply its features to just the proper case and in just the right way for you.

 

 

How to extend Ansible?

 

It is possible that Ansible module database mentioned above does not contain just the suitable module you need. But, Ansible can accept any code as long as it can take JSON as input and produce JSON as output. That means Ansible is a potent tool for developing new ways of orchestrating and automating infrastructures and has unlimited extensibility potential. So its limitations are pretty much the limitations of the user who uses it for automation.

There is also an extension possibility through support for dynamic inventory. It lets Ansible Playbooks be run against a set of machines and infrastructure discovered at runtime rather than statistically defined. Even the runtime behavior of Ansible can be easily extended by the plugin mechanism. New callback plugins can log to log aggregators, send messages to notification services; new connection plugins can be written to access managed nodes in new ways, etc. So, no matter how custom the environment, you can make it work with Ansible.

 

Understood by everyone

 

I’m always for making things simpler and more efficient at the same time. But one important thing in making engineers’ life easier is often overlooked. Of course, we always look for powerful tools that simplify our jobs on a logical level. That is ok and true if we border our view to a single operations team or even an operations department. But we rarely think about how to raise efficiency on the level of the whole organization. This is done by increasing understandability between organization branches or departments, and this is often overlooked. Processes can indeed be simplified, and productivity can rise if all IT teams and departments in a firm have a common language that they can understand.

 

 

Ansible can help with this because it can accomplish all types of automation tasks. Yet, it doesn’t resemble software programming languages but rather basic textual descriptions of desired states and processes while being neutral to the types of processes described. Thus, it can be understood even by those untrained in reading those configurations. This is the beginning of, if not the solutions, to the communication issue I mention above, and undoubtedly a good start to implement a DevOps culture in your organization.

 

Capabilities overview

 

Now, for the end, let’s dive into a quick tour around basic Ansible capabilities. Red Hat Ansible Automation Platform allows users to take three simple actions with their enterprise automation journey:

  • Create – by using Ansible’s massive open source community and prebuilt Ansible Content Collections of the most-used Ansible roles, plugins, and modules. Codify your infrastructure and share it across teams and individuals.
  • Scale – by easy transfer of your automation into multiple domains and across different use cases.
  • Engage – by taking your automation even further with analytics, policy and governance, and content management with the SaaS-based tools in Ansible Automation Platform. These tools include:
    • Content Collections, a new packaging format that streamlines the management, distribution, and consumption of Ansible content.
    • Automation Hub, a repository for certified content via Ansible Content Collections.
    • Automation Analytics for improving automation efficiencies across Red Hat Ansible Automation Platform deployments.

 

 

Breadth of integrations

 

Red Hat Ansible Automation Platform supports a variety of platforms across servers, clouds, networks, containers, and more to meet you where you are in your automation journey:

  • Operating systems and virtualization: Red Hat Enterprise Linux®, Windows and Windows Server, VMware
  • Networks: Arista, Cisco, F5, Infoblox, Juniper, Palo Alto
  • Cloud: Amazon Web Services, Google Cloud Platform, Microsoft Azure, OpenStack®
  • DevOps tools: Atlassian, Check Point, CyberArk, Datadog, IBM, Splunk
PREVIOUS      NEXT

Before you continue...
Subscribe to our monthly content digest and stay up-to-date on everything industry related!