I'm using Linux VPS as a web server (haproxy+nginx+java+mysql+memcached+redis+solr), for security reason, I disabled password login and using key instead.
我正在使用Linux VPS作为Web服务器(haproxy + nginx + java + mysql + memcached + redis + solr),出于安全考虑,我禁用了密码登录并使用了密钥。
These days, I can't login to my server, when using VPS console to login, I found some strange public key in the /root/.ssh/authroized_keys, and my own public key was removed:
这些天,我无法登录我的服务器,当使用VPS控制台登录时,我在/root/.ssh/authroized_keys中发现了一些奇怪的公钥,并删除了我自己的公钥:
"REDIS0006t^@^@^CqweA<92>
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNTotEB55uRlAS9sKUfT3WyJzq1kGQVVGQk9WPDmjg
c6fvkubd3qRAE1lBQmZ+LjnHSSOcP54EoBTphiL+Lf2pFKkbFNYVGIdJBhRWUIDlm/vIGO4GCLfpPnRz
rw3UsVLUykb68fFJXrPOfGC5Qj16nlrVY6gMO2p1pAmmBqkwPpyxbBkXkBFme3k95wl6Q6MWJLUXAEeT
GuqzMukZHkA15hXxas5AKYRKAwrls9UrUqBXCy7Gp5lnq8m/RI0L8mNseB1hD1Fi/KQqVgwXXmXhjWDQ
qtzqF7Eh2woNhqojSpd9QlOO/LxPMKzgF9cStBcbkaQ5gXoO+zFYL2B/nRp1 root@vultr.guest
^@à^AA<8d>-e
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDAND7d7omg6ByhAlAbtb3++0P4clJ4cLCSSAH7CXuM
Y9ENqGVYmdoJSkXJt7uk5HX4ioFkDesuR/Yi6tBx0hKq/AXhfhOX4rS0ESXo83z2dlbo52/bdkEMxwgY
hym+MYcK3jxmnQ+Fy1649otJeidENNhracOPdSekvyIebJTIfcT/4JD46z1anir9M3UD5oa53wBlkyew
VXAWus33SNHrGvns9jCTD0jefclWCNh6MeFITxMIDMErF5Fvz8fPyDuI7AUGt22lYb8I2lhkfQUPruZz
EEdMGaZ/YjhteIao8Ap7Avf55vXHwa7HVbBlwKL7+J7nmpq1X0+RFX6OlktJ yyf
-e
^@^GcrackitABbfilenarmeed iasu-tchloir.iezxeed _-khe y6s0.164.96.208^M
^M
saveconfig set dir /root/.ss^M"
What does that mean? is any hacker try to login my server?
那是什么意思?有没有黑客尝试登录我的服务器?
2 个解决方案
#1
0
Redis is insecure by design, as stated by its developer here.
正如其开发人员所说,Redis的设计不安全。
However, the ability to control the server configuration using the CONFIG command makes the client able to change the working directory of the program and the name of the dump file. This allows clients to write RDB Redis files at random paths, that is a security issue that may easily lead to the ability to run untrusted code as the same user as Redis is running.
但是,使用CONFIG命令控制服务器配置的能力使客户端能够更改程序的工作目录和转储文件的名称。这允许客户端在随机路径上编写RDB Redis文件,这是一个安全问题,很容易导致能够运行不受信任的代码,因为Redis正在运行相同的用户。
That page also contains a detailed description how to rewrite ssh keys and get full access to the system (the result is similar to what OP has). The solution depends on usage model and may include firewalling, enabling AUTH and binding to 127.0.0.1.
该页面还包含如何重写ssh密钥并获得对系统的完全访问权限的详细描述(结果类似于OP所具有的)。解决方案取决于使用模型,可能包括防火墙,启用AUTH和绑定到127.0.0.1。
#2
0
It appears that your server was remotely compromised via the Redis daemon (which is probably running as root, even though it shouldn't be, but this is the default if you compile yourself, as is listening remotely: basically, if you compile redis on a non-firewalled box, expect to get owned unless you actively change the defaults.)
看来您的服务器是通过Redis守护程序远程攻击的(可能是以root身份运行,即使它不应该运行,但如果您自己编译,这是默认设置,就像远程监听一样:基本上,如果您编译redis on除非您主动更改默认值,否则期望获得拥有的非防火墙框。)
Since the attacker obviously gained root, you cannot be certain that you do not have rootkit or other issues or that you will not be re-infected (with possibly even more disastrous consequences later).
由于攻击者明显获得了root权限,因此无法确定您是否没有rootkit或其他问题,或者您不会再次被感染(之后可能会带来更多灾难性后果)。
This was obviously non-subtle attack. :) Since the attacker didn't care if you knew of his presence, expect rootkits, LKM's, etc.
这显然是非微妙的攻击。 :)由于攻击者不在乎你是否知道他的存在,所以期待rootkits,LKM等等。
To be sure, and for your own peace of mind: ensure all data files are backed up, count your blessings, and go through the whole disaster recovery process; securely wipe the server and restore from backups.
可以肯定的是,为了您的安心:确保备份所有数据文件,计算您的祝福,并完成整个灾难恢复过程;安全擦除服务器并从备份还原。
#1
0
Redis is insecure by design, as stated by its developer here.
正如其开发人员所说,Redis的设计不安全。
However, the ability to control the server configuration using the CONFIG command makes the client able to change the working directory of the program and the name of the dump file. This allows clients to write RDB Redis files at random paths, that is a security issue that may easily lead to the ability to run untrusted code as the same user as Redis is running.
但是,使用CONFIG命令控制服务器配置的能力使客户端能够更改程序的工作目录和转储文件的名称。这允许客户端在随机路径上编写RDB Redis文件,这是一个安全问题,很容易导致能够运行不受信任的代码,因为Redis正在运行相同的用户。
That page also contains a detailed description how to rewrite ssh keys and get full access to the system (the result is similar to what OP has). The solution depends on usage model and may include firewalling, enabling AUTH and binding to 127.0.0.1.
该页面还包含如何重写ssh密钥并获得对系统的完全访问权限的详细描述(结果类似于OP所具有的)。解决方案取决于使用模型,可能包括防火墙,启用AUTH和绑定到127.0.0.1。
#2
0
It appears that your server was remotely compromised via the Redis daemon (which is probably running as root, even though it shouldn't be, but this is the default if you compile yourself, as is listening remotely: basically, if you compile redis on a non-firewalled box, expect to get owned unless you actively change the defaults.)
看来您的服务器是通过Redis守护程序远程攻击的(可能是以root身份运行,即使它不应该运行,但如果您自己编译,这是默认设置,就像远程监听一样:基本上,如果您编译redis on除非您主动更改默认值,否则期望获得拥有的非防火墙框。)
Since the attacker obviously gained root, you cannot be certain that you do not have rootkit or other issues or that you will not be re-infected (with possibly even more disastrous consequences later).
由于攻击者明显获得了root权限,因此无法确定您是否没有rootkit或其他问题,或者您不会再次被感染(之后可能会带来更多灾难性后果)。
This was obviously non-subtle attack. :) Since the attacker didn't care if you knew of his presence, expect rootkits, LKM's, etc.
这显然是非微妙的攻击。 :)由于攻击者不在乎你是否知道他的存在,所以期待rootkits,LKM等等。
To be sure, and for your own peace of mind: ensure all data files are backed up, count your blessings, and go through the whole disaster recovery process; securely wipe the server and restore from backups.
可以肯定的是,为了您的安心:确保备份所有数据文件,计算您的祝福,并完成整个灾难恢复过程;安全擦除服务器并从备份还原。