Archive for the ‘Firewall’ Category

Managing cloud environments on large scale has many challenges.

One of the challenges many organizations are facing is managing network inbound/outbound network connectivity to their cloud environments.

Due to the nature of the public cloud, all resources are potentially public, unless we configured them otherwise.

What are the challenges in the network security domain?

There are many challenges related to network security, here are the most common ones:

• Unauthorized inbound network access – Publicly facing resources (such as virtual machines, object storage, databases, etc.) allowing anyone on the Internet access to the resources
• Unrestricted outbound network access – Internal resources (such as virtual machines, databases, serverless, etc.) can initiate outbound traffic to resources on the public Internet
• Managing network access rules at large scale – Ability to control thousands of firewall rules created over time, while managing multiple accounts for a specific cloud provider (or even multiple different cloud providers)
• Understanding the network attack surface – Ability to get a clear view of what inbound or outbound traffic is allowed or denied in a large cloud environment with multiple accounts
• Enabling the business, while keeping the infrastructure secure – Ability to respond to multiple business requests, using small network/information security / IT team

With all the above challenges, how do we keep our cloud network infrastructure secure and at a large scale?

Set Guardrails

One of the common ways to configure guardrails is to use organizational policies using Policy-as-Code.

All major cloud providers support this capability.

It allows us to configure rules for the maximum allowed permissions over our cloud environments according to our company security policy while allowing developers / DevOps to continue provisioning resources.

AWS Service control policies (SCPs)

Below are sample service control policies that can be configured at the AWS organizational level (with inheritance to the underlining OU’s), for restricting inbound access:

• Detect whether any Amazon EC2 instance has an associated public IPv4 address
• Detect whether Amazon S3 settings to block public access are set as true for the account
• Detects whether an Amazon EKS endpoint is blocked from public access
• Detect whether the AWS Lambda function policy attached to the Lambda resource blocks public access
• Detect whether any Amazon VPC subnets are assigned a public IP address

Azure Policy

Below are sample Azure policies that can be configured at the Azure subscription level, for restricting inbound access:

• Container Apps should disable external network access
• Network interfaces should not have public IPs
• All network ports should be restricted on network security groups associated to your virtual machine
• Function apps should disable public network access
• Azure SQL Managed Instances should disable public network access
• Public network access on Azure SQL Database should be disabled
• Public network access should be disabled for MySQL servers
• Public network access should be disabled for PostgreSQL servers
• Storage accounts should disable public network access

Google Organization Policies

Below are sample Google organization policies that can be configured at the GCP Project level, for restricting inbound access:

• Restrict public IP access on Cloud SQL instances
• Enforce Public Access Prevention
• Disable VM serial port access
• Define allowed external IPs for VM instances

Controlling inbound/outbound network traffic at scale

At large scale, we cannot rely on the built-in layer 4 access control mechanisms (such as AWS Security groups, Azure Network Security Groups, or GCP Firewall Rules) to define inbound or outbound traffic from/to our cloud environments.

For large scale, we should consider alternatives that will allow us to configure network restrictions, while allowing us central visibility over our entire cloud environment.

Another aspect we should keep in mind is that the default layer 4 access control mechanisms do provide us advanced protection against today’s threats, such as the ability to perform TLS inspection, control web traffic using URL filtering, etc.

Cloud-native firewall services:

Note: If you prefer to use 3^rd party NGFW, you can deploy it using AWS Gateway Load Balancer or Azure Gateway Load Balancer.

Additional references

• What is AWS Network Firewall?
• What is Azure Firewall?
• Google Cloud Firewall Overview

Understanding the network attack surface

One of the common issues with large cloud environments is to have a visibility of which inbound or outbound ports are opened to the Internet, exposing the cloud environment.

Common services to allow network visibility:

• AWS Network Access Analyzer
• Azure Monitor Network Insights
• Google Network Intelligence Center

Another alternative for getting insights into attack surface or network misconfiguration is to deploy 3^rd party Cloud Security Posture Management (CSPM) solution, which will allow you central visibility into publicly accessible virtual machines, databases, object storage, and more, over multiple cloud providers’ environments.

Summary

In this blog post, I have presented common challenges in managing network security aspects in cloud environments.

Using a combination of organizational policies, strict inbound/outbound traffic control, and good visibility over large or complex cloud environments, it is possible to enable the business to move forward, while mitigating security risks.

As the cloud threat landscape evolves, so do security teams need to research for suitable solutions to enable the business, while keeping the cloud environments secure.

Important note
The guide bellow instructs how to secure Cisco Firewall (PIX, ASA, FWSM).
Not all commands will work on every device series or on every IOS version.
It is highly recommended to test each setting in a test lab before implementing changes to production systems.

Hardening phase
Configure AAA Authentication for Enable Mode (ASA, FWSM, PIX):
aaa authentication enable console LOCAL

Configure AAA Authentication for Console and VTY Lines (ASA, FWSM, PIX):
aaa authentication serial console LOCAL
aaa authentication ssh console LOCAL
aaa authentication http console LOCAL


Configure Local Password (ASA, FWSM, PIX):
passwd <login_password> encrypted

Configure ASDM Access Control (ASA, FWSM, PIX):
http <remote_ip_address> <remote_subnet_mask> <interface_name>