SGs are a networking construct which contain ingress and egress rules for network communications. SGs may be attached to EC2 instances, as well as certain other AWS resources. Along with Network Access Control Lists, SGs are one of the two main mechanisms of enforcing network-level security.
While this resource provides facilities for searching inbound and outbound rules on a variety of criteria, there is currently no support for performing matches based on:
* IPv6 ranges
* References to other Security Groups
* References to VPC peers or other AWS services (that is, no support for searches based on 'prefix lists').
An `aws_security_group` resource block uses resource parameters to search for and then test a Security Group. If no SGs match, no error is raised, but the `exists` matcher returns `false`, and all scalar properties are `nil`. List properties returned under these conditions are empty lists. If more than one SG matches (due to vague search parameters), an error is raised.
# Ensure you have a Security Group with a specific ID
The Security Group ID of the Security Group. This is of the format `sg-` followed by 8 hexadecimal characters. The ID is unique within your AWS account; using ID ensures a match of only one SG. The ID is also the default resource parameter, so you may omit the hash syntax.
A string identifying the VPC that contains the Security Group. Since VPCs commonly contain many SGs, you should add additional parameters to ensure you find exactly one SG.
A list of the rules that the Security Group applies to incoming network traffic. This is a low-level property that is used by the [`allow_in`](#allow_in) and [`allow_in_only`](#allow_in_only) matchers; see them for detailed examples. `inbound_rules` is provided here for those wishing to use Ruby code to inspect the rules directly, instead of using higher-level matchers.
Order is critical in these rules, as the sequentially first rule to match is applied to network traffic. By default, AWS includes a reject-all rule as the last inbound rule. This implicit rule does not appear in the inbound_rules list.
If the Security Group could not be found (that is, `exists` is false), `inbound_rules` returns an empty list.
describe aws_security_group(group_name: linux_servers) do
its('inbound_rules.first') { should include(from_port: '22', ip_ranges: ['10.2.17.0/24']) }
end
### outbound\_rules
A list of the rules that the Security Group applies to outgoing network traffic initiated by the AWS resource in the Security Group. This is a low-level property that is used by the [`allow_out`](#allow_out) matcher; see it for detailed examples. `outbound_rules` is provided here for those wishing to use Ruby code to inspect the rules directly, instead of using higher-level matchers.
Order is critical in these rules, as the sequentially first rule to match is applied to network traffic. Outbound rules are typically used when it is desirable to restrict which portions of the internet, if any, a resource may access. By default, AWS includes an allow-all rule as the last outbound rule; note that Terraform removes this implicit rule.
If the Security Group could not be found (that is, `exists` is false), `outbound_rules` returns an empty list.
describe aws_security_group(group_name: isolated_servers) do
This InSpec audit resource has the following special matchers. For a full list of additional available matchers, please visit our [Universal Matchers page](https://www.inspec.io/docs/reference/matchers/).
`allow_in` and `allow_out` examine if at least one rule that matches the criteria exists. `allow_in` and `allow_out` also perform inexact (ie, range-based or subset-based) matching on ports and IP addresses ranges, allowing you to specify a candidate port or IP address and determine if it is covered by a rule.
`allow_in_only` and `allow_out_only` examines if exactly one rule exists (but see `position`, below), and if it matches the criteria (this is useful for ensuring no unexpected rules have been added). Additionally, `allow_in_only` and `allow_out_only` do _not_ perform inexact matching; you must specify exactly the port range or IP address(es) you wish to match.
The matchers accept a key-value list of search criteria. For a rule to match, it must match all provided criteria.
* from_port - Determines if a rule exists whose port range begins at the specified number. The word 'from_' does *not* relate to inbound/outbound directionality; it relates to the port range ("counting _from_"). `from_port` is an exact criterion; so if the rule allows 1000-2000 and you specify a `from_port` of 1001, it does not match.
* ipv4_range - Specifies an IPv4 address or subnet as a CIDR, or a list of them, to be checked as a permissible origin (for `allow_in`) or destination (for `allow_out`) for traffic. Each AWS Security Group rule may have multiple allowed source IP ranges.
* port - Determines if a particular TCP/IP port is reachable. allow_in and allow_out examine whether the specified port is included in the port range of a rule, while allow_in. You may specify the port as a string (`'22'`) or as a number.
* position - A one-based index into the list of rules. If provided, this restricts the evaluation to the rule at that position. You may also use the special values `:first` and `:last`. `position` may also be used to enable `allow_in_only` and `allow_out_only` to work with multi-rule Security Groups.
* protocol - Specifies the IP protocol. 'tcp', 'udp', and 'icmp' are some typical values. The string "-1" or 'any' is used to indicate any protocol.
* to_port - Determines if a rule exists whose port range ends at the specified number. The word 'to_' does *not* relate to inbound/outbound directionality; it relates to the port range ("counting _to_"). `to_port` is an exact criterion; so if the rule allows 1000-2000 and you specify a `to_port` of 1999, it does not match.
describe aws_security_group(group_name: 'mixed-functionality-group') do
# Allow RDP from defined range
it { should allow_in(port: 3389, ipv4_range: '10.5.0.0/16') }
# Allow SSH from two ranges
it { should allow_in(port: 22, ipv4_range: ['10.5.0.0/16', '10.2.3.0/24']) }
# Check Bacula port range
it { should allow_in(from_port: 9101, to_port: 9103, ipv4_range: '10.6.7.0/24') }
# Assuming the AWS SG allows 9001-9003, use inexact matching to check 9002
it { should allow_in(port: 9002) }
# Assuming the AWS SG allows 10.2.1.0/24, use inexact matching to check 10.2.1.33/32
it { should allow_in(ipv4_range: '10.2.1.33/32') }
# Ensure the 3rd outbound rule is TCP-based
it { should allow_in(protocol: 'tcp', position: 3') }
# Do not allow unrestricted IPv4 access.
it { should_not allow_in(ipv4_range: '0.0.0.0/0') }
end
# Suppose you have a Group that should allow SSH and RDP from
# the admin network, 10.5.0.0/16. The resource has 2 rules to
# allow this, and you want to ensure no others have been added.
describe aws_security_group(group_name: 'admin-group') do
# Allow RDP from a defined range and nothing else
# The SG must have this rule in position 1 and it must match this exactly
it { should allow_in_only(port: 3389, ipv4_range: '10.5.0.0/16', position: 1) }
# Specify position 2 for the SSH rule. Without `position`,
# allow_in_only only allows one rule, total.
it { should allow_in_only(port: 22, ipv4_range: '10.5.0.0/16', position: 2) }
# Because this is an _only matcher, this fails - _only matchers
# use exact IP matching.
it { should allow_in_only(port: 3389, ipv4_range: '10.5.1.34/32', position: 1) }