查看nginx日志,发现有报错信息:

2019/07/16 17:34:42 [crit] 4397#0: *349 open() "/fastcgi_temp/5/00/0000000005" failed (13: Permission denied) while reading upstream

查看对应目录的权限,发现所属用户是nobody,而实际运行nginx的是wwwuser

root      1842  0.0  8.5 410716 332500 ?       Ss   17:10   0:01 nginx: master process /usr/local/nginx/sbin/nginx -c /etc/nginx/nginx.conf
wwwuser   4397  0.0  8.5 412288 332828 ?       S    17:33   0:00 nginx: worker process
wwwuser   4398  0.0  8.5 411776 332360 ?       S    17:33   0:00 nginx: worker process
wwwuser   4399  0.0  8.5 412800 330336 ?       S    17:33   0:00 nginx: cache manager process

因此问题原因应该是:nginx最初始时以nobody身份启动过,创建了缓存所属用户是nobody,后面改动nginx的运行用户为wwwuser,导致新用户没有权限写入缓存。

解决方案:修改对应目录下的所属用户为当前nginx启动用户。

linux环境下查看系统负载的几种方式

一、uptime和w命令

uptime命令和w命令都可以显示系统当前的负载:

ma@centos7:~$ uptime
 09:37:15 up 19 days, 20 min,  1 user,  load average: 0.00, 0.01, 0.05
ma@centos7:~$ w
 09:37:17 up 19 days, 20 min,  1 user,  load average: 0.00, 0.01, 0.05
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
ma       pts/0    200.200.65.82    09:28    5.00s  0.01s  0.00s w
  • 09:37:15 up 19 days, 20 min:系统启动时间
  • 1 user:当前有一个用户在线
  • load average: 0.00, 0.01, 0.05:1分钟、5分钟和15分钟内的cpu平均负载

关于系统负载

