I want to secure admin panel of ecommerce website such that only trusted users get to access the login page. To avoid any malicious attempts like bruteforce etc.
Storefront and admin panel are hosted on different domains. Complete stack is hosted on AWS. Possible solutions I can think of are:
Using fixed static IP address is a possible solution but many of our employees access panel from mobile devices outside office, and many from different cities while on travel.
Employing WAF to restrict login attempts etc. can be employed. But again, possibilities are there for a non trusted user to hack into with dedicated efforts.
I am looking for some way with which any url including login page becomes inaccessible for non trusted users without using IP blocking strategy.
If you need tight security, these are my points for you.
make the admin website to a private website and make it available only via VPN.
use WAF to guard the website from malicious attacks
as #Daniel mentioned, adding multi factor authentication(MFA) is the best way to secure it further.
to make a website private via VPN, You can,
deploy the website instances and the load balancer on private subnets
setup a open vpn instance on a public instance
Setup open vpn login credentials for each admin
Hope this helps
two factor authentication with TOTP (note that NIST recommends against SMS strongly, and the rest of the industry should too) is probably the best way to do this without imposing undue burdens on the users. AWS ALBs can do some cool things with authentication these days (from cognito OIDC to full on AWS-style request authorization with signatures) , but none of those things amount to more than a password login.
While the VPN solutions are good, the common approach to what you're describing is a client certificate. Each user is issued a client cert which they store on their machine(s). An approved cert is required to access the page. This is also commonly called "mutual authentication."
Related
I'm running a backend app with several endpoints on Cloud Run(fully-managed). My endpoints are publicly available by its nature so I don't want to authenticate users through my client app hosted on Netlify.
What I do need is to restrict access to my endpoints so that other applications or malicious users can't abuse it. It is not about scaling, I just don't want to exceed the Free Tier limits since it is a demo of an opensource application.
I've already set the concurrency and max instance limits to minimum but this alone is not enough. There is also a product named Google Cloud Armor but it seems an expensive one, not free.
I was expecting to have a simple built-in solution for this but couldn't find it.
What other solutions do I have? How can I block the traffic coming out of my website on Netlify?
You don't have a lot of solution:
You don't want to authenticate your users -> so you need to rely on the technical layers
Netlify is a serverless hosting platform, you don't manage servers/IPs -> So you need to rely on the host name
To filter on the host name, you can use 2 products
External HTTPS only (about $15 per month) with url path matching.
Default URL land on a dummy service
Only request where the host matches your netlify host name are redirected to your backend
Use Cloud Armor on top of External HTTPS load balancer ($15 + Cloud Armor policy x traffic volume). The time, the load balancer redirect the default URL to the correct backend and Cloud Armor check the request origin.
The problem is that this weak solution is easy to overpass. Perform a simple curl with the host as header, and HTTPS Load Balancer and Cloud Armor think that is the correct origin
curl -H 'Host: myNetlifyHost.com' ....
The highest protection is the authentication. Google Cloud itself say: "Don't trust the network".
On AWS, our EC2 container hosts an app that runs both a backend and frontend server. The frontend server is our customer facing app that we want open to the public, and our backend server hosts the admin panel that should be accessible from the web by ONLY the admins and devs.
Normally, we could just create a security group to filter who can access the app. However, doing this would also block users from accessing the frontend app.
We're looking for a solution that can distinguish not only the IP of the user, but also takes into account whether they are trying to access the frontend URL or the backend URL.
Any suggestions? Thanks!
This logic is taking the decision from network layer protection to the application layer instead, you're trying to prevent access based on the URI so features like security groups or NACLs would not work.
Instead the approach to take would be to use a WAF as a protective layer in front of your application.
To do this you would add the developers IPs to an IPSet then apply ordering through a rule group to always allow the request if it comes from these IPs. After this the second rule would evaluate the path of the request and block if it matches a particular pattern. Finally all other requests would be allowed.
The WAF would need to be attached to either an Application Load Balancer or CloudFront as it cannot be directly attached to an EC2 instance.
I have a backend service, which I don't want to be expose, and also, just the employees that uses Gsuite oAuth should access.
Instead of exposing the backend and add the logic of oauth in it, I looked at the vouch-proxy project, which fits me very well (a proxy that redirects unauthenticated traffic to oauth login page and then, when a valid token is passed, it's redirect to the backend.
Before using this vouch proxy, do GCP has something built-in for it? Or another kind of setup that my backend service is not exposed?
Google Cloud provides the Identity-Aware Proxy (IAP) that would precisely fit your needs since it's integrating well with G Suite domain and can sit in front of your Load-Balancer.
tldr: See bold generic questions below.
I have built the infrastructure outlined below(in attachment) in AWS. OAuth specifies an auth server which issues tokens(Authorizes) and then authenticates tokens on each request and allows a proxy to the internal ALB.
It's based on a micro-services architecture and uses oauth to issue tokens and authenticate them from the client apps. The client apps could be apps inside the VPC or apps external to the VPC. As you can see I want all requests to go through OAuth server before they get to the internal ALB. Now the different types of apps should use different types of grants to get an access tokens. Those access tokens will contain a scope which relates to the routes(API endpoints) of the internal ALB.
Now I have a few questions which I hope are as succinct as possible:
AWS VPC ALB Questions
What is the most secure way of insuring that only the oauth apps communicate with the internal ALB and not other apps in the public subnet? So we can be sure that all requests to the internal ALB are authenticated? Do I have to somehow attach a new oauth only subnet to the input of internal ALB but how do I restrict the internal ALBs input?
To the same end, how do I ensure apps in the same subnet do not communicate with each other? Basically, how do I ensure that no internal apps communicate with each other and must be passed all the way to the external load balancer and therefore to oauth from the private subnet.
Route 53 SLL termination ALB
Does SSL termination on certain port stop traffic directed from different domains. If I make a call to ALB port 433 from internal ALB with SSL termination do I have to call from the host(route53 something.com) specified by the certificate or can I use the DNS hostname of the ALB(something.elb.amozonaws.com) resolved by AWS ok?
Scopes and OAuth
How to compare each request's url and it's token with oauth scopes? I want to relate oauth scopes to api endpoints. So each request goes to a route endpoint with an access_token which contains scopes. This scope will have to be compared with the request url on each request to make sure it’s allowed. Does oauth come with this functionality? I would guess not. However whats the point of scopes if this is not the case? Seems like scope is just an array I need to do some processing on after authentication rather than it being special in oauth. I’m probably missing something :-).
This post is too long already so I can’t for obvious reasons get into all the details but if you would like more detail I would of course give them. Even a help in the right direction would be useful at this point.
Thanks in advance.
Can someone help me with my understanding?
So i understand how one can use ADFS and SAML to provide SSO access to the Console via IAM. However im not as clear how this can be done at the application level
So take MS Dynamics as an example. It will be on an EC2 instance which is on a domain controller hosted in the VPC (for mgt etc). However the users themselves will be in an on-prem AD server and we'd want to authenticate users accessing the dynamics web front end with that on-prem AD server. Is this as simple as setting up ADFS between the two sites and configuring the app itself to use ADFS / SAML for claims based authentication?
For application level support, it depends on the ability of the app to support claims based/SAML authentication. CRM supports ADFS configuration. You have one of 2 choices
You can hook it up directly to your on-premises ADFS if it is really about just providing access to your corporate employees. If it requires partner access that ADFS can still federate to other ADFS/IDP organizations.
You can set one up in AWS next to or on the DC that it has and treat it as a Federation Provider and then set up trust to the corporate ADFS where the users live.
I'd recommend #1 as it is simpler. Go with #2 only if you are operating this as a different company or you are building multiple server apps in this AWS site that require local ADFS for things like server to server communication.
Thanks
//Sam