I wish to know how Azure NSGs work when it comes to statefulness and Denys.
For example, let's compare to AWS security groups.
# Example AWS Security Group inbound/outbound rules
Inbound: Port 80 from the internet
Outbound: Port 443 to the internet
Because of statefulness, even though I only allow 443 outbound implicitly, 80 outbound is allowed due to statefulness.
Do Azure NSGs work the same way? If I have an implicit Deny on all outbound traffic but have an Inbound rule for port 80 from some service, will outbound traffic to that service still be allowed over port 80 even with the implicit outbound deny rule?
Thanks
• Kindly do note the below points while creating rules in Network Security Groups.
a) The NSGs in Azure are Stateful. Meaning that if you open an incoming port, the outgoing port will be open automatically to allow the traffic. Thus, if you create an implicit deny rule for all the outbound traffic, but have an inbound allow rule for port 80 from some service, then this inbound rule will not take effect until it is configured at a priority higher than the ‘Deny’ rule when comparing to the corresponding inbound and outbound rules configured based on priority.
b) The default rules in a Network Security Group allow for outbound access and inbound access is denied by default. Access within the VNet is allowed by default.
c) Like normal ACLs, the rules are processed based on a priority.
d) NSGs can only be used in the Azure region that it was created in.
e) There is a soft limit of 100 NSGs per subscription and a soft limit of 200 rules per NSG.
As a result, though the NSGs are stateful, but their effective functionality depends on the priority of the rules set in the Inbound/Outbound rules allow/deny list. The higher priority, the more effective that rule will be, the lesser priority, the lesser probability of it getting effective as it will be overrided by the higher priority rules.
Kindly refer the below link for more details on the above: -
https://theithollow.com/2016/08/03/azure-network-security-groups/
Yes, Azure NSGs are stateful and work similarly.
If you specify an outbound security rule to any address over port 80,
for example, it's not necessary to specify an inbound security rule
for the response to the outbound traffic. You only need to specify an
inbound security rule if communication is initiated externally. The
opposite is also true. If inbound traffic is allowed over a port, it's
not necessary to specify an outbound security rule to respond to
traffic over the port.
Network security groups - Security rules
Related
Wanted to know the difference between security groups and internal prefix-list and to know which would be best for not allowing the external traffic to enter the cloud?
A Security Group is a firewall on an individual resource in an Amazon VPC.
For example, you could add a Security Group to an Amazon EC2 instance that only permits access on port 80 and 443 (HTTP and HTTPS). Any requests going to other ports would be blocked before reaching the instance. You could then add another rule that permits access to port 22 (SSH) but only from your IP address. You could connect, but requests from any other IP address would be blocked.
Rules can be configured for Inbound connections (going into the instance) and also for Outbound connections (requests leaving the instance). Requests are stateful, meaning that a request in one direction will always be permitted a response in the other direction. For example, if there is an Inbound rule permitting port 80, then the instance will be able to respond to an HTTP request without needing an Outbound rule that specifically permits the response.
Security Groups can also refer to each other. For example:
An Amazon EC2 instance running an application would have a Security Group permitting inbound HTTP and HTTPS connections, and all Outbound connections
An Amazon RDS database in the same VPC would have a Security Group permitting inbound database connections from the Security Group on the Amazon EC2 instance
That is, the database security group specifically refers to the instance security group. Any instance associated with the EC2 security group would be allowed to access the database.
When defining rules in a Security Group, you specify a CIDR that defines the IP address(es) that are permitted by the rule. For example, 0.0.0.0/0 means the entire Internet, while 1.2.3.0/24 means all IP addresses starting with 1.2.3.x.
Prefix Lists are simply a pre-defined list of CIDRs. They make it easier to define rules by permitting access from a specific Prefix List rather than having to define multiple rules with one CIDR per rule. So, prefix lists can be used by security group.
From azure documentation
A fully qualified domain name (FQDN) represents a domain name of a
host or IP address(es). You can use FQDNs in network rules based on
DNS resolution in Azure Firewall and Firewall policy. This capability
allows you to filter outbound traffic with any TCP/UDP protocol
(including NTP, SSH, RDP, and more). You must enable DNS Proxy to use
FQDNs in your network rules. For more information see Azure Firewall
DNS settings. link to documenation
I want to use azure firewall to filter inbound traffic based on FQDN, for example allow just traffic from the domain out.example.com to reach our virtual network resources,
is this supported ? The doc mention just outbound traffic.
I can't filter by IP addresses as the resolved IPs of this domain (out.example.com), are not static, and this is the reason behind why I want to use the azure firewall service.
Azure Firewall supports inbound and outbound filtering. Inbound protection is typically used for non-HTTP/S protocols. For example RDP, SSH, and FTP protocols.
Inbound Internet connectivity can be enabled by configuring Destination Network Address Translation (DNAT). You can configure Azure Firewall Destination Network Address Translation (DNAT) to translate and filter inbound Internet traffic to your subnets. When you configure DNAT, the NAT rule collection action is set to Dnat. Each rule in the NAT rule collection can then be used to translate your firewall public IP address and port to a private IP address and port. DNAT rules implicitly add a corresponding network rule to allow the translated traffic.
Application rules aren't applied for inbound connections. So if you want to filter inbound HTTP/S traffic, you should use Web Application Firewall (WAF). For more information, see What is Azure Web Application Firewall
I want to secure my web server vm to limit mainly to 443 and 3389 ports strictly. I denied everything else both outbound and inbound in the NSG for the web vm. But I can't rdp after doing so. When I relax the NSG to allow all outbound, then rdp starts working. My question is what outbound ports and protocols the rdp service needs to be opened in nsg beside 3389?
thesushil: In my case it turns out, I just needed to add an outbound rule to allow Azure AD communication over http and https, because I have azure AD authentication enabled. But I think the answer below would be helpful to others.
Be default, the RDP server listens on TCP port 3389 and UDP port 3389. Read wiki. You also could change the listening port for remote desktop.
If you want to secure your Azure VM limit to 443 and 3389 ports, you can add inbound port rules like this to only allow your client-specific IP address to access your Azure VM.
Also, please note that If inbound traffic is allowed over a port, it's not necessary to
specify an outbound security rule to respond to traffic over the port. Read https://learn.microsoft.com/en-us/azure/virtual-network/security-overview#security-rules
Network security group security rules are evaluated by priority using
the 5-tuple information (source, source port, destination, destination
port, and protocol) to allow or deny the traffic. A flow record is
created for existing connections. Communication is allowed or denied
based on the connection state of the flow record. The flow record
allows a network security group to be stateful. If you specify an
outbound security rule to any address over port 80, for example, it's
not necessary to specify an inbound security rule for the response to
the outbound traffic. You only need to specify an inbound security
rule if communication is initiated externally. The opposite is also
true. If inbound traffic is allowed over a port, it's not necessary to
specify an outbound security rule to respond to traffic over the port.
Existing connections may not be interrupted when you remove a security
rule that enabled the flow. Traffic flows are interrupted when
connections are stopped and no traffic is flowing in either direction,
for at least a few minutes.
Hope it helps.
I have provisioned App Gateway with WAF V2 SKU. Then, I have configured back-end pool to point to WebApp and added IP restrictions to allow only traffic from WAF IP. Then, i am attempting to add NSG to the provisioned Subnet to further restrict traffic to the Frontend IP address. I am getting an error (see below). Per Application Gateway FAQ this should be possible, but having trouble. Here is are the details of the deployment error:
Network security group /subscriptions/49c19f96-135d-4599-ae34-fd9087ce2bf8/resourceGroups/dbt-sc-platform-rg/providers/Microsoft.Network/networkSecurityGroups/BannerCIDRNsg blocks incoming internet traffic on ports 65200 - 65535 to subnet /subscriptions/49c19f96-135d-4599-ae34-fd9087ce2bf8/resourceGroups/dbt-sc-platform-rg/providers/Microsoft.Network/virtualNetworks/dbt-sc-platform-rg/subnets/default, associated with Application Gateway /subscriptions/49c19f96-135d-4599-ae34-fd9087ce2bf8/resourceGroups/dbt-sc-platform-rg/providers/Microsoft.Network/applicationGateways/dbt-sc-appgw. This is not permitted for Application Gateways that have V2 Sku.
The error message displays that you need to add incoming internet traffic on ports 65200 - 65535 to subnet-default in your Network security group-BannerCIDRNsg.
Per Application Gateway FAQ, you can whitelist Application Gateway access to a few source IPs.
This scenario can be done using NSGs on Application Gateway subnet. The following restrictions should be put on the subnet in the listed order of priority:
Allow incoming traffic from source IP/IP range.
Exceptions must be put in for incoming traffic on ports 65503-65534
for the Application Gateway V1 SKU and ports 65200 - 65535 for the V2
SKU. This port-range is required for Azure infrastructure
communication. They are protected (locked down) by Azure certificates.
Without proper certificates, external entities, including the
customers of those gateways, will not be able to initiate any changes
on those endpoints.
Allow incoming Azure Load Balancer probes (AzureLoadBalancer tag) and
inbound virtual network traffic (VirtualNetwork tag) on the NSG.
Block all other incoming traffic with a Deny all rule.
Allow outbound traffic to the internet for all destinations.
I want to add on #Nancy's answer, that actually, as per the documentation, there is no need to allow traffic from Any protocol. Allowing TCP traffic is enough.
There is also no need to allow traffic from Any source, it is sufficient to allow traffic from GatewayManager service tag.
You must allow incoming Internet traffic on TCP ports 65503-65534 for
the Application Gateway v1 SKU, and TCP ports 65200-65535 for the v2
SKU with the destination subnet as Any and source as GatewayManager
service tag. This port range is required for Azure infrastructure
communication.
So, I created the security rule as follows:
It should also be noted that:
These ports are protected (locked down) by Azure
certificates. External entities, including the customers of those
gateways, can't communicate on these endpoints.
I was getting the error message "Subnet associated to gateway with v2 sku" when trying to associate a subnet containing a Gateway V2 WAF to an existing NSG.
Strangely though it was no problem navigating to the VNET -> SubNet and after clicking the given SubNet then associating the NSG to that SubNet.
To associate NSG to the subnet containing an application gateway, allow traffic from
source: 'GatewayManager', port: Any to Destination: 'GatewayManager' service tag, Destination port: 65503-65534
Traffic from the AzureLoadBalancer tag with the destination subnet as Any must be allowed.
Note: just be cautious that you don't add deny rule before these inbound rules, so give them a low priority no, to avoid accidental misconfiguration
Also,
Outbound Internet connectivity can't be blocked
Reference : https://learn.microsoft.com/en-us/azure/application-gateway/configuration-infrastructure#network-security-groups
In azure portal, currently all ports are open, I need to deny all ports and allow only wanted once. When i do that, the websites are not accessible. The pic below is the inbound ports. I need to deny the first one(which is circled in red).
Do i have to allow any other port as well?
According to your description, you should check the priority of your NSG rules.
The rule that you deny any ports should have the lowest priority. It means the rule's priority number is the largest.
Also, you don't need add this rule. Azure's default rule denies all ports except the ports you opened.
More information about Azure NSG please refer to this link.