I have a small server on Azure (Windows 10 pro). There is only one service (webservice REST) on this server and it's not critical: if the service is down for a few hours or even days or if someone stole the data that's not a big deal.
I'm the only person that have access to this server, I have a quite strong password with a custom admin user name so I just use "RDP" to manage the server without VPN. A few days ago I saw that my Azure bill was higher than usually (more or less +10USD). I see that it was because of a higher "data transfer out". So I'm try to understand the reason.
I saw that:
in my web server access and error log (Apache) there is about 80 connections that were blocked (http code 400/403).
in my web service log (custom log) I haven't any request (blocked by Apache that require a valid user and password)
in my Windows security events logs that's more complicated: I have about 31'000 "audit failure". I see that it's a kind of brute force attack probably through the rdp port (login events with differents accounts names). I haven't seen any successful attempts. So in my opinion it's because of this brute force attack that my bill is higher.
So my question is: could you help me to evaluate how many data transfer those 31'000 connection through RDP could represent ? Are there other elements that I should take into consideration ?
In order to avoid that kind of things I'll try to install a VPN. For now I just allow my IP adress through RDP in Azure portal.
Thank you for your help
Loic
For this, you can block all port incoming ports except RDP one ie 3389. (Also you can restrict for your Public IP to use them.
Blocking unused ports is always the best option.
try wail2ban used long back to protect Bruteforce attack.
I would recommend activating the just-in-time access feature in Azure.
This feature protects your management ports from attacks and it's a good option if you do not want to spend more money on a Azure App Gateway or Azure Bastion.
https://learn.microsoft.com/en-us/azure/defender-for-cloud/just-in-time-access-usage?tabs=jit-config-asc%2Cjit-request-asc
Related
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 currently performing a research on cloud computing. I do this for a company that works with highly private data, and so I'm thinking of this scenario:
A hybrid cloud where the database is still in-house. The application itself could be in the cloud because once a month it can get really busy, so there's definitely some scaling profit to gain. I wonder how security for this would exactly work.
A customer would visit the website (which would be in the cloud) through a secure connection. This means that the data will be passed forward to the cloud website encrypted. From there the data must eventually go to the database but... how is that possible?
Because the database server in-house doesn't know how to handle the already encrypted data (I think?). The database server in-house is not a part of the certificate that has been set up with the customer and the web application. Am I right or am I overseeing something? I'm not an expert on certificates and encryption.
Also, another question: If this could work out, and the data would be encrypted all the time, is it safe to put this in a public cloud environment? or should still a private cloud be used?
Thanks a lot!! in advance!!
Kind regards,
Rens
The secure connection between the application server and the database server should be fully transparent from the applications point of view. A VPN connection can connect the cloud instance that your application is running on with the onsite database, allowing an administrator to simply define a datasource using the database server's ip address.
Of course this does create a security issue when the cloud instance gets compromised.
Both systems can live separately and communicate with each other through a message bus. The web site can publish events for the internal system (or any party) to pick up and the internal system can publish events as well that the web site can process.
This way the web site doesn't need access to the internal database and the internal application doesn't have to share more information than is strictly necessary.
By publishing those events on a transactional message queue (such as MSMQ) you can make sure messages are never lost and you can configure transport level security and message level security to ensure that others aren’t tampering messages.
The internal database will not get compromised once a secured connection is established with the static Mac ID of the user accessing the database. The administrator can provides access to a Mac id through one time approval and add the user to his windows console.
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.