ssh 蜜罐部署

前言

我记得以前玩 centos7 的时候,有一次新开服务器,服务器开完后我就碎觉了。第二天早上登录的时候看到有 一千五百个错误登录,感觉蛮烦的而且因为是新开所以没有设置 ssh key 还是有一定几率被攻破的。

关于 ssh 的防护修改一下 ssh 的默认监听端口就能免疫 99% 的爆破攻击。

既然别人想要爆破 我的 ssh 那不妨我直接开放 ssh ,毕竟我也想看看他们会做些什么。这就需要用到 ssh 蜜罐了,简单的说 ssh 蜜罐就是一个隔离的虚拟环境,让攻击者很容易打进来,并记录攻击者所留下来的印记,攻击者所获得的信息是你预先定义好的,有风险的指令并不会被真正的执行。

部署 ssh 蜜罐,不建议在生产环境下进行,建议一台单独的服务器进行部署。

ssh 蜜罐我使用的是 Cowrie,Cowrie 由 python 进行编写,我在 debian 默认源和 pip 仓库查看过并没有打包好的程序所以我们只有手动安装了。

Cowrie 开源在 github 感兴趣的朋友可以查看一下
https://github.com/cowrie/cowrie

本次安装在 debian9 下进行,理论上也适用于其他 linux 发行版。

修改 ssh 默认监听端口

在安装 Cowrie 之前 先修改一下默认的 ssh 端口把 22 端口让出来,如果不使用 22 端口的话可能很久都等不到攻击者。

用你喜欢的编辑器打开 /etc/ssh/sshd_config找到 #Port 22 这一行并将其修改为 Port 233 保存后退出。

重启一下 ssh 服务

/etc/init.d/ssh restart

退出 ssh 使用你的新 ssh 端口连接 ssh ,接下来就开始正式安装了。

安装并配置 Cowrie

由于未在 pip 仓库找到打包好的 Cowrie 所以我们只有自行安装了。

更新软件源

sudo apt update

更新本机软件

sudo apt upgrade

安装 Cowrie 需要的依赖

sudo apt install -y virtualenv python3 python3-pip authbind git

为了增加安全性我们新建一个普通用户用来专门运行 Cowrie,新建的时候一路回车,直至用户建立完成

sudo adduser --disabled-password cowrie

使用 authbind 以让 cowrie 有能力使用 22 端口

sudo touch /etc/authbind/byport/22

将权限修改为 cowrie 用户

sudo chown cowrie:cowrie /etc/authbind/byport/22

接下来切换到 cowrie 用户

sudo su - cowrie

克隆 cowrie 的储存库

git clone http://github.com/cowrie/cowrie

进入 cowrie 目录开始正式安装

cd cowrie

创建一个 python env 环境用于运行 cowrie,别问我为什么这样做因为这样最简单

virtualenv --python=python3 cowrie-env

进入 env 环境

source cowrie-env/bin/activate

在 env 环境里安装 cowrie

pip install -r requirements.txt

安装好后退出 env 环境

deactivate

复制演示配置文件为配置文件

cp etc/cowrie.cfg.dist etc/cowrie.cfg

用例喜欢的编辑器编辑 etc/cowrie.cfg#listen_port = 2222 改为 listen_port = 22,将 listen_endpoints = tcp:2222:interface=0.0.0.0 改为 listen_endpoints = tcp:22:interface=0.0.0.0。改好后保存退出

接下来就可以启动 Cowrie 了

启动 Cowrie

authbind --deep bin/cowrie start

到这里我们的安装以及配置也就算了完成了,接下来我们可以退出 cowire 用户了,输入 exit 退出当前用户(cowire用户),可以使用 ssh [email protected] 测试一下,密码请随意输入。你在蜜罐里执行的所有操作都将记录在 /home/cowrie/cowrie/var/log/cowrie

扩展阅读

如果你对 Cowire 的配置文件进行了修改,需要对 Cowire 进行重启,当然这些操作都是在 cowire 用户下进行的。例如:authbind --deep bin/cowrie restart

当然 Cowire 记录的数据也是可以保存到数据库的在这里就不进行演示了

在 cowire 储存库下的 etc 目录里有一个名为 userdb.example 的文件可以将它复制并重命名为 userdb.txt 这个文件的作用是定义允许登录 ssh 蜜罐 的 ssh 用户名和密码。格式类似于这样

[username]:x:[password]

其配置文件支持简单的正则表达式 * 表示接受所有密码 ! 代表不接受的密码,具体实例可以在 userdb.example 中进行查看

将 cowrie 收集的数据放进数据库