系统平均负载被定义为在特定时间间隔内运行队列中的平均进程数,如果一个进程满足以下条件则其就会位于运行队列中:

  • 它没有在等待I/O操作的结果
  • 它没有主动进入等待状态(也就是没有调用wait
  • 没有被停止(例如:等待终止)

一般来说,每个CPU内核当前活动进程数不大于3,则系统运行表现良好!当然这里说的是每个cpu内核,如果主机是四核cpu的话,那么只要uptime最后输出的一串字符数值小于12即表示系统负载不是很严重。如果达到20,那就表示当前系统负载非常严重。

二、/proc/loadavg

/proc/loadavg也能显示系统的负载信息:

ma@centos7:~$ cat /proc/loadavg 
0.01 0.02 0.05 1/199 19643

前面三个也是分别表示1分钟、5分钟以及15分钟的系统平均负载。后面的1/199表示系统当前共有199个进程,其中1个进程处于运行状态。19643表示最后一个运行的进程ID。

三、查看CPU负载情况

mpstat命令可以打印出当前系统的cpu信息,统计当前CPU的各项指标信息:

ma@centos7:~$ mpstat 
Linux 3.10.0-862.14.4.el7.x86_64 (centos7)    05/07/19    _x86_64_    (2 CPU)

10:03:33     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
10:03:33     all    0.03    0.00    0.03    0.00    0.00    0.07    0.09    0.00   99.78
  • %user:在internal时间段里,用户态的CPU时间(%),不包含nice值为负进程。(usr/total)*100
  • %nice:在internal时间段里,nice值为负进程的CPU时间(%)。(nice/total)*100
  • %sys:在internal时间段里,内核时间(%)。(system/total)*100
  • %iowait :在internal时间段里,硬盘IO等待时间(%)。(iowait/total)*100
  • %irq:在internal时间段里,硬中断时间(%)。(irq/total)*100
  • %soft:在internal时间段里,软中断时间(%)。(softirq/total)*100

常用参数

  • -P CPU:打印指定CPU的信息,默认只打印所有CPU汇总后的统计数据,加上-P ALL会把每个CPU的统计信息都打印出来。
  • interval times:每隔interval统计一次信息,共统计times次。

例如,每1秒打印一次cpu信息,共打印2次:

最后会针对这三次生成一次统计信息。

四、查看内存

free命令可以查看当前的内存:

maqian@os:~$ free -m
              total        used        free      shared  buff/cache   available
Mem:          16285        5096       10964          17         223       11057
Swap:         29663           0       29663

Mem表示的是系统的物理内存,Swap是虚拟内存。

五、使用top查看CPU和内存占用

top命令可以查看当前系统下所有进程的CPU和内存占用情况:

输入命令后会进入交互式界面,在交互式页面输入P可以对CPU占用排序,输入M对内存占用排序。

一、问题描述

某天,在QQ空间看到大学同学发了一个求助帖:

求助安装一个ffmpeg软件((linux平台下开源的音视频转码工具),本着助人为乐的想法准备提供一下帮助,了解之后才发现她想做的根本不是安装ffmpeg,而是已经装好了发现命令执行太卡,以为自己装错了,想找个熟人重装一下。再次深入了解才发现最终的问题是这样的:她们用的腾讯云学生机(1C1G配置),平常在上面用ffmpeg做音视频转码的实验,一个10M左右的视频转码需要十几分钟,觉得时间太长了,并且看到的日志显示他们转码并没有消耗CPU资源。

最后排查下来发现系统是被黑客入侵了,排查相当顺利(比起我们公司设备的排查简直容易一百倍),记录下排查过程。

二、排查过程

了解具体问题之后发现了两个不寻常的地方:

  1. 10M的视频转码要10分钟以上-----单核CPU应该也不至于此。
  2. 她们看到的日志显示没有占用CPU资源-----没有GPU,视频转码不耗CPU不太可能。

首先登陆上设备,看CPU占用:发现设备上以ftpuser运行了一个bash64的进程,常年占用CPU在97%以上。

第一眼看上去就很奇怪,为什么ftpuser会运行bash64?而且一般的bash也不叫bash64,为什么CPU占用会这么高?一种不妙的感觉顿时涌上心头,当时感觉就可能是被黑了。

尝试关闭进程,果然,根本关不掉,关了又起来。ps查看文件所在位置之后删除也不行,删除后还会自动创建,进程也还是会起来。

再仔细一看,发现进程执行的程序是放在ftpuser主目录下的一个隐藏文件夹下,同时还有个配置参数,cat这个文件竟然是一串ssh密钥。这明显就是一个挖矿进程了。

。。。于是乎,排查结束!

三、解决方案

结论

系统被黑客入侵,植入了挖矿程序,一直占用CPU导致其他程序无法得到CPU资源,出现了ffmpeg转码卡慢的问题。

解决方案

因为工作太忙(当时已经是晚上快十点了还在公司加班。。。)没有深入分析下去,直接建议重装系统了。

事后发现

腾讯云早已发送告警短信到她手机,她熟视无睹:

修改ssh端口后使用systemctl一直无法启动sshd,报错:

Job for sshd.service invalid.

使用journalctl -xe查看错误信息,发现一串没有权限绑定端口错误信息:

-- Unit sshd.service has begun starting up.
Jun 04 18:58:11 instance-1 sshd[20960]: error: Bind to port 22345 on 0.0.0.0 failed: Permission denied.
Jun 04 18:58:11 instance-1 sshd[20960]: error: Bind to port 22345 on :: failed: Permission denied.
Jun 04 18:58:11 instance-1 sshd[20960]: fatal: Cannot bind any address.
Jun 04 18:58:11 instance-1 systemd[1]: sshd.service: main process exited, code=exited, status=255/n/a
Jun 04 18:58:11 instance-1 systemd[1]: Failed to start OpenSSH server daemon.
-- Subject: Unit sshd.service has failed

很奇怪,服务是使用root身份启动的,端口号也不在1-1024之间,不可能出现端口号无法绑定的问题。

开始怀疑是不是端口号被占用了,但是用netstat命令查看并没有占用,而且如果被占用报错也应该是xx already been used,因此排除端口被占用了。

后来发现是开启了SELinux导致的,使用sestatus查看SELinux当前的状态:

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      31

最后的解决办法就是关闭SELinux了,执行setenforce 0临时关闭。

通过ssh登录时报错:

Host key verification failed.

最开始以为是服务端的问题,但是排查发现不管登录哪台设备都是报这个错,因此肯定不是服务端的问题了。

打印ssh连接日志发现有如下错误信息:

debug1: checking without port identifier
debug1: read_passphrase: can't open /dev/tty: Permission denied
Host key verification failed.

以前从来没有遇到这个问题,查看/dev/tty的权限发现是600,而其他的设备正常是666

于是修改/dev/tty的权限,再次登录就好了:

sudo chmod 666 /dev/tty

下午客户打电话过来说QQ总是掉线,怀疑(一口咬定)是我们设备(我们的是路由设备,放在出口)故障导致的,态度十分强硬。从客户提出问题的第一秒起就已经可以断定是运营商网络问题了,为什么呢:

  1. 对路由器来说,路由逻辑都是在系统内核实现的,linux系统跑了这么多年,不可能还出现这种问题。
  2. 客户那里断网不是每次都是所有PC集体断,只有少部分PC时断时续,不稳定。如果路由器有问题肯定是集体短线,而运营商有问题就不一定了,不是所有的QQ都在同一个服务器上,线路不同,网络状态也不同。

但是没有真凭实据可以来证明这一点,并且现象不是一直存在的,所以最后只能用挫招了:在设备的lan和wan口抓包,每十分钟重抓一次,直到客户网络出现问题。

最后抓了一个小时,终于抓到了数据包,那么如何判断是路由器的问题还是运营商网络的问题呢:

  1. 对比LAN和WAN的数据包,如果LAN的数据没有经过WAN发出去,或者从LAN收到数据包到WAN发出数据包的时间太长,那说明路由设备有问题。
  2. 如果来自LAN的数据包在WAN口都发出去了,但是没有收到对端服务器的回复,或者回复时间太长,那么就是运营商网络有问题了。

要用到的一个重要的功能就是Wireshark的追踪流功能:

使用追踪流可以把当前连接的所有交互数据都显示出来:

这个是lan口的抓包数据,PC的IP是192.168.10.62,已经能看到有很多重传的数据包了,但是还不能确定是路由器丢包了还是服务端丢包了。此时就要对比两个口的数据包,看看lan口的数据包是否有被转发出去,lan和wan的数据包可以通过目的IP地址来一一对应起来,因为不管数据怎么转发,目的IP都是不变的。可以先在lan口追踪每一个TCP流,然后在wan口过滤目的地址。

而在随机抓取的前面几个数据包中,发现,每个连接都是wan端发起的连接,然后服务端没有响应,一直在产生重传操作,这就可以证明是用户网络的问题而不是我们设备的问题了。

TCP流1

imagec46b15a9d92d3a02.png

TCP流2

image659c17255647c185.png

TCP流3

image68afd74093fafb22.png

TCP流4

imagede37053196e95251.png

准备好证书和私钥文件,重命名为:rui.certrui.key

开启SSH:

登陆后台,把证书和私钥拷贝到/etc/vmware/ssl/目录覆盖,然后使用services.sh restart重启服务。

一、概述

之前安装好了ModSecurity作为nginx的WAF,但是后续的使用中发现OWASP-CRS规则过于苛刻,很多正常操作都会被阻挡,甚至打开一个正常的页面都会被拦截。每次都要手动排除规则十分麻烦,可以考虑使用第三方规则库:comodo规则库地址(访问需要翻墙)

comodo规则库是免费使用的,支持apache/httpd/nginx等多种web应用。使用前要先注册账号,支付0元之后将会得到为期一年的授权,此时就可以下载最新的规则库使用了,使用方式和OSASP-CRS一样,只需把规则文件加到ModSecurity的配置文件中即可。同时,官方还提供了非常简易的操作面板和详细的操作文档。

二、使用方式

如果没有安装ModSecurity先参考nginx安装modsecurity实现waf功能进行安装,ModSecurity的配置文件放在/etc/nginx/目录下。

当前最新版的comodo规则库版本为1.208,解压规则库,放到/etc/nginx/waf/comodo目录:

tar cwaf_rules_nginx_3-1.208.tgz -C /etc/nginx/waf/comodo

修改/etc/nginx/modsecurity.conf文件,设置新的规则文件位置:

Include /etc/nginx/waf/comodo/rules.conf.main

重启nginx服务,然后测试规则是否生效:

[ma@ubuntu comodo]$ curl -I http://localhost
HTTP/1.1 200 OK
Server: Tomcat/1.0.2
Date: Sun, 02 Jun 2019 01:38:52 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Fri, 14 Dec 2018 14:04:25 GMT
Connection: keep-alive
ETag: "5c13b869-264"
Accept-Ranges: bytes

[ma@ubuntu comodo]$ curl -I 'http://localhost/?search=<scritp>alert('xss');</script>'
HTTP/1.1 403 Forbidden
Server: Tomcat/1.0.2
Date: Sun, 02 Jun 2019 01:39:17 GMT
Content-Type: text/html
Content-Length: 169
Connection: keep-alive

第二个xss攻击的被拦截了,规则生效。

一、ModSecurity和OWASP

ModSecurity是一个免费、开源的Apache模块,可以充当Web应用防火墙(WAF)。ModSecurity从3.0开始支持nginx,配合nginx的灵活和高效,可以打造成生产级的WAF,是保护和审核web安全的利器。

ModSecurity的主要功能在于,提供可靠的保护,远离各种网上威胁。它不是将安全重心偏离应用程序,而是增添了全局级别的功能。想对它进行配置,只需为客户机与服务器之间通信的每一个部分用条件和操作来指定规则,这些部分包括请求头、请求主体、响应头和响应主体。因而,ModSecurity可以预防针对Web服务器、PHP、Perl和ASP等解释器以及Web应用程序发动的攻击。

OWASP是一个安全社区,开发和维护着一套免费的应用程序保护规则,这就是所谓OWASP的ModSecurity的核心规则集(即CRS)。我们可以通过ModSecurity手工创建安全过滤器、定义攻击并实现主动的安全输入验证。

二、nginx中添加ModSecurity模块

2.1 查看当前nginx编译选项

如果设备已经安装了nginx,先记住当前的nginx编译选项。使用nginx -V命令可以查看编译选项:

[art@centos7 ~]$ nginx -V
nginx version: Tomcat/1.0.2
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) 
built with OpenSSL 1.0.2k-fips  26 Jan 2017
TLS SNI support enabled
configure arguments: --user=www --group=www --prefix=/usr/local/nginx-1.12.2 --with-http_stub_status_module --with-http_ssl_module

最后一行就是nginx安装时的编译选项,先记住。

2.2 下载ModSecurity代码

拉取ModSecurity主代码,当前版本是3.x。ModSecurity在3.0以后已经不止是一个模块了,主代码库编译出来的是一个公共库,可以被第三方代码直接引用,现如今的ModSecurity-nginx就是通过这个lib库来完成的。

因此,整个modsecurity功能目前一共涉及到三个东西:

  1. ModSecurity的lib库
  2. ModSecurity的nginx模块
  3. owasp规则

克隆ModSecurity代码:

git clone https://github.com/SpiderLabs/ModSecurity.git

克隆ModSecurity-nginx代码:

git clone https://github.com/SpiderLabs/ModSecurity-nginx.git

克隆owasp-modsecurity-crs代码:

git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git

三个代码都克隆完成后,应该存在以下三个目录:

maqian@Inspiron:/usr/src/software$
total 20
drwxrwxr-x  5 root   root   4096 6月   1 19:48 ./
drwxr-xr-x  9 root   root   4096 6月   1 19:41 ../
drwxrwxr-x 13 maqian maqian 4096 6月   1 19:44 ModSecurity/
drwxrwxr-x  5 maqian maqian 4096 6月   1 19:47 ModSecurity-nginx/
drwxrwxr-x  7 maqian maqian 4096 6月   1 19:48 owasp-modsecurity-crs/

进入到ModSecurity目录,初始化子模块,这一步相当重要,否则后面会出错

cd ModSecurity
git submodule init
git submodule update

2.3 集成ModSecurity到nginx

2.3.1 下载依赖项

依赖项注意区分系统环境,除此之外后面的流程都不再依赖系统环境。

CentOS环境:

sudo yum install autoconf automake libtool gcc gcc-c++ make
sudo yum install yum install prce pcre-devel openssl openssl-devel

Ubuntu系统:

sudo apt-get install autoconf automake libtool gcc g++ make
sudo apt-get install openssl libssl-dev libpcre3 libpcre3-dev zlib1g-dev

2.3.2 编译ModSecurity

进入ModSecurity目录:

./build.sh
./configure
make && sudo make install

因为后面的modsecurity-nginxnginx编译都依赖modsecurity的lib库,为了方便起见,直接把编译后的库文件放到默认目录,不手动指定安装目录。

2.3.3 nginx编译安装

如果没有安装nginx,先下载好nginx代码,nginx的编译安装参考:CentOS源码编译安装NGINX。如果已经安装了nginx,记录nginx当前的编译选项,参考步骤2.1

nginx是否安装不重要,不同的是如果没有安装就要先下载源代码,如果安装了就记录下编译选项。

假设安装时候的编译选项为:

--user=www --group=www --prefix=/usr/local/nginx-1.12.2 \
    --with-http_stub_status_module --with-http_ssl_module

进入nginx目录:

./configure --user=www --group=www \
    --prefix=/usr/local/nginx-1.12.2 \
    --with-http_stub_status_module --with-http_ssl_module \
    --add-module=../ModSecurity-nginx/
make && sudo make install

安装好后nginx的配置参考上面的文档即可。

2.3.4 配置OWASP Core Rule Set

owasp-modsecurity-crs开始已经下载到本地,首先拷贝一份到nginx配置目录,假设安装到/etc/nginx/owasp目录下:

cp owasp-modsecurity-crs /etc/nginx/owasp/ -rf
mv /etc/nginx/owasp/crs-setup.conf.example /etc/nginx/owasp/crs-setup.conf

配置ModSecurity:

cp ModSecurity/modsecurity.conf-recommended /etc/nginx/modsecurity.conf
cp ModSecurity/unicode.mapping /etc/nginx/

modsecurity.conf中添加crs-setup.conf的配置:

SecRuleEngine On
Include /etc/nginx/owasp/crs-setup.conf
Include /etc/nginx/owasp/rules/*.conf

在nginx的配置中开启modsecurity模块,可以放在server段或者location段内:

modsecurity on;
modsecurity_rules_file /etc/nginx/modsecurity.conf;

测试配置文件是否正确:

nginx -t -c /etc/nginx/nginx.conf

可能会报错:

2019/06/01 20:56:09 [emerg] 29985#0: "modsecurity_rules_file" directive Rules error. File: /etc/nginx/owasp/rules/REQUEST-910-IP-REPUTATION.conf. Line: 71. Column: 22. This version of ModSecurity was not compiled with GeoIP or MaxMind support.  in /etc/nginx/nginx.conf:40
nginx: configuration file /etc/nginx/nginx.conf test failed

这是因为ModSecurity中的IP检测的功能还没有添加,暂时可以先不考虑这个,直接删掉或者重命名掉不加载即可:

mv /etc/nginx/owasp/rules/REQUEST-910-IP-REPUTATION.conf /etc/nginx/owasp/rules/REQUEST-910-IP-REPUTATION.conf.bak

测试无误后重启nginx服务,务必使用restart而不是reload等操作。

三、测试

3.1 正常访问

maqian@Inspiron:~$ curl http://localhost -I
HTTP/1.1 200 OK
Server: nginx/1.12.2
Date: Sat, 01 Jun 2019 13:00:38 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Sat, 01 Jun 2019 12:34:27 GMT
Connection: keep-alive
ETag: "5cf270d3-264"
Accept-Ranges: bytes

返回200,正常访问。

3.2 简单SQL注入

maqian@Inspiron:~$ curl 'http://localhost/?id=1 AND 1=1' -I
HTTP/1.1 403 Forbidden
Server: nginx/1.12.2
Date: Sat, 01 Jun 2019 13:01:30 GMT
Content-Type: text/html
Content-Length: 169
Connection: keep-alive

返回403,禁止访问。

3.3 简单xss攻击

maqian@Inspiron:~$ curl 'http://localhost/?search=<scritp>alert('xss');</script>' -I
HTTP/1.1 403 Forbidden
Server: nginx/1.12.2
Date: Sat, 01 Jun 2019 13:01:15 GMT
Content-Type: text/html
Content-Length: 169
Connection: keep-alive

返回403,禁止访问。

四、日志

默认情况下,ModSecurity是开启了审计日志的,会把审计日志打到modsec_audit.log,以下就是上面执行xss攻击时候的日志:

---EmbUKKWv---A--
[01/Jun/2019:21:01:15 +0800] 155939407569.849497 127.0.0.1 58856 127.0.0.1 80
---EmbUKKWv---B--
HEAD /?search=<scritp>alert(xss);</script> HTTP/1.1
Host: localhost
User-Agent: curl/7.58.0
Accept: */*

---EmbUKKWv---D--

---EmbUKKWv---F--
HTTP/1.1 403
Server: nginx/1.12.2
Date: Sat, 01 Jun 2019 13:01:15 GMT
Content-Length: 169
Content-Type: text/html
Connection: keep-alive

同时nginx的日志中也有日志:

2019/06/01 21:01:15 [error] 30005#0: *3 [client 127.0.0.1] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `5' ) [file "/etc/nginx/owasp/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "79"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "127.0.0.1"] [uri "/"] [unique_id "155939407569.849497"] [ref ""], client: 127.0.0.1, server: localhost, request: "HEAD /?search=<scritp>alert(xss);</script> HTTP/1.1", host: "localhost"
2019/06/01 21:01:30 [error] 30005#0: *4 [client 127.0.0.1] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `7' ) [file "/etc/nginx/owasp/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "79"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 7)"] [data ""] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "127.0.0.1"] [uri "/"] [unique_id "155939409056.181076"] [ref ""], client: 127.0.0.1, server: localhost, request: "HEAD /?id=1 AND 1=1 HTTP/1.1", host: "localhost"

正式环境下,如果访问量很大,建议关闭审计日志,开启审计日志会导致以下问题:

  1. 写入大量的日志数据,会消耗磁盘容量。
  2. 大量的IO操作会影响设备的性能。

关闭审计日志需要在/etc/nginx/modsecurity.conf中添加配置:

SecAuditEngine off

五、优化

5.1 不检查静态内容

location / {
    modsecurity on;
    modsecurity_rules_file /etc/xxxx/main.conf;
    root html;
}
location ~ \.(gif|jpg|png|jpeg|svg)$ {
    root /data/images; 
}

六、参考文档

ModSecurity3_Nginx 指南

nginx下安装配置modsecurity waf防火墙(附完整编译、配置、排错、详细规则)

Nginx1.14.0+ModSecurity实现简单的WAF

一、适用场景

忘记了数据库密码,但是navicate中还保存了数据库的密码,能通过navicate连接数据库,不能手动输入密码登陆。不想改密码,希望能从navicate中得到保存的密码。

二、步骤

点击文件-导出连接

勾选上导出密码

然后打开刚刚导出的ncx文件,找到账号和密码部分的信息:

这里的密码是加密后的,想要解密的话需要还需要一点小操作。github上已经有开源的工具了,支持多种语言解密。详情可以参考:how-does-navicat-encrypt-password

使用python解密

要求电脑已经安装好python3,并且安装好了pycryptodomepypiwin32库。

把代码库下载下来,进入到python3目录,执行NavicatCipher.py dec -ncx xxxx即可得到解密后的密码,xxxx是上面复制的密码。

$ ./NavicatCipher.py enc "This is a test"
0EA71F51DD37BFB60CCBA219BE3A

$ ./NavicatCipher.py dec 0EA71F51DD37BFB60CCBA219BE3A
This is a test

$ ./NavicatCipher.py enc -ncx "This is a test"
B75D320B6211468D63EB3B67C9E85933

$ ./NavicatCipher.py dec -ncx B75D320B6211468D63EB3B67C9E85933
This is a test