故事的起因是这两天发现甲骨文主机一直在满载，查看后台记录可知从5月15日前后开始满载，表现为有几个xrdp进程吃掉了cpu占用。

中间短暂恢复正常是是我重启了xrdp服务，后来又出现相同的满载情况

第一次我觉得可能是bug，但是第二次就基本上断定是有人在干坏事了。

搜索之后有人在xrdp的github上问相同的问题，开发者由于良好的使用习惯，没有直接想到被扫描的场景，倒是有一个网友的的回答比较贴近我的猜测：

ckpeter commented 5 days ago

I am seeing a very similar issue, with multiple xrdp processes taking up 100% cpu indefinitely.This happens on two different unconnected, public-facing servers in two different data centers. My investigation suggests that this is some kind of DOS attack/port scan that causes the xrdp processes to hang. This is because there is one single specific IP that connects to both servers repeatedly every few seconds, and it seems that every few hours or so, a new xrdp process will hang at 100%. As soon as I blocked that IP, no more xrdp hangs on either server. However, existing xrdp processes running at 100% cpu continues to hang.

https://github.com/neutrinolabs/xrdp/issues/2692

我发现/var/log/xrdp.log有2G多之大，而我实际连接的次数满打满算也就只有几十次，想办法看了里面的记录之后，也是超乎我之前的想象。

去年到现在，一共有301万次的连接尝试…基本上每几秒钟就有一次连接尝试，几乎可以等同于暴力破解了。

这更是进一步证明这篇文章的主题：不要公网暴露RDP

我曾经尝试把一台安装了win7的小机器暴露公网做跳板机，没多久就被塞了勒索病毒，如今看来确实也是理所当然。

面对这种强度的扫描，直接暴露公网也等于直接暴露漏洞。

VPN或者其他认证方式是十分必要的，防火墙规则也不能随意清空。

还有一种xRDP over SSH Tunnel可以参考

xRDP – How to secure Xrdp Connection using SSH Tunnels on Ubuntu 20.04

牢记：公网十分危险

===================

The reason for the story is that in the past two days, it has been found that the Oracle host has been fully loaded. Looking at the background records, we can see that it has been fully loaded since around May 15. It shows that several xrdp processes have eaten up the CPU usage.

It returned to normal briefly in the middle because I restarted the xrdp service, and then the same full load situation appeared again

The first time I thought it might be a bug, but the second time I basically concluded that someone was doing something bad.

After searching, someone asked the same question on the github of xrdp. Due to good usage habits, the developer did not directly think of the scene being scanned, but another reply in the discussion was closer to my guess:

ckpeter commented 5 days ago

I am seeing a very similar issue, with multiple xrdp processes taking up 100% cpu indefinitely.This happens on two different unconnected, public-facing servers in two different data centers. My investigation suggests that this is some kind of DOS attack/port scan that causes the xrdp processes to hang. This is because there is one single specific IP that connects to both servers repeatedly every few seconds, and it seems that every few hours or so, a new xrdp process will hang at 100%. As soon as I blocked that IP, no more xrdp hangs on either server. However, existing xrdp processes running at 100% cpu continues to hang.

https://github.com/neutrinolabs/xrdp/issues/2692

https://github.com/neutrinolabs/xrdp/issues/2692

I found that /var/log/xrdp.log is large than 2GB, and the number of actual connections I have made is only a few dozen times. After trying to read the records in log, the reality is beyond my previous imagination.

From last year to now, there have been a total of 3.01 million connection attempts… basically one attempt by every few seconds, which is almost equivalent to brute force cracking.
This further proves the theme of this article: Do not expose RDP on the public network

I once tried to expose a small machine with win7 installed to the public network as a springboard machine, and it didn’t take long for it to be filled with ransomware, which seems to be a matter of course now.

In the face of this intensity of scanning, directly exposing the public network is also equivalent to directly exposing vulnerabilities.

VPN or other authentication methods are very necessary, and the firewall rules cannot be cleared at will.

There is also xRDP over SSH Tunnel you can refer to

xRDP – How to secure Xrdp Connection using SSH Tunnels on Ubuntu 20.04

Please remember that: public internet is more dangerous that you think!