RDP Firewall
|
|
|
|
|
The built-in RDP Firewall of your AADS Terminal Server is not a replacement of the Windows Firewall. It is not a replacement for anti-virus software or security-software in general.
The built-in AADS RDP Firewall gives you protection, specifically and focussed on RDP connections, sessions, and logon's. Improper RDP sessions, failed logons, hack attempts thru a RDP session, will be detected, logged, and handled by the built-in AADS RDP Firewall. These type of "attacks" are not handled by anti-virus software or security-software in general. And now that you are using an AADS Terminal Server and therefore are running a Terminal Server, you will need the protection for Terminal Servers: the AADS built-in RDP Firewall. The AADS RDP Firewall is one of the reasons why AADS is a better solution then default MS Terminal Server, Citrix or others.
Other "typical" security problems like viruses, are not handled by the built-in AADS RDP Firewall. Therefore the usual recommendations do still apply:
Default the built-in RDP Firewall is enabled and has the following settings:
AADS Terminal Server can handle both IPv4 and IPv6 traffic.
You can change the default port number which is used by the AADS Terminal Server for listening for Remote Desktop Sessions.
The range of the custom value is 1000 – 65534. Although a number lower then 1000 might be technical possible, this is disabled in order to prevent problems.
If you change the port number to another value:
A reboot is required before the new port number is used by AADS Terminal Server.
Don't be tempted to disable the AADS built-in Firewall. Too often we receive ZIP Support Files with loglines indicating many hack-attempts because of a disabled AADS RDP Firewall or no Firewall at all. This also applies to local networks. If one (or more) of the Client PCs are hacked, infected, the virus on the Client PCs may attempt to login on the AADServer and is doing many RDP-logins. Regularly we receive ZIP Support Files with these type of problem...
No firewall is not acceptable, because then to many hack-attempts are happening, and those hack-attempts do use/waste Windows resources, and if that happens for a day, Windows might become unstable.
Note: The Windows Firewall or firewalls build into routers and / or other network devices, do not block RDP sessions which are done with the objective to hack a Terminal Server. One should not assume that some network device or firewall has the ability to detect multiple failed RDP logins, followed by blocking the remote client / device.
Access from Local / Private IP Addresses is default allowed (and usually there is no reason for not allowing this).
Access from Public IP Addresses is default not allowed. If it is required to access the Terminal Server from the internet, from a Public IP Address, it is recommended to use a SSL connection and use the SSL Gateway .
Access from Public IP Addresses can be allowed:
Permanent Allow RDP Connections from Public IP Addresses is possible as follows:
When allowing RDP Connections from Public IP Addresses for all users, be sure to use the Spamhaus Drop List and the GeoIP list.
Example: the Administrator has created a group called "On The Road" users:
Access from Public IP Addresses is only allowed for users who are member of the group "On The Road users".
By clicking on the button showing the group name, the Administrator can select the appropriate group:
The objective of the option "Allow Temporary RDP Connections from Public IP Addresses" is as follows:
However,
Either only Administrators or all Users can temporary allow RDP Connections from Public IP Addresses
The Application folder of an AADS Terminal Server contains the following program:
Any user can start this program, although it depends on the configuration as shown above here, if the user can do something with the program.
The user can select an amount of time between 1 and 48 hours, and click on the Apply button. If he selects, for example, 3 hours, it shows as follows:
The end-date and time is shown. For the next 3 hours it is possible to do RDP connections from Public IP Addresses.
When the remote administrator is done with his job, the user can optional click on the Stop-button, and the period for allowing RDP connections from Public IP Addresses is terminated immediately.
Note; when the user clicks on Stop, the current active session of the remote administrator will not be disconnected. However, if the remote administrator attempts to connect again, that attempt will be denied.
If the AADS Terminal Server is configured that it is not allowed to enable temporary RDP Connections from public IP Addresses:
then the user can not set a temporary period:
SSL connections are default allowed from both Private and Public IP Addresses.
The SSL Gateway describes how an AADServer handles SSL traffic.
GeoIP Location offers the ability to allow only connections from certain countries (Allow List) or block connections from certain countries (Deny List).
GeoIP Location should be used with RDP connections. For SSL connections is GeoIP is less relevant because the SSL Gateway does only allow connections from known Client PCs.
Quote from the Spamhaus website: DROP includes netblocks that are hijacked or leased by professional spam or cyber-crime operations (used for dissemination of malware, trojan downloaders, botnet controllers).
It is quite unlikely that legitimate users do need to do a login on an AADServer, from one of the netblocks / IP ranges which are included on the Spamhaus Drop list. Therefore it is better to block all connections from these netblocks / IP ranges.
Spamhaus Drop List should be used with RDP connections. For SSL connections is Spamhaus Drop List is less relevant because the SSL Gateway does only allow connections from known Client PCs.
The Firewall will block Clients when it is detected that the Client has done 5 failed logon attempts.
When it is about "failed logon attempts", it can be about those zombie-hacked-PC's, hacked routers, compromised IOT devices, hacked smart TV's, etc, in a botnet out there on the internet. And this botnet with hacked devices does attempt to hack into the AADServer with the well known "Administrator" userID or other well-known, pre-defined userID's like "Guest".
Or it can be about, for example, a former employee, or a visitor to the company office, who knows the userIDs of the employees, and attempts to hack into the AADServer with the usernames / userIDs as defined for the employees.
Either hack-attempts are blocked by the AADS RDP Firewall.
There are however circumstances where it is not really required to block Client PCs which do multiple failed logon attempts with specific company usernames / userIDs. For example, Point Of Sales systems that do automatically login on the AADServer, with a specific username like "POSClient123" (example of an username), and a password that nobody knows. Login is done automatically when booting the POS Client PC. And in the event that the remote POS Client PC makes an error, for example because the barcode reader is disconnected, it might not be needed to block the remote POS Client PC in the Firewall, but just fix the error. In such a case the IT Administrator of the AADServer can choose to handle only failed login / hack attempts when it is done with a well known user names like Administrator, but do not block a Client in the Firewall in case the failed login attempt is done with other, self defined user names.
However, if it is chosen not the block such failed login attempts, a rough (ex-)employee for example, might start some trouble with login attempts, using those usernames like "POSClient123". Therefore it is recommended always to enable Notifications, specifically the Notification for a failed logon attempt.
Default setting is to block Clients in any case. Wether the failed login / hack attempt is done with a well known username like Administrator, or a specific username that is known only on this AADServer, the Client will be blocked after 5 failed login / hack attempts.
Default a Client will be blocked after 5 Failed Login attempts.
When it is attempted to do a Remote Login from a specific IP Address, and there are 5 Failed Attempts within the configured Deny-period of 7 days, the IP Address of the Remote PC / Client is entered on the Temporary Blocked list for the next 7 days.
The Client PC will be removed automatically from the Temporary Blocked list when it has not been seen for 7 days. The 7 days are counted down to 0 from the last moment that the Client PC has contacted the AADServer. Any attempt to login again in those 7 days, will prolong the 7 days.
If required, Audit Logfiles will be created which will contain details about connections from Clients.
The logfiles are created in:
| x32 | C:\Program Files\AADServer\logging |
| x64 | C:\ProgramData\AADServer\logging |
Usually the loglines are ordered by DATE/TIME. However, it is possible that "newer" loglines appear before "older" loglines. This might happen in case 2 or more Remote Clients connect or disconnect on almost the exact same moment. Therefore when using or viewing the Audit Logfiles, one should not assume that all loglines are ordered by DATE/TIME.
| d | Displays the day as a number without a leading zero (1-31) |
| dd | Displays the day as a number with a leading zero (01-31) |
| ddd | Displays the day as an abbreviation (Sun-Sat) |
| dddd | Displays the day as a full name (Sunday-Saturday) |
| m | Displays the month as a number without a leading zero (1-12). Note: If the m specifier immediately follows an h or hh specifier, the minute rather than the month is displayed |
| mm | Displays the month as a number with a leading zero (01-12). Note: If the mm specifier immediately follows an h or hh specifier, the minute rather than the month is displayed |
| mmm | Displays the month as an abbreviation (Jan-Dec) |
| mmmm | Displays the month as a full name (January-December) |
| yy | Displays the year as a two-digit number (00-99) |
| yyyy | Displays the year as a four-digit number (0000-9999) |
| h | Displays the hour without a leading zero (0-23) |
| hh | Displays the hour with a leading zero (00-23) |
| n | Displays the minute without a leading zero (0-59) Note: it is also possible to use a m for minutes, but the m is ambiguous: see month. |
| nn | Displays the minute with a leading zero (00-59). Note: it is also possible to use a mm for minutes, but the mm is ambiguous: see month. |
| s | Displays the second without a leading zero (0-59). |
| ss | Displays the second with a leading zero (00-59). |
| am/pm | Uses the 12-hour clock for the preceding h or hh specifier, and displays 'am' for any hour before noon, and 'pm' for any hour after noon. The am/pm specifier can use lower, upper, or mixed case, and the result is displayed accordingly. |
| a/p | Uses the 12-hour clock for the preceding h or hh specifier, and displays 'a' for any hour before noon, and 'p' for any hour after noon. The a/p specifier can use lower, upper, or mixed case, and the result is displayed accordingly. |
The built-in Firewall has Connect Rate Limit settings, such to prevent attacks on the Server. There are 3 increasing sets indicate the number of connections within a given amount of time. These 3 sets are applied when the same IP Address does multiple connections to the Server. When exceeding this number of connections, the attempts from the Client to do more connections are denied. The current active connections which were within the limits of the 3 sets, are allowed; the current active connections are not disconnected when the "next" connection attempt from the Client exceeds the Connect Rate Limit sets.
Default AADS will Block access from Localhost to Localhost.
The objective of "Block access from Localhost to Localhost" is to block viruses and / or RAT (remote access tools) on an infected PC / Server.
This setting does not prevent the infection of a PC / Server. AADS is not Anti Virus software. As usual any PC or Server needs proper Anti Virus software. However, if it happens that the PC / Server gets infected, this setting is an additional protection against the operation of RAT viruses.
In the event that a PC / Server gets infected with a RAT virus, using the RAT virus the hacker might attempt to get full RDP access to the infected PC / Server and do whatever the hacker wants to do. Because the RAT virus / software runs locally on the PC / Server, it is possible to block this type of RDP access by blocking access from Localhost to Localhost. The users within the company are not affected by this setting.
Because of our Support, we have received multiple ZIP Support Files from customers in trouble, and from the details of the logging in the ZIP Support Files, we have learned that it was a RAT virus that was causing the trouble. And we have also learned from the logging that we can block the operation of the RAT virus by blocking access from Localhost to Localhost.
In case the Webserver is activated and applied, the AADS RDP Firewall does also handle invalid WWW requests towards the Webserver:
In case Clients do multiple invalid WWW request, after 10 requests they will be blocked for 1 day (default setting).
This option is available for Windows 10 and newer, and Windows Server 2016 and newer.
In case the option for Windows Firewall is selected, AADS creates and maintains the following Firewall rules:
| RDP | Created and maintained by AADServer. |
| SSL |
Created and maintained if the SSL Gateway is enabled. |
| WWW |
Created and maintained if the WebServer is enabled. |
| FARM |
Created and maintained if the Farm is enabled. |
In case AADS settings are changed, AADServer will also update the Windows Firewall rule.
Example: if the port number of the SSL Gateway is changed, AADServer will also update the Windows Firewall rule for the SSL Gateway.
|
© 2012-2023 AADS WorldWide. Terminal Server | Application Server | Remote Desktop solutions | Firewall |
|
|
|
