We integrate with a third-party service where we can run queries which is right now secured using HTTPS encryption and username/password. We send our queries from a service running on the Windows Azure cloud.
The third-party provider wants to migrate towards better security and they have asked us to either
Setup a VPN - which is problematic because for we'd need to use Azure Connect and they'd have to install the client endpoint service on their part.
Provide some IP address where the queries will come from so they can filter out anyone else at the firewall level - which is problematic because AFAIK you cannot fix the IP addresses of the Windows Azure Compute nodes.
Suggest another secure alternative - the only thing I could think of is to set up the VPN with them on a non-Azure server and then tunnel the requests through using Azure Connect - which is obviously extra work for us and also defeats the point of hosting the service on a cloud if it depends on a non-cloud service.
Any ideas?
Can they install the Azure Connect endpoint on another server on their DMZ network? i.e. not the actual server which hosts their service?
Can we somehow provide them with static IPs for incoming queries?
Any other solution that is scalable?
Thanks
If I understand the scenario correctly, your Azure service is a client to a 3rd party service. This scenario may be solved through the use of the Windows Azure AppFabric Service Bus. You would need to install a proxy app in the 3rd party's datacenter that would be responsible for establishing the connection to the service bus. The connection comes from inside the 3rd party's datacenter, so no new incoming holes in the firewall. The connection can handle WCF connections with all its security strengths, and users can be authenticated with ACS.
Here is a starting point: http://msdn.microsoft.com/en-us/library/ee732537.aspx
There is a hands on lab in the Windows Azure Platform Training Kit that explains most of the details that you'll need.
IMHO, HTTPS is already very good; and I don't exactly see how a VPN would make the system any more secure. In particular, VPN is no silver bullet, if your VM is compromised then the VPN connection is compromised too (same for HTTPS). On the other hand, the IP restriction would indeed reduce the attack surface.
Then, using a server outside the cloud is a poor idea indeed. Not only it defeats most of the benefits of the cloud (been there, done that and suffered a lot), but also it also makes the whole thing less secure with more complexity and more attack surface.
Windows Azure does not provide anything that look like a static IP at this point. In our experience, IP addresses for a given service change once in a while even if the service is only upgraded (and never deleted). Static IP addresses have been an important feature request for a long time, Microsoft will probably provide it at some point, but it might still take many months.
Related
I am creating a WebService with C# Core 3.0 that is using MySQL and Redis, but I am not so familiar with Azure so I need advice about configuring everything.
I had MySQL hosted on AWS, but I am transferring it to Azure because I think that performance (speed) will be better on Azure because they will be on same data center. Right?
But, on my MySQL page Host is like '*.mysql.database.azure.com'. That means that every connection will go out of Azure, and than come back? I don't have some local IP for connection? Same question for Redis.
Do I need to configure some local network on Azure and will that impact speed on the app? And, is MySQL a good choice for Azure or should I try with another one?
I am just reading about Azure Virtual Networks. But as I understand it, VN's sole purpose is to isolate elements from the outside network?
You will get better performance if your my-sql instance and your app service are in the same region (basically the same data centre).
The connection string is mysql.database.azure.com, but remember the connection will be a TCP/IP connection, so the DNS lookup will realise that this address mysql.database.azure.com is in the same region (same data center). Then the TCP/IP connection will go to an internal IP.
You could use tcpping in your app service's kudo console to try this and see the result.
The basic rule is that you should group your app and database in the same region for better performance and cheaper cost (as Microsoft doesn't charge traffic within the same region).
Azure Virtual network is for a different purpose. For example, if you have some on premise database servers and you want to call these servers from azure, then VM could be helpful. But for the scenario you described, it is not really needed.
The company I work for has Microsoft azure support included, and if you or your company have support contract with them, you can raise questions directly to them and get really quick responses.
I have a Django based web application hosted on Azure provisioned virtual machines (Ubuntu OS). My application recently experienced a DDoS attack and we were helpless against it.
The problem is that once traffic hits the server - even if it's blocked at a firewall or throttled in my webserver - the traffic is already consuming my network bandwidth. I can do nothing about it. This needs to be blocked "upstream", in the routing gear servicing my server.
Is there any DDoS protection Azure can offer me? Or at the very least, make recommendations as to how I might deploy my application so that it's more resistant to these attacks? Please advise.
Current, Azure provides DDOS protection at the network level, but not at the application level. So, if you are receiving a bunch of ACK requests, for example, this should be blocked by the platform itself.
For app level DDOS protection, you need to consider an upstream provider such as Incapsula or Silverline. Integrating them is quite easy. See https://www.incapsula.com/blog/how-to-add-incapsula-to-your-microsoft-azure-instance.html for an example.
Essentially, you will setup Incapsula and configure it with the DNS label of the web app (something.azurewebsites.net). Your DNS (www.domain.com) will then point to the incapsula service and they will handle the rest.
Please note that separating the DDOS from the service still allows for an attack against the service itself (ie: if someone hits something.azurewebsites.net then Incapsula will not protect this traffic).
Hope that helps!
First: Azure allows for IP-whitelisting (or blacklisting), so you can add malicious IP addresses to your block-list on incoming traffic (port 80/443 for instance). And you can modify IP addresses / ranges programmatically. This should prevent traffic from hitting your web app. Note: This is specific to Azure Virtual Machines, which you're using.
Second: Azure provides the Azure Security Center, which is designed to detect such things as DoS attacks, intrusion attacks, etc. Not that it solves your problem, but it can be used for alerting you to issues.
Using incapsula will be the right answer for you , since incapsula hides your origin ip and mitigate the attack before it even reached Azure.
in addition it provides CDN and cache which helped us save on bandwidth costs on AWS and make our application work faster.
I just created my first Azure SQL Server and Database and now am trying to configure the firewall so that my web application can connect and make changes to the single database on the server.
I see that you can allow all clients to connect by allowing a rule such:
However is this bad practice? I see my Client IP address is listed in the Azure portal can I get clarification that I should allow just that single IP address access for now, and then later when I publish my web application to Azure I will be given an IP address of where that web app lives and only restrict access to that (assuming that people can only make database changes through my front end application).
Thanks
Yes, this is bad practice. There are other layers they'd have to get through (e.g., the server login), but this opens the front door and allows anyone to pick away at it at their leisure.
If you have a web server hosting your web application on some server (which you must be), whitelist that server's IP address (and perhaps your own, for development/admin purposes), but allowing all IPs is not considered good practice, no.
One particular case where you may really want to allow this is if you are distributing a desktop application to unknown clients that must connect to the backend. It becomes extremely enticing at that point, but even so, the recommended practice (or at least, my recommended practice) would be to utilize a web service that will accept an application registration upon startup of the app, register the client IP temporarily through that, and then have a background server (think WebJobs) that will flush the firewall rules say, every night or so (or for a more elaborate setup, accept the registration with a timeout and use a continuous WebJob to poll for the timeout and refresh/revoke as necessary)
I have a mobile application that communicates with a REST based web-service. The web-service lives behind the firewall and talks to other systems. Currently this web-service requires a firewall port to be opened and a SSL cert generated for each installation. Mobile apps sends login credentials so web-services can login to custom back-end systems.
Recently a customer approached us asking how could we deploy this to 50 offices. As we don't want to say modify every firewall in every office, we're looking for options.. This is a list of possible solutions and my thoughts on each one:
Open firewall port and expose https webservice - This is our current
solution but we dont want to have to contact 50 network admins and explain why we need to do this.
VPN - Too heavy weight, complex and expensive, we only need access
to one server. Does not solve problem as firewall needs to be
modified.
Microsoft Azure Hybrid Connection Manager - This provides a managed
service where the Azure cloud will expose an end point. Azure will
also expect connections from a easy to install application that
lives behind the firewall. When a REST call is made to the cloud
end-point, the request is forward down socket that was initiated by
the software behind the firewall. This does what we want but as its
a Microsoft Solution there might impose other requirements that our
customers might not want. Currently the simple Hybrid Connection Manager is free. But for how long?
Jscape MFT Gateway - Similar to Azure but you can host their server anywhere. Not that expensive but is not opensource.
Netty - A async java library/toolkit where this type of application could easily be build. Client and server apps would need to be build and deployed. Dont know what we dont know about Netty.
MDM, AirWatch, BlackBerry BES - A MDM based solution would work expect that MDM's are centrally managed and are not often in every office where the backend services are located. Airwatch has an AppTunnle but im not sure about the specifics.
At this point the Microsoft and Jscape systems are possible solutions.
But most likely these solutions will require us to modify the mobile software to work around issues such as:
How does the user know which server to login to? A locator service
needs to be built such that, an email address is used to lookup their
office, or they need to select their office location from a list.
While the connection is SSL many company might want some additional protection since network login information will be send down the pipe.
How is load balancing and fail-over managed?
So, at this point i'm looking for more options. The best option would be a commercial product that offers some level of customization. Second, would like a well used open-source product that could be installed in Aws and customized.
Thanks
The best approach we found was to use the PUTTY API and setup a reverse proxy.
I'm using some hosted 2008R2 servers for testing scenarious in the Azures cloud and they seem to be working well for most things.
I need clients to directly access the server via VPN such that they have full IP access to the server, for, say, SMB NET USE drive mappings, which otherwise would not be available over the Internet.
Normally, you'd just install RRAS and configure VPN.
But on these VMs, the connection from a remote VPN client fails. I'm forwarding the correct endpoints (I believe), 47 & 1723 for PPTP and 50/51/500 for IPSEC. But they aren't getting through.
The server is listening on these ports.
All my searching seems to suggest you need to use "Azures connect" for VPN access, so does this mean you can't go direct to the server for clients? I don't want to go for the Azures Connect route as I'm just playing/testing and don't want to use any proprietory methods.
Confirmation that this is impossible would be useful to save me going mad.
Azure Connect is a very good way to start; it is an Azure service so I am not sure why you are reluctant to use it. I would keep an eye on performance; VPN could very well be faster. Here is my blog post on how Azure Connect works and the steps I took to make it work: http://geekswithblogs.net/hroggero/archive/2012/10/18/how-to-create-a-virtual-network-with-azure-connect.aspx
Regarding VPN, only certain devices are supported for the preview. Please refer to MSDN for a complete list of supported devices and protocol requirements: http://msdn.microsoft.com/en-us/library/windowsazure/jj156075.aspx