Is RDS-Knight with Brute-Force Attacks Defender useless with HTML5Service ?

[Alpin]

Hello,

We are testing RDS-Knigt but Brute-Force Attacks Defender is not functionnal because the IP source (when we use HTML5 solution) is 127.0.0.1 and not the public IP from the attacker.

Then RDS-Knight with Brute-Force Attacks Defender enabled can not defend HTML5Service.


Are you agreee with that ?

Best regards,

[admin]

Hello,

RDS Knight has no effect for HTML5 connections, logging being done on the server itself (so IP source 127.0.0.1, that it would be annoying To block).

For other connection modes (mstsc, client generated, RemoteApp web client) RDS Knight works correctly, provided that the Windows logs include the source IP address.
The Windows logs used by RDP Knight are :
Log ID 4625 present in the security log.
Log ID 140 present in Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational

There is always a log 4625, but the IP address is not always there, if SSL connection method is used.
There is not always a log 140, because it is only present on the most recent version of Windows. If this log is present, the IP address will always be there. If this log is not present and the log 4625 does not display the IP address, the solution is to disable the SSL for RDP.

The GPO below can also be set to allow these logs to be present :
You must then modify the following GPO: "Computer Configuration \ Windows Settings \ Security Settings \ Local settings \ Security Options": "Network security: Restrict NTLM: Incoming NTLM traffic" and set it to : Deny all accounts".

[bbogedin]

Hello,

RDS Knight has no effect for HTML5 connections, logging being done on the server itself (so IP source 127.0.0.1, that it would be annoying To block).

For other connection modes (mstsc, client generated, RemoteApp web client) RDS Knight works correctly, provided that the Windows logs include the source IP address.
The Windows logs used by RDP Knight are :
Log ID 4625 present in the security log.
Log ID 140 present in Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational

There is always a log 4625, but the IP address is not always there, if SSL connection method is used.
There is not always a log 140, because it is only present on the most recent version of Windows. If this log is present, the IP address will always be there. If this log is not present and the log 4625 does not display the IP address, the solution is to disable the SSL for RDP.

The GPO below can also be set to allow these logs to be present :
You must then modify the following GPO: "Computer Configuration \ Windows Settings \ Security Settings \ Local settings \ Security Options": "Network security: Restrict NTLM: Incoming NTLM traffic" and set it to : Deny all accounts".

So how do we block brute force attacks from the HTML5 interface?... Why can't that be part of the solution with TSPlus?

[bbogedin]

Hello,

We are testing RDS-Knigt but Brute-Force Attacks Defender is not functionnal because the IP source (when we use HTML5 solution) is 127.0.0.1 and not the public IP from the attacker.

Then RDS-Knight with Brute-Force Attacks Defender enabled can not defend HTML5Service.


Are you agreee with that ?

Best regards,

I found a buried knowledge article where you can adjust the default portal lockout feature from brute force attacks.

https://support.tsplus.net/support/solu ... ut-feature

I also found another knowledge article to help harden the server against these attacks from a GPO.

https://support.tsplus.net/support/solu ... om-80-443-

Hope that helps you as well.

[bbogedin]

@Admin

On second thought re-reading it only protects brute force attempts if they know the account and it locks out the account. I am looking for something that blocks by IP by failed attempts only regardless if its the right account they are trying to brute force or not.

Why can't the HTML5 client also grab the IP address of the originator and block them at the web server level versus just forwarding every request to the RDP authenticator at localhost?

[adrien]

Why can't the HTML5 client also grab the IP address of the originator and block them at the web server level versus just forwarding every request to the RDP authenticator at localhost?

It does.
Please send us an email to support@tsplus.net with an access to your server and we will investigate why it is not working on your side.

Before that, please make sure that:
- you are using RDS-Knight latest version (currently 3.6)
- the file "C:\Program Files (x86)\TSplus\Clients\webserver\settings.bin" contains a line

Code: Select all

log_rdp_ip="1mb"

. If not, add it, save the file and restart TSplus webserver.

Thank you!

[bbogedin]

Why can't the HTML5 client also grab the IP address of the originator and block them at the web server level versus just forwarding every request to the RDP authenticator at localhost?

It does.
Please send us an email to support@tsplus.net with an access to your server and we will investigate why it is not working on your side.

Before that, please make sure that:
- you are using RDS-Knight latest version (currently 3.6)
- the file "C:\Program Files (x86)\TSplus\Clients\webserver\settings.bin" contains a line

Code: Select all

log_rdp_ip="1mb"

. If not, add it, save the file and restart TSplus webserver.

Thank you!

But you just said above that the RDSKnight does not work with HTML5 in your reply to OP.

"RDS Knight has no effect for HTML5 connections, logging being done on the server itself (so IP source 127.0.0.1, that it would be annoying To block)."

[TSPlusSMD]

I just went through this on a ticket a couple days ago and am still not really warm and fuzzy about the answer. I was told that RDS-Knight should translate 127.0.0.1 to the actual IP address. I was also told to put that in the settings.bin but it was already there.

I was also told that you shouldn't really see 127.0.0.1 in the log unless it was from something else other than a HTML5 login. All of a sudden 127.0.0.1 quit showing up in the log. Still don't understand it and am still very confused about the answers I was given.

I would like to see a clear, concise response to two thins. 1) Should you see 127.0.0.1 in the RDS-Knight logs and 2) Is HTML5 protected from Brute Force and Homeland, Working Hours or any combination thereof?

[bbogedin]

I just went through this on a ticket a couple days ago and am still not really warm and fuzzy about the answer. I was told that RDS-Knight should translate 127.0.0.1 to the actual IP address. I was also told to put that in the settings.bin but it was already there.

I was also told that you shouldn't really see 127.0.0.1 in the log unless it was from something else other than a HTML5 login. All of a sudden 127.0.0.1 quit showing up in the log. Still don't understand it and am still very confused about the answers I was given.

I would like to see a clear, concise response to two thins. 1) Should you see 127.0.0.1 in the RDS-Knight logs and 2) Is HTML5 protected from Brute Force and Homeland, Working Hours or any combination thereof?

I have current ticket open for a few days but no response. I tested it and so far I've seen it doesn't work. I went to another PC outside of the local network where TSPlus and RDS is installed on and attempted to mislogin a bunch of times to both accounts that exist and don't exist. In RDS knight have it set to ban after 4 failed attempts for 24 hours but it doesn't. Looking at the Security Events it shows at ::11 or 127.0 failed logins but can't ban since its local.

So RDS is pretty much useless for internet facing HTML5 logins. Not worth buying unless they come up with a fix..

In TSplus client session panel you can see the clients logging in and their remote IP's.. so not sure why RDS can't see it? Also I don't think it should have to be a separate product at all. This should be a web server feature built in and included with TSPLUS and not a separate product. The other features I can understand ... but not this one.

[TSPlusSMD]

Support on RDS-Knights is at best spotty. I had a remote session with support where he showed me that it was translating 127.0.0.1 to the real IP address but he never explained why the log didn't reflect the real IP address. I agree that not protecting the server via HTML5 make the product useless. They need to come clean on these issues and respond......