Thursday, April 20, 2023

issues with a Windows server running a dot net app and mitigation

Copy-pasting my response to a message,  

server seems to be down again. It is happening quite frequently since yesterday....

I see two types of attacks on the server. Both are likely to be by automated bots, since such attacks are very common.

1. Remote Desktop

Attack
The remote desktop service (RDP, termservice) is being attacked. If a sufficiently large number of connections take place, the server will run out of memory, and other services will also start failing.




Mitigation
We can prevent these by simply stopping the remote desktop service when not in use. For this, please run the stoprdp.bat via SSH, logging in with putty etc, whenever you start RDP with restartrdp.bat, after you finish your work on the server. I have run stoprdp.bat now.

2. Attacks on the database via dotNET api

There are attacks on the database / dotNET app using the API exposed by the dotNET application. In the screenshots below (redacted in this blog post), you can see how multiple API controller endpoints are being targeted in a short time, with the database quickly reaching maximum retries.


Edit - adding another screenshot from another day - 
 



Mitigation

Assuming that these are not some tests being done by your team, we will need to

(a) check if the dot net app code-base is secured against all the usual attack vectors mentioned at
In particular, exception handling via try-catch should be checked.

(b) add some sort of Denial of Service attack prevention, similar to
https://www.madskristensen.net/blog/block-dos-attacks-easily-in-aspnet/
Please note - directly using the code in the link above would not be safe, since our web app is much more complex.


Another one is


(c) Prevent direct access to the API on our server, and allow ONLY access through Cloudflare.
This is supposed to mitigate many types of attacks.
 
I've now implemented blocking of all external requests on HTTP and HTTPS on the Sainin production server except via cloudflare's ip addresses
 
For this, just had to copy-paste the ipv4 addresses from the list above, make them comma-separated, and paste them into a newly created inbound security rule in Azure portal for the nsg (network security group) of the server in question. And, of course, make sure that the relevant services' DNS records are proxied through cloudflare and not "DNS only".
 


 

No comments:

Post a Comment