I started a web server on EC2 following the basic instruction on AWS website. The web page (index.html) since yesterday is not accessible through the browser (chrome & edge) but is accessible from my mobile. I have not made any changes to my desktop settings which should affect this.
Any pointers on how to investigate this would be great?
Check your security groups and access control lists to confirm that you have not accidently allowed traffic to the page only from certain ip address/addresses.
Related
We currently have a large array of customers (1000 different on-premises installations).
We use a single server to host our sites which communicates with on-premises WebAPI's.
Currently we limit the traffic to the local servers in the router to allow only our server to access the local API's.
However we are considering moving alot of these webservices/sites to Azure which in turn means limiting on the IP's addresses becomes not feasible.
What approach would you recommend to allow the Azure servers to access the on-premises servers?
Best case scenario would of course be that no ports needed to be open in the routers (limit maintenance) however this seems very hard to accomplish if we still would like the ease of development that WebAPI gives us.
Otherwise we have thought about opening for public access to the API's but securing with https and authentication.
Does anyone have any alternative solutions?
Note: The on-premises WebAPI services are hosted with selfhost inside a Windows Service.
You could try using 'Azure Hybrid Connections' to access your on-premises Web API.
You could host your websites as 'Web Apps' in Azure App service and access your Web API.
You do not need to open any firewall ports or change your network perimeter configuration to allow any inbound connectivity into your network
I have a web app and a web service (which will be uploaded to Azure as an web app). How can i make my web service private (not accessible to the public, only accessible by the web app). Apparently you're able to do it with an App Service Environment but there isn't much documentation on it.
Is it possible?
You can follow this article to set it up: https://azure.microsoft.com/en-us/documentation/articles/app-service-web-how-to-create-an-app-service-environment/
The main difference between App Service and App Service Environment (ASE) is that App Services run on a pre-built, shared tenant hyper scaled web farm, but ASEs are purpose built (on demand) web farms provisioned directly in your subscription that must be attached to a VNET. Because you can attach your ASE to a VNET, you can then apply Network Security Groups (NSG) to the VNET to prevent/allow traffic to flow to the ASE.
Here is the page describing how to add the layered security to your ASE once you've built it:
Layered Security Architecture with App Service Environments
So with ASE you get the deployment/monitoring/management features of App Services, but with the network layer control of a VM.
How can i make my web service private (not accessible to the public, only accessible by the web app).
Network Security Groups could be used to control network traffic rules at the networking level, we could apply Network security group to the subnet to let Network security group act as a firewall in the cloud. #Russell Young has shared us a good article about setting up Network security group, you could read it. And you could check this blog that explained securing network access using Network Security Groups.
Besides, it is easy to implement a custom authentication to prevent unauthenticated client from accessing to your Web service at application layer. For example, we could use SOAP headers for authentication. Web service client credentials would be passed within the SOAP header of the SOAP message when the client want to access to Web service, and then Web service will validate SOAP header, if it contains the authentication credentials, the client will be authorized to access to the Web service.
You could check Implement Custom Authentication Using SOAP Headers.
We are working on an app whose Front-end has been decoupled from the back end.
We have 2 project packages. The first project package acts as the front-end for the app and interacts with the 2nd package which acts as the back-end via API.
Front-end is built with:
React
Redux
Back-end is built with:
ExpressJS
MongoDB
We have deployed the app successfully on the AWS EC2 instance but I am doubtful about the security inbound measure we have applied for the packages. Both the packages are deployed on the same ec2 instance.
The front end of the app can be accessed with https://xxx.xxx.x.xxx:8080. Under the security group, under inbound rules, I added the source as anywhere for port 8080 under the custom TCP rule.
I did the same for port 3000 reserved for the back-end API server and port 27017 reserved for MongoDB.
What I actually wanna do is only let the front-end package running on port 8080 talk to the API server and the API server in turn talks to MongoDB.
I do not want everyone to have access to the backend server and MongoDB except for the front-end app server.
Note that I have already used the JWT token to secure the API. This one is to add an extra layer of security.
How can I limit the access to only the Front-end app server?
Thanks in anticipation.
Sorry, are you accessing your MongoDB directly from the frontend? I hope no...
So you should configure firewall on your server (firewalld or iptables) to block Mongo and all other internal ports from access from web.
Is there a 'quick and dirty' way of funnelling calls to a web service via a certain IP address? Possibly in code (C#)?
I'm working on this Azure website (PaaS no VM) that's got it's own domain secured by SSL.
e.g. myapp.azurewebsites.net -> https://myapp.com
The system is using a 3rd party web service that uses whitelisted IPs for access control. Unfortunately they are not happy whitelisting the standard Azure egress IPs.
So what I need to do is find a way to call that web service via our own IP address (the one that came with the domain name package).
If possible, only that traffic, not all outgoing.
I've come across several solutions but I’d rather not want to compromise the stability of the production website by experimenting with App Service Environment.
I think the scenario being asked about is outbound calls from an app running on Azure App Service (aka Azure Websites), to an external endpoint.
In that scenario, the outbound calls from the web app are NAT'd using a pool of IP addresses allocated for the App Service scale unit that is running your app.
Using the "preview" portal (portal.azure.com), drill into the website blade for your app and click through "All settings" --> "Properties". In the properties blade that appears, there is a textbox called "OUTBOUND IP ADDRESSES". Those are the values you need to give to the third party provider to whitelist.
We have developed a RESTful Web Service which requires access to a Network share in order to read and write files. This is a public facing Web Service (running over SSL) which requires staff to log on using an assigned user name and password.
This web service will be running in a DMZ. It doesn't seem "right" to access a Network Share from a DMZ. I would venture a guess that the "secure" way to do this would be to provide another service inside the domain which only talks to our Web Service. That way, if anyone wanted to exploit it, they would have to find a way to do it via the Web Service, not through known system API's.
Is my solution "correct"? Is there a better way?
Notes:
the Web Service does not run under IIS.
the Web Service currently runs under an account with access to the Network Share and access to a SQL database.
the Web Service is intended only for designated staff, not the public.
I'm a developer, not an IT professional.
What about some kind of vpn to use the internal ressources? There are some pretty solutions for this, and opening network shares to the internet seems too big a risk to do.
That aside, when an attacker breaks into your DMZ host using those webservices, he can break into your internal server using the same API unless you can afford to create two complete different solutions.
When accessing the fileservers from the DMZ directly, you would limit theses connections using a firewall so even after breaking your DMZ Host the attacker cannot do "everything" but only read (write?) to those servers.
I would suggest #2