I've been through most of the free/affordable answers on this page as well as searching elsewhere [for days, including reading the Event logs mentioned by Andy Bichler] and here's an alternate free RDP monitoring and blocking tool:
//www.tweaking.com/content/page/remote_desktop_ip_monitor_blocker.html
I haven't tested it extensively, but downloaded and scanned it [the portable version] and although the UI is a bit on the ugly side, it's working on a 2012 R2 server without issue thus far. It's "hands on," but a no-brainer as well and beats deciphering the event logs.
There is also ts_block which allows you to automatically block IPs that are brute forcing your server's RDP [which I'm guessing would have some log of RDP attempts]:
//github.com/EvanAnderson/ts_block
As you can see in that link, the author is a serverfault user. I have not tested it as it's basically a vbscript that I would need to dissect before using. But, it seems promising.
The problem with the event logs mentioned by Andy above is that they are not very clear or descriptive as to who's doing what... at least in a malicious sense. You can find IP Addresses, but then it's hard to tell if they are related to all the unsuccessful login attempts. So, another tool other than the inherent logs seems almost mandatory if you're server is internet facing and you have any concerns about security.
Q: Is there a way to look at all the previous connections to my Remote Desktop Services Gateway?
A: Each connection via Remote Desktop Services [RDS] Gateway will result in a number of logs in \Applications and Services Logs\Microsoft\Windows\TerminalServices-Gateway\Operational. A 302 log is generated at connection time; the most interesting log is 303—which shows details of the connection, including the amount of data transferred, the duration of the connection, and the protocol used. Collecting the 303 logs is a good way to gain insight. The following is an example of a 303 log.
Log Name: Microsoft-Windows-TerminalServices-Gateway/Operational Source: Microsoft-Windows-TerminalServices-Gateway Date: 1/23/2014 12:35:46 PM Event ID: 303 Task Category: [3] Level: Information Keywords: [16777216] User: NETWORK SERVICE Computer: savdalrdsgw Description: The user "SAVILLTECH\Administrator", on client computer "x.x.x.x", disconnected from the following network resource: "savdalrds01". Before the user disconnected, the client transferred 1394115 bytes and received 22817836 bytes. The client session duration was 1779 seconds. Connection protocol used: "HTTP".Behind the scenes in Windows Server 2012 are multiple connections [two UDP and two HTTP—which are reported as one]. The HTTP connection gives you the correct data because it's the first connection created and is present throughout the entire connection.
2021-08-13
We often want to audit user logins from Remote Desktop Gateway to see what kind of activity a particular user has when connecting to remote terminal servers.
The simplest way is to execute the following powershell script on the RD Gateway server[s]:
[Get-WinEvent -FilterHashTable @{LogName='Microsoft-Windows-TerminalServices-Gateway/Operational';ID='302'} | Select-Object -Property TimeCreated,Message] -match '[USERNAME YOU ARE LOOKINGFOR]' | Format-Table -AutoSize
This will search the Event log at Microsoft/Windows TerminalServices/Gateway/Opertional for Event ID 302 [login], then will run a match for the username you specify.
The output will show the time as well as the public IP of the user that connected!
By using Remote Desktop Gateway Manager, you can specify the types of events that you want to monitor, such as unsuccessful or successful connection attempts to internal network resources [computers] through an RD Gateway server.
When these events occur, you can monitor the corresponding events by using Windows Event Viewer. RD Gateway server events are stored in Event Viewer under Application and Services Logs\Microsoft\Windows\Terminal Services-Gateway\.
Membership in the local Administrators group, or equivalent, on the RD Gateway server that you plan to configure, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at //go.microsoft.com/fwlink/?LinkId=83477.
| To specify Remote Desktop Gateway events to log |
-
On the RD Gateway server, open Remote Desktop Gateway Manager. To open Remote Desktop Gateway Manager, click Start, point to Administrative Tools, point to Remote Desktop Services, and then click Remote Desktop Gateway Manager.
In the Remote Desktop Gateway Manager console tree, right-click the local RD Gateway server, and then click Properties.
On the Auditing tab, select or clear the appropriate check boxes to specify the events that you want to monitor for RD Gateway.
Click OK.
hi,
there is nothing there but i have found it in the accounting log file.
i have discovered that the network policy in question is not working well.
i have configured a "client access ipv4" condition and that condition is failing to work.
as i said, i can see in the rdg monitoring after a successful connection the ip that is used and it is the ip address that i have configured to evaluate however, the condition in question is not working and it is blocking the connection.
i couldn't find any mentioning to the ip address in the accounting log file nor the event viewer so i can not know which ip address is presented during the evaluation stage.
asked • May 10, '21 | JohnReam-2643 answered • Sep 22, '21
Hi, so I have a Server 2019 DC RD Gateway Server in production that seems to be having some issues with logging anything that is being audited by the RD Gateway Manager. For example, I have turned on all the auditing options within the RD Gateway manager and I can see the traffic coming in via the 'monitoring' tab. However, those sessions are not being logged by event viewer under 'TerminalServices-Gateway' in Event Viewer. I should mention that this is a brand new build and the old Gateway was simply migrated over to this one as an upgrade path from Server 2016 to Server 2019. Any assistance on this would be great.
Comment