Idea is to run this app either periodically or on every failed login attempt. If you run this app frequently (like every few seconds) app uses .state file to prevent running the app multiple times in parallel. If you run this app while it is already running, it will just schedule one more run and exit.

Above is the default behavior but you can change configuration to identify any desired set of requests from Firewall log or to modify Firewall rule that is being updated.See RequestFloodGuard.ini for more options...

You can ocasionally re-download .mmdb GeoIP databases but keep same file names:

https://db-ip.com/db/download/ip-to-asn-lite

	CraftSynth.RequestFloodGuard.1.0.zip (64.5 MB)
	CraftSynth.RequestFloodGuard.Code.1.0.zip (53.9 MB)

Hi, today I will show you how you can defend your server against brute force attacks and then present one application I wrote for for that purpose. If you leave your server open to the Internet long enough, eventually somebody will try to break in by trying different random passwords against your remote desktop account, so-called brute force attack. Practically they will create a loop and then try all possible combinations and. By default in Windows Server you don't see much information about what's going on, except that your server may become slow. And of course there is a risk that eventually they will succeed and guess your password. First step that you can do is to create some e-mail notification for the events when somebody actually enters your machine or disconnects from from your machine. That way you can at least control and review connections to your remote desktop. and for that you need to switch on these settings in group policy that will tell Windows to create log events for every such that will tell Windows to create event log for every such situation and you will get something like this sometimes it will show IP address of an attacker but sometimes not andIf you will receive a flood of such events, it's hard to make sense of them and it still does not protect you. You're still at risk that eventually they will succeed in guessing your password. So next thing you can do is to switch on account local policy. In case somebody types wrong password several times, it will disable your account for several minutes. And also a good idea is to uh also create a block event for that situation also we want emails to be sent and you can do that by creating a scheduled task something like this and called some script to send e-mail to administrator I also have one utility that I will share for that simple e-mail sending Next step is to switch on event log for invalid password attempt. This is important today because we will change other processes to be triggered by by this event. And as in earlier case, after setting this up and after somebody attempts wrong password, you will get an event. It will looks again something like this. Luckily here in. Event viewer you can right click and just attach task scheduler task to that event and for you I already found which event IDs you can use for the account lockout wrong password and and now by changing those actions you can get your e-mail notifications in case of wrong password and the account lockout. But as I said, this still does not protect you from attackers actually using your login screen, logging your account. And once somebody locks your account, then even you will not be able to to access it. So it's not the best solution. Ideally, we want to prevent attackers earlier before even they access your login screen. And we can do something like that with Windows Firewall. By default, Windows Firewall will not protect you nor identify a flood of requests. You first need to switch on logging in your firewall and it will start writing into these files. But if you take a look in these log files, there will indeed be every request, every access to your server written. However, because there will be too many of them, it will be hard for you to make sense of them. And especially if your machine becomes slow and if your account gets locked out, it will be hard for you to even access this file. So ideal solution would be to automate identification of request flooding in those logs and then automatically create a firewall rule that will block requests. And just for that, I wrote one Python application that will, when run, feed these logs into the database and query that database by. The query we specified earlier and identify such groups of malicious requests and finally for IPS. From where these requests are coming from, it will create a firewall rule to block those requests. Let me show you that. So this query gets executed. We can see IPS from where the requests are coming from. We can see the number of times. Request came from that IP and for every IP we can see country, city, coordinates and some information about the Internet service provider for that IP. And it will then check whether the firewall rule exists or not. If it's found, it will go straight to the remote IP addresses that should be banned and it will add IP's. listed here to that firewall block rule. Finally it will send the e-mail notification. Practically showing what can be seen here on the screen. Let me show you how you can configure this application to better suit your needs. Here is the main query and the important part here is the port for which you are collecting IPs and alsoIn this example, we have subnetworks specified as well as some IPs for which we are sure that will never come from attacker, particularly local hosts. So you can add exceptions in that query as well. And the important thing is to decide how many requests will be needed for IP to be identified as an attacker's IP. It is a SQLite database and You should write query that files syntax for SQLite. These are the all fields that you can use, but important fields that should be returned by select queries is this one because later by that field we will add some IP information and of course this field will be used for blocking attackers. This is IP and here we specify the location for Windows Firewall box. This is default location. Now, this application is meant to be run either periodically or on every failed password attempt. If you run this application periodically, then, of course, it makes no sense to check some requests from earlier, some requests that you already processed. And by this field, you can limit your query to work only against recent requests. Practically, it will add additional filter in the final query. And anotherway to use this application is to run it every time password attempt failed. For that to work, you would need to set up-- uh you would need to call this application on such event, number 4776, and it is recommended to also use these settings. Now these password attempts happen frequently. Because they are automated and this application will handle frequent calling. If you call this application while it's still executing, it will allow running only one instance. But if you do so, it will schedule another run after the current run has been executed. So if you call it several times within 5 seconds, it will execute. And after last call, after 50 seconds, one more run will be executed so that every request gets processed. I will show you this. As you can see, this state file has been created and it controls parallel execution. Very simple one. Later you could improve script to use mutex or some other locking mechanism. And besides this configuration file, there is a log file that probably shows everything you saw on the screen. This database is the file where these logs are loaded every time and if it is not needed, it can be deleted. And these are local databases for GeoIP. I provided links from where you can occasionally download the latest. Just make sure that you name them same as their name here. Also, if you call this application with show parameter, it will just run query. This can help you debug or you can manually identify attackers.