为了方便分析,我们可能需要将数据放进数据库,例如 mysql等。本小结是后来加上的,如果你想很好的使用本小结可能需要会一点的的数据库知识。我个人的使用方式,蜜罐再一台单独的 vps ,数据在我的生产环境。部分参考的官方储存库里的文档路径在 cowrie/docs/sql/README.rst

本文使用的 debain 进行演示,又于 debian 的默认从某个时刻开始 就不再包含 mysql,我们使用它的替代品 maeiadb 进行演示,关于 debian 为什么抛弃 mysql,其实不止 debian 抛弃了,fedora contos 也抛弃了。至于它们为什么同时抛弃了 mysql ,这就是另外一个精彩的故事了。这里我们只需要知道 mariadb 完全可以替代 mysql 就行了。

本小结的演示我将演示重要代码,一步一步的演示头皮痛,毕竟数据库还有一些前期操作要做,例如 :mysql_secure_installation

好了不多 bb 了,接下来就开始了

安装 mariadb 以及必要依赖

sudo apt install mariadb-server libmariadb-dev-compat python3-mysqldb

这里 mariadb-server 替代的 mysql , libmariadb-dev-compat 替代的 libmysqlclient-dev

进入 mariadb

sudo mysql

创建 一个数据库用来储存 cowrie 收集的数据

CREAT cowrieDB

再创建一个用户用来操作 刚才创建的数据库,这里用户名我用的 cowrie 密码用的 123456

CREATE USER 'cowrie'@'%' IDENTIFIED BY '123456';

将 cowrieDB 的所有操作权限授予 cowrie 用户

GRANT ALL ON cowrieDB.* TO 'pig'@'%';

进入 cowrieDB 数据库,准备导入数据

USE cowrieDB

接下来开始导入数据,需要导入的数据在 项目文件路径之下,名为 /cowrie/docs/sql/mysql.sql 这里视你的项目 clone 位置进行导入,这里我按我的位置进行导入

source /home/cowrie/cowrie/docs/sql/mysql.sql

数据库的设置到这里就完成了,按 CTRL + c 退出 mariadb

切换到 cowrie 用户

sudo su - cowrie

用你喜欢的编辑器编辑 cowrie 的配置文件 cowrie/etc/cowrie.cfg,找到下列这几行

#[output_mysql]
#enabled = false
#host = localhost
#database = cowrie
#username = cowrie
#password = secret
#port = 3306
#debug = false

取消注释并修改为

[output_mysql]
enabled = true
host = localhost
database = cowrieDB
username = cowrie
password = 123456
port = 3306
debug = false

修改完重启一下

authbind --deep cowrie/bin/cowrie restart

然后去喝杯咖啡等一会登入你的数据库,就能查看攻击记录了

记录查询

SELECT * from input; 执行的命令

SELECT * from sessions; 登陆IP

SELECT * from auth; 尝试登陆的用户名和密码

有意思的命令

在对数据收集的过程中发现了几个有意思的命令

unset HISTORY HISTFILE HISTSAVE HISTZONE HISTORY HISTLOG WATCH ; history -n ; export HISTFILE=/dev/null ; export HISTSIZE=0; export HISTFILESIZE=0 ; rm -rf /var/log/wtmp ; rm -rf /var/log/lastlog ; rm -rf /var/log/secure ; rm -rf /var/log/xferlog ; rm -rf /var/log/messages ; rm -rf /var/run/utmp ; touch /var/run/utmp ; touch /var/log/messages ; touch /var/log/wtmp ; touch /var/log/messages ; touch /var/log/xferlog ; touch /var/log/secure ; touch /var/log/lastlog ; rm -rf /var/log/maillog ; touch /var/log/maillog ; rm -rf /root/.bash_history ; touch /root/.bash_history ; history -r 这个简单虽然长了一点至少还能看的懂

echo -e '\x47\x72\x6f\x70/dev/shm' > /dev/shm/.nippon; cat /dev/shm/.nippon; rm -f /dev/shm/.nippon 这句才看到的时候我是比较懵逼的,其实关键字是 \x47\x72\x6f\x70 ,别问我是怎么定位到这几个字的只能说是直觉。简单的说这句命令,就是你用你的服务器破解下一台服务器,具体可查看 https://security.stackexchange.com/questions/158169/bot-called-gweerwe323f-accesing-ssh 。基于这样一个设定,我突然想到一个不错的设计,我感觉 ssh 攻击瓶颈不在性能,而是 一个 IP 的请求不能太频繁 如果每破解一台 服务器 都能为这套系统增加能力,这是很可观的也是我之前没有想到过的。也许正在攻击里的 IP 也是受害者的服务器了,但是谁有说的准了

参考

https://nxnjz.net/2019/01/deploying-an-interactive-ssh-honeypot-on-debian-9/

0%