We currently have an Amazon VPC containing several instances, all using the same security group.
Unfortunately, we have off-site staff who connect to our network via VPN. These users have an elastic IP address, meaning we're finding it tough to give them reliable access via the security group.
Does anyone know of a way of giving access via MAC address? Its the only solution i can think of other than arranging for them to have static IP's. Any ideas? Haven't been able to find a thing elsewhere online!
Cheers,
Per the security group documentation, only IP addresses/networks in CIDR notation and security group IDs are permitted as rules. You cannot use DNS, nor is there a straightforward way to allow access from a dynamic IP address such as in the case of your off-site staff.
You could set up a jump/bastion host in your VPC, harden it properly, allow access from everywhere to that jump host, and then allow that jump host to access your other instances in the VPC.
Alternatively, Dome9 offers a nifty service that adds an extension to users browsers to permit temporary access. Basically you authorize Dome9 to make changes to your security group. The user clicks the browser extension, Dome9 changes the security group to allow access from that user's IP address for some amount of time, and removes the rule when the time is up.
Related
We have a number of test/uat app services and websites running on app services. We currently restrict access via IP address by adding the IP address to the firewall.
This worked fine when it was mostly developers with static IP addresses but now we have suppliers and customers accessing the UAT systems from various places including home. It's a pain to maintain the IP addresses.
Ideally, I would like to be able to setup users in Azure and give them access to the various test system via this user.
Is there anyway to do something similar or is there a better approach.
Thanks.
You can use Azure App Registrations with a client secret and then use the client credentials flow to obtain access. This is probably the easiest way.
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 are utilizing Azure Web Apps' feature Access Restrictions. We restrict access and allow specific IPs and a subnet on our Virtual Network.
The problem is that only VMs that reside on that specific subnet are able to access the Web Apps, while VMs that reside on different subnets are not able to access the Web Apps which doesn't make sense.
Is such behavior is by counter-intuitive design or is it not working how it should?
Ist Part--
Yes, this behaviour is by counter-intuitive design. For your clear understanding the Thread you are referring here Two Virtual Machine can intercommunicate from different subnet but they should reside in same VNET. It is by design you can follow this MS document. For more information.
Second Part –
It is also by design , VMs that reside on that specific subnet are able to access the Web Apps and by setting up access restrictions, you have defined a priority-ordered allow/deny list that is IP addresses or Azure Virtual Network subnets.
When a request is made to your app, the FROM address is evaluated against the rules in your access restriction list. If the FROM address is in a subnet that's configured with service endpoints to Microsoft.Web, the source subnet is compared against the virtual network rules in your access restriction list. If the address isn't allowed access based on the rules in the list, the service replies with an HTTP 403 status code.
Please follow this document for more information.
Given that I create an Azure 'App Service'
How do I ensure that this service is only callable from ...
A.> 2 existing external servers (whose IP addresses will be known)
B.> 3 other App Services which I will be creating, but whose IP Addresses may not be known since I may need to scale those out (Over multiple additional instances)
To clarify... Is there some Azure service that will allow me to treat this collective of machines (both real and virtual) as a single group, such that I can apply some test on incoming requests to see if they originate from this group?
on Azure WebApps, You may wish to know; the IP Restrictions (https://learn.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions) allow you to define a list of IP addresses that are allowed to access your app. The allow list can include individual IP addresses or a range of IP addresses defined by a subnet mask. When a request to the app is generated from a client, the IP address is evaluated against the allow list. If the IP address is not in the list, the app replies with an HTTP 403 status code.
You can use IP and Domain Restrictions to control the set of IP addresses, and address ranges, that are either allowed or denied access to in your websites. With Azure WebApps you can enable/disable the feature, as well as customize its behavior, using web.config files located in their website.
Additionally, VNET Integration gives your web app access to resources in your virtual network but does not grant private access to your web app from the virtual network. Private site access is only available with an ASE configured with an Internal Load Balancer (ILB).
If you haven’t checked this already, checkout Integrate your app with an Azure Virtual Network for more details on VNET Integration (https://learn.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet)
I strongly suggest dropping the whole what's my IP approach and throwing in OAuth. Azure AD gives you access tokens with moderate effort —
Service to service calls using client credentials (shared secret or certificate)
Else, TLS client authentication would be next on my list. Although that tends to really suck if you have to deal with several programming stacks, TLS offloaders and what not.
I'm looking into developing a system via Google's App Engine for PHP. I'm now pretty well underway, but realized that I don't know a good way to deny incoming traffic from countries known for their nefarious inhabitants.
On other sites, I just block subnets via .htaccess. However, I'm now beginning to think it's impossible outside of using Google's own PHP request header designating the country code.
See their doc here: https://developers.google.com/appengine/docs/php/
It would be easy to just block it that way, but I'm not sure this would be the optimal way.
Any insight would be appreciated.
You can use the dos.yaml file to blacklist subnets. You create a dos.yaml file in the root directory of your application and then block IPs or entire subnets as specified here. Note that this file is limited to a maximum of 100 entries.
Once you have a list of country subnets which you wish to block (which you could obtain from a list like this or this), you can populate the dos.yaml file manually. Alternatively, you can use a script like this one to populate the file.
In addition to the DOS attack protection mentioned in #rudolph1024's answer it is now possible to enable a fully-featured firewall (still beta, recently released) to protect your GAE application.
From App Engine firewall:
The App Engine firewall enables you to control access to your App
Engine app through a set of rules that can either allow or deny
requests from the specified ranges of IP addresses.
Create a firewall to:
Allow only traffic from within a specific network
Ensure that only a certain range of IP addresses from specific networks can access your app. For example, create rules to allow only
the range of IP addresses from within your company's private network
during your app's testing phase. You can then create and modify your
firewall rules to control the scope of access throughout your release
process, allowing only certain organizations, either within your
company or externally, to access your app as it makes it's way to
public availability.
Allow only traffic from a specific service
Ensure that all the traffic to your App Engine app is first proxied through a specific service. For example, if you use a
third-party Web Application Firewall (WAF) to proxy requests directed
at your app, you can create firewall rules to deny all requests except
those that are forwarded from your WAF.
Block abusive IP addresses
While Google Cloud Platform has many mechanisms in place to prevent the various attacks, you can use the App Engine firewall as
another mechanism to block traffic to your app from IP addresses that
present malicious intent.
You should use the App Engine firewall as your primary option for
shielding your app from denial of service attacks or similar forms of
abuse. You can blacklist IP addresses or subnets so that requests
routed from those addresses and subnets are denied before it reaches
your App Engine app.
For details about creating rules and configuring your firewall, see
Controlling App Access with Firewalls.
The firewall appears to be intended to replace the DOS protection. From Denial of service (DoS) protection service:
Tip: You should instead use the App Engine firewall for reliable protection as well as the improved features, access, and
management through the Cloud Platform Console, gcloud command-line
tool, and Admin API.
You still need to collect the IP ranges for the country in your particular case, to configure the firewall.