I have a NSG for controlling inbound traffic to my VM. One of the rules controls inbound TCP traffic on port 5061. We only want traffic to come from a specific group of external IP addresses, otherwise the traffic will be dropped.
Is there a way to have a group of ip addresses defined for the source entry of the rule where I can easily modify that list after the rule is created? I thought that Azure IP Groups would be the answer but that is not an option in the drop down list.
This is a common feature for most firewall appliances I have used.
Thank you.
Unfortunately, NSG's do not offer this functionality. Although you can specify multiple source (public or private) IP addresses within one NSG rule, you would always have to modify that particular rule when you need to change the list of IP addresses, which makes it a little inconvenient - particularly if you use the same list of IP addresses across multiple NSG's.
Services like Azure Firewall do have such functionality and, like you mentioned, 3rd parties offer this as well. But those services come with additional costs.
Related
I have two servers: ExternalSrv and InternalSrv, on the same EC2 VPC.
I have a very simple setup using Nodejs, Express and Axios.
ExternalSrv handles requests from the public, which, of course, come in to ExternalSrv's public IP address. ExternalSrv calls InternalSrv to do some of the work.
In order to simplify the security group inbound rules on InternalSrv, I would like to allow ALL VPC IP address, but nothing else.
I find that ExternalSrv always uses its Public IP address when making requests to InternalSrv's Private IP address. Therefore, the security group needs to be updated with ExternalSrv's Public IP address whenever that address changes (Stop/Start, new instance, more instances, etc.). That seems like a fragility point in ongoing maintenance.
This seems like this should be easy, but I've been searching for an answer for quite some time.
Any insight would be appreciated.
Bill
When two Amazon EC2 instances in the same VPC communicate with each other, it is best to perform this communication via private IP addresses. This has several benefits:
Security Groups can refer to other Security Groups
Traffic stays within the VPC (if communicating via Public IP addresses, the traffic will exit the VPC and then come back in)
It is cheaper (there is a 1c/GB charge for traffic going out of the VPC and then back in)
The best-practice security setup for your situation would be:
Create a Security Group on ExternalSrv (SG-External) that would allow inbound traffic as necessary (eg port 80, 443), together with default "Allow All" outbound traffic
Create a Security Group on InternalSrv (SG-Internal) that allows inbound traffic from SG-External
That is, SG-Internal specifically references SG-External in its rules. This way, inbound traffic will be accepted from ExternalSrv without needing to know its IP address. It also allows other servers to be added to the Security Group in future and they will also be permitted access.
Yes, you could simply add a rule that limits inbound access to the CIDR of the VPC, but good security is always about having multiple layers of security. Restricting access will cut-down potential attack vectors.
We need to allow a platform traffic to reach our systems (as I know adding a static public IP in our network security group in azure), but they mention that they don't have a static public IP or a range of IPs to whitelist, but instead a static domain name
What I found in azure documentation and some questions is that filtering traffic based on FQDN is impossible for now in network security group resource !
Is there any other possibility to achieve this ?
The Azure firewall seems just working for outbound rules (as I understand from azure documentation)
Still waiting, help please !!
This is so wired, anyone was in the same situation before ??
Could you help me with understanding the pricing for loadbalancer in Azure. Here what I've found in manual https://azure.microsoft.com/en-us/pricing/details/load-balancer/
Am I right, if I add several Frontend IP configurations, Backend pools and Inbound NAT rules only, without any Load balancing rules I'll be charged only for the amount of data processed? The reason I am asking is that I can't find what is "outbound rules" there is no such item in the settings.
And,in general, my aim is just to redirect ports from public IP to VM.
Yes, you are right. If you are creating only Inbound NAT rules, you will be charged only for the amount of data processed and the charge of the Public IP address resource which is attached to the LB.
Outbound rules are not visible in Portal. You can configure it via CLI or PowerShell. It is used in scenarios where you have VMs without Public IP which are part of Internal Load balancers and need to talk to Internet.
I'm trying to set an one IP adresss (dynamic) as the source of inbound ssh rules for azure VM. But when its set to "any" works perfectly but given my local dynamic IP doesn't work(connection timed out).
Also tried giving CIDR block for source, but still confused as to why a single IP doesn't work.
Most 'Whats my IP' sites will give you your Public IP address that you can use for you NSG.
http://www.hazelnest.com/IPproject/MyIP/ip.php
But i believe the issue you are having is one i have seen in very large company networks, the IP you get from site is not really the IP for RDP/SSH.
Easiest and guaranteed way is to contact you networking guys to provide you with the information.
Another way is to check the IP you get on the RDP/SSH logs when you connect without restricting NSG. Then use that IP on the NSG, not that depending on the network this might change.
Linux:
Check the auth.log under the \var\log
IMAGE 1
Windows:
In the VM's Event Viewer, navigate to path below and check the event 22, that should have information.
Applications and Services Logs\Microsoft\Windows\TerminalServices-LocalSessionManager
IMAGE 2
I'm using Azure App Services that calls an external API that uses white-listing of IP addresses for defense-in-depth protection.
I'm aware I can find my Outbound IP addresses of my App Services under the WebApp -> Settings -> Properties -> Outbound IP addresses (showing a list of 4 comma separated IP addresses) which can be supplied to the external API whitelist. I understand Microsoft publishes a regularly updated list of Azure datacenter's IP addresses for outbound traffic that I can whitelist: https://www.microsoft.com/en-us/download/details.aspx?id=41653
The issue is the external API can only handle a number of IP addresses and not the full list of Azure datacenter IP's. Would it be safe to just provide the 4 comma separated IP addresses? Is there clear Microsoft documentation on how often or when the IP address can dynamically change?
I have tried to look for the answer and found two external sites that suggested it only changes when moving Azure regions [Ref 2] or if you scale up/down (but scale out/in is apparently fine) [Ref 1]. Is this correct information?
Is the Azure App Services Environment the only other viable alternative in my situation?
Late to the party on this one but just to flesh this out:
Unless you use an Application Service Environment (ASE) you cannot guarantee that the inbound or outbound IPs will change, however there some differences between inbound and outbound IP addresses.
When does an Inbound IP change?
Inbound IP will change when:
Delete an app and recreate it in a different resource group.
Delete the last app in a resource group and region combination and recreate it.
Delete an existing SSL binding, such as during certificate renewal
However, this can be countered by getting a static IP for inbound connections configure an IP-based SSL binding - you can even use a self-signed cert if you're not using any SSL functionailty.
Outbound IP addresses
This is where you sit and it's the space that is a little more volitile, this is from the docs directly:
The set of outbound IP addresses for your app changes when you scale your app between the lower tiers (Basic, Standard, and Premium) and the Premium V2 tier.
So in a nutshell if you will never scale up or down then you should be fine.
Edit: Re-reading the above and with a little test it looks like it's saying that the IPs will not change unless you ramp right up to the Premium V2 tier from a lower tier (or vice versa). A cursory test backs this up so:
Running under F1 free tier and scaling up to P1v2 gave me the following IP addresses:
Scaling back down to any of the lower tiers reverted the IP addresses to the same as the F1 tier.
Possible remediation
A very solution specific example but in-case it helps - where I've solved this before is monitoring the outbound IP addresses for the webapp, if it notices a change then it could send those IP addresses to a whitelist for update via an API call - but this could also just cause a high priority ticket to be raised.
I should note that we could do this because it wouldn't be the end of the world for a little bit of outage and we weren't expecting to scale up and down very often.
Otherwise, as you've noted, an Application Service Environment is your only belt and braces option.
References
When do inbound IPs change?
When do outbound IPs change?
Get a static inbound IP addresses
In addition to above resources about changes the other thing is that additional IP's might be added to accommodate additional capacity for outbound n/w calls.
Specific comment to look out for is "With the recent upgrades the Websites service has a stable set of outbound IP addresses allocated to each of its scale units. We continue to monitor network utilization and we might add (though never remove) additional IP addresses." by Stefan_MS
https://social.msdn.microsoft.com/Forums/azure/en-US/fd53afb7-14b8-41ca-bfcb-305bdeea413e/maintenance-notice-upcoming-changes-to-increase-capacity-for-outbound-network-calls?forum=windowsazurewebsitespreview