RDweb integration

Hi there,
great piece of software! Unfortunately I've noticed a sharp uptick in RDweb login attempts, and while these generate 4625 events, they do not contain a source IP - hence IPban is not informed about the attack.
I believe IIS is logging logins and IP addresses as well. Is there a known way to integrate IIS logs into IPban? Or any other way to make it shield RDweb?

Thank you!

[jjxtra]

Could piggy back off this recipe: https://github.com/DigitalRuby/IPBan/blob/master/Recipes/Windows/LogFile/IIS.xml

If you can post the log file names and some lines that show the failed logins, I can add to this recipe.

The log file names are u_ex230904,u_ex230905,u_ex230906,u_ex230907, etc, stored under C:\inetpub\logs\LogFiles\W3SVC1. A few sample lines: [masked server IP]
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2023-09-06 00:00:00 [server-IP] POST /RDWeb/Pages/en-US/login.aspx - 443 - 94.142.138.97 Mozilla/5.0+(Windows+NT+6.1;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/69.0.3386.127+Safari/537.36 - 200 0 0 268
2023-09-06 00:00:02 [server-IP] POST /RDWeb/Pages/en-US/login.aspx - 443 - 94.142.138.97 Mozilla/5.0+(Windows+NT+6.1;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/69.0.3386.127+Safari/537.36 - 200 0 0 250
2023-09-06 00:00:03 [server-IP] POST /RDWeb/Pages/en-US/login.aspx - 443 - 94.142.138.97 Mozilla/5.0+(Windows+NT+6.1;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/69.0.3386.127+Safari/537.36 - 200 0 0 282

Notice that the cs-username field is empty, and that seems to be for all failed logins. For successful logins the cs-method changes to 'GET' instead of 'POST'.

Is this helpful? Sorry, I'm new to web stuff.

[jjxtra]

No file extensions? I can try to make a recipe.

Ugh, sorry about that. These are .log files.

…

On Thu, Sep 7, 2023 at 9:49 AM Jeff Johnson ***@***.***> wrote: No file extensions? I can try to make a recipe. — Reply to this email directly, view it on GitHub <#271 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQYULG52NBZ77KCBPYD4NDDXZH3IBANCNFSM6AAAAAA4PDZIVE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Ronald Ratzlaff IT Specialist Van Belle Nursery Inc <https://www.credly.com/badges/af5af6a7-e591-40f1-ad53-557161b4b95c/public_url>[image: CWNA) Certified Wireless Network Administrator | Networking Certifications & Training] <https://certified.certitrek.com/977f693e-ed61-4d55-a7b9-49eafecaabea>

Did some more digging with the help of a friend who has more experience. The 'GET' or 'POST' part is irrelevant. Here are two examples of log lines, the first of a successful login, the second of an unsuccessful attempt:

2023-09-07 16:10:21 [server-IP] POST /RDWeb/Pages/en-US/login.aspx - 443 [username] 184.68.23.229 Mozilla/5.0+(Windows+NT+6.1;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/69.0.3386.127+Safari/537.36 [redirect-URL] 302 0 0 138
2023-09-07 16:27:24 [server-IP] POST /RDWeb/Pages/en-US/login.aspx - 443 - 184.68.23.229 Mozilla/5.0+(Windows+NT+6.1;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/69.0.3386.127+Safari/537.36 [redirect-URL]/ 200 0 0 53

The difference is that the first contains a username and ends in a redirect, whereas the unusccessful attempt contains no username, and no redirect. Although these lines both contain a URL at the end. The lines I see from the attackers have none.

I hope this is of more help.

[jjxtra]

I will conjure a recipe. Post back soon.

Thank you very much!

[jjxtra]

Username is in brackets or no?

nope, no brackets

[jjxtra]

Here is the recipe @LontzroV : https://github.com/DigitalRuby/IPBan/blob/master/Recipes/Windows/LogFile/IIS_RDWeb.xml

Will your log file also contain lines that are neither a successful or failed login?

Let me know how it goes. Happy to tweak if needed.

This is great! However a couple of items to tweak:

1. The IP address matched by the regex is the wrong one. Sorry for not having clarified that more precisely. [server-address] is the local address. What we're wanting to block is the client IP address. We tweaked the regex land it worked. Unfortunately when I paste the regex in here it swallows the IPaddress string. Basically, the IP address needs to be moved further to the right in the line, befre these last characters: \s[^\s]+\s[^\s]+\s2. In case of a successful login, it is located right after the username.

2. Under some circumstances it matches a minus sign as a username, thus deeming the attempt successful when in fact it was not. So username should be limited in some way. At least excluding the minus sign (this is the logs equivalent for blank)

3. Reintroducing the POST vs GET actually makes sense after all. All GET messages can be ignored, as all failed and successful attempts will include a POST message as in the example.

[jjxtra]

Recipe updated, let me know if it's any better

Points 1 and 3 are addressed, but it still matches a minus sign ( - ) as username for some log lines, even though it is not a successfull login attempt. That could be an issue if it clears the attackers login counter.