We have a series of articles looking at common misconfigurations and dangerous defaults we’ve seen in the wild.
Configuration settings can create security gaps that expose applications and their data to cyberattack and possible breach. Many of the configurations happen because dev, infrastructure and operations teams do not change the default configuration of the device, application or provider during installation. We are on the hunt for common configuration settings in the wild and trying to help teams find their configurations and set appropriate/intential values.
Next up, Terraform and firewall rules, particularly on AWS and Azure.
Firewall rules overwriting each other
How you define security groups for AWS with Terraform matters. The Terraform documentation defines the interaction between rules that will be overwritten.
You should not use the aws_vpc_security_group_egress_rule and aws_vpc_security_group_ingress_rule resources in conjunction with an aws_security_group resource with in-line rules or with aws_security_group_rule resources defined for the same Security Group, as rule conflicts may occur and rules will be overwritten.
There need to be checks ensuring that these conflicting definitions are not made at all. These should be caught in your IaC Terraform files by your friendly neighbourhood IaC static analyzer (you’ve embedded in your CI/CD pipeline, right?).
Example Terraform for AWS VPC
resource "aws_security_group" "allow_tls" {
name = "allow_tls"
description = "Allow TLS inbound traffic"
vpc_id = aws_vpc.main.id
ingress {
description = "TLS from VPC"
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = [aws_vpc.main.cidr_block]
ipv6_cidr_blocks = [aws_vpc.main.ipv6_cidr_block]
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
ipv6_cidr_blocks = ["::/0"]
}
tags = {
Name = "allow_tls"
}
}
resource "aws_vpc_security_group_egress_rule" "example" {
security_group_id = aws_security_group.allow_tls.id
cidr_ipv4 = "10.0.0.0/8"
from_port = 443
ip_protocol = "tcp"
to_port = 443
}
Test Environment
- CoGuard CLI version 0.2.14
- KICS version 1.7.9-alpine (Docker)
- Snyk version 1.1203.0
All tests were done on the above file using macOS and linux versions.
Summary Results
| Severity |
CoGuard |
Snyk |
KICS |
| Total |
2 |
1 |
3 |
| High |
1 |
|
|
| Medium |
|
|
|
| Low |
1 |
1 |
1 |
| INFO |
|
|
2 |
Because the Terraform file is a valid file it does not trigger a lot of configuration errors. All three tools identify issues with the AWS Security Groups. CoGuard identifies the mixing of AWS security group definitions.
CoGuard Results
$ coguard folder ./
XXXXXXXXXXXK
xXXXXXXXXXXXXXXXXXXl
XXXXX. ;XXXXO .XXXXXXXXXX oXXXX XXXXc xXXXX' 'XXXXXXXXXXXXO XXXXXXXXXXX;
lXXXx lXXXXXXXX, 0XXX; cXXXXXXXXXXXXXX. oXXXX XXXXc :XXXXXX 'XXXXXXXXXXXXXXX. XXXXXXXXXXXXXX'
dXXX. .XXXXXx 0XXXXX ... dXXXX' cXXXX. oXXXX XXXXc .XXXXXXX0 'XXXX' OXXXX XXXXo .XXXXk
;XXX xXXX do .XXXc 'XXXX, oXXXX XXXXc XXXX.oXXXd 'XXXX' ,XXXX. XXXXd XXXXd
0XXl ;XXk ,, KXX. lXXXXoXXXX XXXXc OXXXl 0XXX: 'XXXX' .XXXXk XXXXd lXXXX
XXX: oXX: cll. ,ll: oXX; oXXXX .XXXXXXXXo oXXXX XXXXc oXXXO .XXXX. 'XXXXXXXXXXXXXX; XXXXd lXXXX
OXXo ;XXO do KXX. cXXXX. .XXXXXXXXo oXXXX XXXXc ;XXXX :XXXX 'XXXXXXXXXXXXl XXXXd xXXX0
;XXX. oXXX ,, .XXX: .XXXXo XXXXo lXXXX .XXXX: .XXXXXXXXXXXXXXXO 'XXXX' .XXXXd XXXXd ,XXXX;
oXXX. XXXXXX:lXXXXXK ;XXX: .XXXXX. XXXXo XXXXX .XXXX0 XXXXx XXXXo 'XXXX' .XXXX0 XXXXd .XXXXX,
cXXXO ;XXXXXXXX. XXXX' xXXXXXXXXXXXXXX. kXXXXXXXXXXXXd kXXXX ,XXXX:'XXXX' XXXXK XXXXXXXXXXXXXl
KXXXX; lXXXXx 'XXXXXXX cXXXXXX; lXXXX, dXXXXlXXXX' KXXXX XXXXXXXXK
oXXXXXXXXXXXXXXXXXX:
OXXXXXXXXXXd
SCANNING FOLDER blog-examples-firewall
Found file /AWS-Firewall-Rules-Example.tf
Found configuration files for terraform in non-standard location.
SCANNING OF blog-examples-firewall COMPLETED
Scan result: 2 checks failed, 1 High/0 Medium/1 Low (🔧 0 candidates for auto-remediation)
X Severity 5: terraform_aws_no_mix_network_security_group_rules (affected files: ./AWS-Firewall-Rules-Example.tf for service terraform)
Documentation: The AWS provider for Terraform allows the definition of network
security rules both inline in a `aws_security_group` resource, as
well as in a `aws_vpc_security_group_egress_rule` resource.
However, in the current version of Terraform, mixing is not
recommended, since it can lead to rules being overwritten.
Remediation: Ensure that you either always define network
security rules using the `egress` directive within
`aws_security_group` resource definitions, or separately as
`aws_vpc_security_group_egress_rule` resource, but do not mix
both approaches. Source: https://registry.terraform.io/provider
s/hashicorp/aws/latest/docs/resources/security_group
X Severity 1: terraform_aws_no_unused_security_groups (affected files: ./AWS-Firewall-Rules-Example.tf for service terraform)
Documentation: When defining a security group for EC2-instances, we also expect
it to be used. Remediation: For every resource of type
`aws_security_group`, ensure that it is referenced at least in
one `aws_instance` resource under `security_groups` or
`vpc_security_group_ids`. Source: https://registry.terraform.io
/providers/hashicorp/aws/latest/docs/resources/instance
Scan result: 2 checks failed, 1 High/0 Medium/1 Low (🔧 0 candidates for auto-remediation)
Snyk Results
$ snyk iac test --report --org=927c4fe6-f615-45ae-97f8-954e44413e8d
Snyk Infrastructure as Code
✔ Test completed.
Issues
Low Severity Issues: 1
[Low] AWS Security Group allows open egress
Info: The inline security group rule allows open egress. Open egress can be
used to exfiltrate data to unauthorized destinations, and enable
access to potentially malicious resources
Rule: https://security.snyk.io/rules/cloud/SNYK-CC-TF-73
Path: resource > aws_security_group[allow_tls] > egress
File: AWS-Firewall-Rules-Example.tf
Resolve: Set `egress.cidr_blocks` attribute to specific ranges e.g.
`192.168.1.0/24`
-------------------------------------------------------
Test Summary
Organization: d-U5bKD53qopZ7jyVZGLXF3N
Project name: blog-examples-firewall
✔ Files without issues: 0
✗ Files with issues: 1
Ignored issues: 0
Total issues: 1 [ 0 critical, 0 high, 0 medium, 1 low ]
-------------------------------------------------------
Report Complete
KICS Results
docker run -t -v ~/src/blog-examples-firewall:/path checkmarx/kics:latest scan -p /path/AWS-Firewall-Rules-Example.tf -o "/path/"
.0MO.
OMMMx
;NMX;
... ... ....
WMMMd cWMMM0. KMMMO ;xKWMMMMNOc. ,xXMMMMMWXkc.
WMMMd .0MMMN: KMMMO :XMMMMMMMMMMMWl xMMMMMWMMMMMMl
WMMMd lWMMMO. KMMMO xMMMMKc...'lXMk ,MMMMx .;dXx
WMMMd.0MMMX; KMMMO cMMMMd ' 'MMMMNl'
WMMMNWMMMMl KMMMO 0MMMNoMMMMMMMXkl.
WMMMMMMMMMMo KMMMO 0MMMX .ckKWMMMMMM0.
WMMMMWokMMMMk KMMMO oMMMMc . .:OMMMM0
WMMMK. dMMMM0. KMMMO KMMMMx' ,kNc :WOc. .NMMMX
WMMMd cWMMMX. KMMMO kMMMMMWXNMMMMMd .WMMMMWKO0NMMMMl
WMMMd ,NMMMN, KMMMO 'xNMMMMMMMNx, .l0WMMMMMMMWk,
xkkk: ,kkkkx okkkl ;xKXKx; ;dOKKkc
Scanning with Keeping Infrastructure as Code Secure v1.7.9
Preparing Scan Assets: Done
Executing queries: [---------------------------------------------------] 100.00%
Files scanned: 1
Parsed files: 1
Queries loaded: 1045
Queries failed to execute: 0
------------------------------------
Security Group Rule Without Description, Severity: INFO, Results: 1
Description: It's considered a best practice for all rules in AWS Security Group to have a description
Platform: Terraform
Learn more about this vulnerability: https://docs.kics.io/latest/queries/terraform-queries/aws/68eb4bf3-f9bf-463d-b5cf-e029bb446d2e
[1]: ../../path/AWS-Firewall-Rules-Example.tf:15
014:
015: egress {
016: from_port = 0
Resource Not Using Tags, Severity: INFO, Results: 1
Description: AWS services resource tags are an essential part of managing components. As a best practice, the field 'tags' should have additional tags defined other than 'Name'
Platform: Terraform
Learn more about this vulnerability: https://docs.kics.io/latest/queries/terraform-queries/aws/e38a8e0a-b88b-4902-b3fe-b0fcb17d5c10
[1]: ../../path/AWS-Firewall-Rules-Example.tf:23
022:
023: tags = {
024: Name = "allow_tls"
IAM Access Analyzer Not Enabled, Severity: LOW, Results: 1
Description: IAM Access Analyzer should be enabled and configured to continuously monitor resource permissions
Platform: Terraform
Learn more about this vulnerability: https://docs.kics.io/latest/queries/terraform-queries/aws/e592a0c5-5bdb-414c-9066-5dba7cdea370
[1]: ../../path/AWS-Firewall-Rules-Example.tf:1
001: resource "aws_security_group" "allow_tls" {
002: name = "allow_tls"
003: description = "Allow TLS inbound traffic"
Results Summary:
HIGH: 0
MEDIUM: 0
LOW: 1
INFO: 2
TOTAL: 3
Results saved to file /path/results.json
Generating Reports: Done
Scan duration: 16.755121508s
Conclusion
CoGuard was the only analyzer to identify the risk associated with mixing inline network security rules.
All of the configurations are valid. They pass a syntax check and a validity check. There are unique circumstances as related to the structure for AWS and Azure in mixing security group definitions. CoGuard is able to identify a possible risk related to the mixed uses age of aws_security_group and aws_vpc_security_group_egress_rule. While this might seem pedantic, it is possible that different developers working on the same infrastructure codebase at different points in time might each use the different but valid network security rules.
The role of the static analyzer is to detect:
- security vulnerabilities,
- performance issues,
- non-compliance with standards,
- And the use of out of date programming constructs.
And alert the teams to possible conflicts and risk. So that decisions can be made about the method and actual network security definitions.
Get started for free
At CoGuard, we believe that static analysis is an incredibly useful tool for developers, operations and security teams. As teams adopt cloud native applications, security and configuration requires new insights across cloud configurations, containers, applications and firewalls. You can get started for free today.
pip3 install coguard-cli
coguard folder ./
Photo credit: Diogo Fagundes on Unsplash
