BLOG和FREESHELL出现故障，正在抢修中

[Yifan Gao]

非常抱歉得通知大家，从今天凌晨2：00开始，blog数据库无法响应部分查询请求。今天早晨发现数据库损坏。因此我们暂时关闭了blog的访问。

维护人员正在从备份恢复数据库。同时，由于freeshell和blog共享同一个mysql数据库，因此在恢复数据期间freeshell也将无法访问。

考虑到用于发布服务器故障通知的servers.blog.ustc.edu.cn 也受到波及，因此在邮件列表中通知大家。如有打扰，敬请谅解。

维护人员正在全力恢复blog和freeshell，请大家耐心等待，如有任何疑问，请致信 lug (AT) ustc.edu.cn。

—

Yifan Gao

[Bojie Li]

此外，今天中午 11:54，LUG 服务器（lug.ustc.edu.cn）也突然失联，我们正在联系图书馆机房工作人员进入抢修。

订购版衫的同学可能无法访问 LUG wiki，请移步 BBS Linux 版：http://bbs.ustc.edu.cn/cgi/bbstcon?board=Linux&file=M.1432879981.A

非常抱歉此次故障给大家带来的不便。

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
To post to this group, send email to ustc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bojie Li]

Yifan Gao 已经修好了 lug 服务器（重启大法），现在 lug 主页已经能正常访问了。

blog 还在抢修中。

[Bojie Li]

刚才（19:52），lug.ustc.edu.cn 和 mirrors.ustc.edu.cn 两台服务器同时失联。会长、CTO 进入网络中心修复 mirrors，目前已经修复。lug 服务器在西区，需要多等一会儿了。

目前受影响的服务包括 lug, blog, gitlab 三台服务器。受影响的服务还包括 freeshell 控制面板、防污染 DNS 等。非常抱歉！

[Bojie Li]

现在 vpn 服务器也跪掉了，症状和 blog 服务器基本相同。真是黑色儿童节啊……

此外今天下午发现 gitlab 服务器所在的 VMWare 虚拟化节点无法执行 RDP 备份、恢复，因此被破坏的 gitlab 服务器暂时无法恢复。

我们有可能正在受到攻击，这是 LUG 服务器有史以来最严重的一次服务故障，几乎所有服务全线瘫痪。

[崔灏 (CUI Hao)]

基本可以确认有服务器被入侵了。

--

崔灏 / CUI Hao
Homepage: i-yu.me
Twitter: @cuihaoleo

[Hao Wang]

加油，这应该是近期最严重的攻击了吧。。

话说攻击来源能看出来么，hacker 没留下什么东西？

[Zebo Wen]

辛苦了

在 2015年5月31日星期日 UTC+8下午12:43:10，Yifan Gao写道：

[linda linda]

现在 gitlab 和  freeshell 恢复了。  freeshell  虚拟机上好像还是ping 不通外网

vpn  什么时候好。

在 2015年5月31日星期日 UTC+8下午12:43:10，Yifan Gao写道：

非常抱歉得通知大家，从今天凌晨2：00开始，blog数据库无法响应部分查询请求。今天早晨发现数据库损坏。因此我们暂时关闭了blog的访问。

[Bojie Li]

请大家关注 LUG 服务器博客 https://servers.ustclug.org/

目前 LUG 各网络服务的状态如下。

受到黑客入侵影响，已经完全恢复的：

• 代码托管服务 GitLab
• LUG 主页
• 防污染 DNS

受到黑客入侵影响，尚未完全恢复的：

• Mirrors：服务可用性受到影响不大，但部分软件源的文件被篡改，正在重新同步。
• Blog：6月5日晚上修复了已经注册的博客到5月30日的完整备份。由于安全原因，暂停注册新 blog，暂停 blog FTP 服务（PASV 模式对防火墙不友好）。
  

受到黑客入侵影响，暂时关闭的：

• Freeshell：控制面板修好后又发现运算节点被入侵，现已临时关闭。关闭之前的一段时间无法访问外网是因为 VPN 挂了。如果着急要数据，可以给我们发邮件 https://servers.ustclug.org/2015/06/freeshell-worker-node-attacked/
• VPN：暂时关闭。正在开发测试更安全的新架构，将在合适的时间重新审核发放 VPN 账号密码。
  
• LUG FTP 和 LUG 主页上的一些资源：尚未恢复，但没有数据丢失。
  
• TimeMachine：暂时关闭。如果着急要数据，可以给我们发邮件。
• 谷歌字体代理：尚未恢复。

暂未受到黑客入侵影响的：

• PXE
• 白帽子网站
  
• 权威 DNS
• 内部账号系统和虚拟化基础架构

由于考试周快到了，大家都要复习，技术组已经为修复服务忙碌一周了。我们准备借这个机会对我留下的一些烂摊子进行重构，因此可能要到期末考试后才能继续修复。非常抱歉我的账号被入侵给技术组和各位用户带来这么多麻烦，也希望大家能给予我们理解与支持！

2015-06-01 21:10 GMT+08:00 Tianyu Pan <pantia...@gmail.com>:

作为vpn用户刚想反应情况。。关注事态。

在 2015年6月1日星期一 UTC+8下午8:44:44，Bojie Li写道：

[linda linda]

额  看来一段时间用不了 vpn 了  ，  有替代翻墙方法么？  目前 

自己申请 vpn 怎么玩

You received this message because you are subscribed to a topic in the Google Groups "USTC_LUG" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ustc_lug/tEOZ3NZPJLM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ustc_lug+u...@googlegroups.com.

[old9]

cft…… 你帐号被入侵？什么情况？

另外，白帽子比赛的漏洞已经报告给网络中心了么？为啥我管着的几个服务器没有收到详细细节呢？

[Bojie Li]

想自建梯子的话，推荐使用 shadowsocks，当然这个需要国外 VPS。在国外买个 VPS 吧，比如 DigitalOcean（新加坡）、Conoha（日本），都是比较便宜的。
国内也有一些不错的商业 VPN 服务，可以上 v2ex 看看。

对了，本邮件列表的 Archive 目前也没有修复。服务太多，我们自己都记不住了……

[Bojie Li]

初步调查，cracker 通过某种未知方式，替换了我 Windows 8.1 里的 cygwin1.dll。这个 dll 篡改了 PTY handler 部分的源码，监控 PTY slave 的读操作，把用户输入的键盘序列加以混淆并打上时间戳后存储在当前目录的 .stackdump 隐藏文件中。经过对此文件的逆向，恢复出了我近几天在 Cygwin 里输入的命令、密码、服务器上的操作等。由于我装的杀毒软件版本较低（学校版 ESET NOD32 4.0），没有报毒（学校版 NOD32 5.0 报毒了）。这个 dll 声称编译时间为5月24日，如果没有伪造，则入侵时间应该在此之后。cracker 通过某种未知方式取走并删除了 .stackdump 文件，还窃取了我的 SSH private key。

5月29日，blog 服务器上我的账号开始出现异常登录，并收集系统信息，由于没有登录提醒机制，日志又被破坏，不能完全确认 cracker 做了什么。5月31日凌晨2点左右，黑客通过 LUG VPN 和窃取到的密钥、密码登录各个服务器，再使用公共账号密码获取 root 权限（我4月底已经主动放弃了 sudo 权限，需要先进入公共账号才能做特权操作）。5月31日中午12点，黑客利用从 blog 服务器上窃取的 freeshell 控制 API 私钥和控制 API 中的命令注入漏洞，在 freeshell 计算节点上实现提权。

黑客在各个服务器里悄悄插入一个名叫 ext4progs.ko 的内核模块。该内核模块具有自我隐身功能，lsmod 和 /sys 里看不到。尽管我们没能查获该内核模块的样本，但通过内核调试，确认该恶意模块 hook 了网络 socket 关闭路径，每当一个网络 socket 关闭时，就向磁盘的某个分区随机写入一个字节。该模块似乎还有限速功能，避免给磁盘带来过高的写负载而被发现。硬盘上的文件系统就这样被悄悄破坏了。但这个恶意模块似乎有些 bug，偶尔会爆出内核栈，这给我们留下了查它的线索。基本上都是当文件被大量破坏、服务停止运行，或者恶意模块自身的 bug 导致内核崩溃后，才发现又一台服务器沦陷了。

详细的分析报告我有空再写。

白帽子比赛的漏洞似乎还没有报告，前些天我们都忙着修服务器去了…… @cuihao

[Zhuoyun Wei]

2015-06-08 15:58 GMT+08:00 Bojie Li <boj...@gmail.com>:

初步调查，cracker 通过某种未知方式，替换了我 Windows 8.1 里的 cygwin1.dll。这个 dll 篡改了 PTY handler 部分的源码，监控 PTY slave 的读操作，把用户输入的键盘序列加以混淆并打上时间戳后存储在当前目录的 .stackdump 隐藏文件中。经过对此文件的逆向，恢复出了我近几天在 Cygwin 里输入的命令、密码、服务器上的操作等。由于我装的杀毒软件版本较低（学校版 ESET NOD32 4.0），没有报毒（学校版 NOD32 5.0 报毒了）。这个 dll 声称编译时间为5月24日，如果没有伪造，则入侵时间应该在此之后。cracker 通过某种未知方式取走并删除了 .stackdump 文件，还窃取了我的 SSH private key。

5月29日，blog 服务器上我的账号开始出现异常登录，并收集系统信息，由于没有登录提醒机制，日志又被破坏，不能完全确认 cracker 做了什么。5月31日凌晨2点左右，黑客通过 LUG VPN 和窃取到的密钥、密码登录各个服务器，再使用公共账号密码获取 root 权限（我4月底已经主动放弃了 sudo 权限，需要先进入公共账号才能做特权操作）。5月31日中午12点，黑客利用从 blog 服务器上窃取的 freeshell 控制 API 私钥和控制 API 中的命令注入漏洞，在 freeshell 计算节点上实现提权。

黑客在各个服务器里悄悄插入一个名叫 ext4progs.ko 的内核模块。该内核模块具有自我隐身功能，lsmod 和 /sys 里看不到。尽管我们没能查获该内核模块的样本，但通过内核调试，确认该恶意模块 hook 了网络 socket 关闭路径，每当一个网络 socket 关闭时，就向磁盘的某个分区随机写入一个字节。该模块似乎还有限速功能，避免给磁盘带来过高的写负载而被发现。硬盘上的文件系统就这样被悄悄破坏了。但这个恶意模块似乎有些 bug，偶尔会爆出内核栈，这给我们留下了查它的线索。基本上都是当文件被大量破坏、服务停止运行，或者恶意模块自身的 bug 导致内核崩溃后，才发现又一台服务器沦陷了。

这邮件看得我心惊肉跳的……

之前的邮件里 Bojie 说账号被盗我以为是弱密码、撞库等简单的「脚本小子」级别的入侵，心想大神也有被宵小算计的时候，没想到竟然是如此有针对性(?)的入侵啊……

--

Zhuoyun Wei

[赵锦威]

看起来这是一次有预谋且精心策划的攻击，好可怕

===

Best Regards!

Jinwei Zhao(赵锦威)

(clar...@gmail.com)

Open Source Community of

Zhejiang Gongshang University

--

[old9]

听着惊心动魄的，该不是被白帽子比赛引过来的吧……

[Zhuoyun Wei]

2015-06-08 20:23 GMT+08:00 old9 <qi.j...@gmail.com>:

听着惊心动魄的，该不是被白帽子比赛引过来的吧……

白帽子不会干破坏文件系统这么恶劣的事情吧……

之前不是有人说可能是 LUG VPN 引来的么……（阴谋论：GFW 御用 cracker）

--

Zhuoyun Wei

[Bojie Li]

2015-06-08 15:58 GMT+08:00 Bojie Li <boj...@gmail.com>:

初步调查，cracker 通过某种未知方式，替换了我 Windows 8.1 里的 cygwin1.dll。这个 dll 篡改了 PTY handler 部分的源码，监控 PTY slave 的读操作，把用户输入的键盘序列加以混淆并打上时间戳后存储在当前目录的 .stackdump 隐藏文件中。经过对此文件的逆向，恢复出了我近几天在 Cygwin 里输入的命令、密码、服务器上的操作等。由于我装的杀毒软件版本较低（学校版 ESET NOD32 4.0），没有报毒（学校版 NOD32 5.0 报毒了）。

纠正一下，学校版 NOD32 5.0 报毒是我室友说的…… 我用学校版 NOD32 5.0 和卡巴斯基都没有检测出威胁。 zhsj 把这个文件提交到几个在线平台，也没有检测出威胁。我把这个文件的反汇编码和同一版本的正常 cygwin1.dll 进行对比，发现只有 PTY handler 这一部分发生了改变，如果没有已知的木马使用这种特征码，应该不会被识别为威胁。

我已经把该文件上传，大家可以去分析。

http://home.ustc.edu.cn/~boj/keylogger/cygwin1.dll

测试方法：首先安装 cygwin 64 位版，把该文件覆盖掉 Cygwin 安装目录下的 bin/cygwin1.dll，然后在非 cygwin 环境下（如 cmd）执行 rebaseall（由于不同版本的 cygwin dll 的堆基地址不同，直接覆盖可能无法运行）。黑客估计是事先通过某种方式知道了我的 cygwin 版本，然后放了对应的 cygwin1.dll 进去。

[Bojie Li]

2015-06-08 20:23 GMT+08:00 old9 <qi.j...@gmail.com>:

听着惊心动魄的，该不是被白帽子比赛引过来的吧……

这个确实有可能……我在白帽子比赛之前曾经放话，不仅希望看到 XSS、SQL 注入之类的应用漏洞，更希望看到从应用漏洞实现任意命令执行，到沙盒逃逸，再本地提权拿到 root 的漂亮的攻击，让我们开开眼。可能是这个吸引来了真正厉害的黑客。

其实在 5 月 21 日（白帽子大赛期间），我的电脑就已经被种上了 webshell，以我的电脑作为跳板，用齐博 CMS 的漏洞黑掉了学校两个不堪一击的网站，并用伪造的身份在白帽子大赛网站上提交了漏洞。由于违反了不准搞破坏的比赛规则，我们开始让 james 帮忙调查，当天就查到是我的电脑被当成肉鸡了。这事发生之后我修改了密码和 SSH 私钥，但有部分服务器上的公钥没有 revoke，而密码估计是此后黑客才通过键盘记录器拿到的。

我有很多服务器的账号，但就目前掌握的情况来看，受到攻击的只有 LUG 的服务器，可见 cracker 的意图很明确，就是以我为跳板来攻击 LUG 网络服务。

道高一尺，魔高一丈，千万别招惹黑客。

[ternnence]

话说blog和freeshell的用户名和密码有没有泄露的危险呢？

如果有还是发个通告吧

[王冠]

服务器上应该不会作死存明文密码吧！

在 2015年6月9日星期二 UTC+8下午7:15:48，ternnence写道：

[Alkaid]

没有明文，更应该关心的是用户的个人数据泄没泄漏，虽然就算泄漏也做不了什么了。

ternnence <twy...@gmail.com>于2015年6月9日星期二写道：

[Zhuoyun Wei]

2015-06-09 13:46 GMT+08:00 Bojie Li <boj...@gmail.com>:
> 纠正一下，学校版 NOD32 5.0 报毒是我室友说的…… 我用学校版 NOD32 5.0 和卡巴斯基都没有检测出威胁。 zhsj
> 把这个文件提交到几个在线平台，也没有检测出威胁。我把这个文件的反汇编码和同一版本的正常 cygwin1.dll 进行对比，发现只有 PTY
> handler 这一部分发生了改变，如果没有已知的木马使用这种特征码，应该不会被识别为威胁。

这样看来真的是专门针对你的作品而不是公版产品啊……好可怕……

--
Zhuoyun Wei

[Rizza Ssz]

很奇怪是怎么中上这个dll的？难道是某同学手工拷进去的？还是win的某个未知漏洞？

[linda linda]

vpn  有人管么      没有vpn 不幸福啊

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en
---

You received this message because you are subscribed to a topic in the Google Groups "USTC_LUG" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ustc_lug/tEOZ3NZPJLM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ustc_lug+u...@googlegroups.com.

[Zhen Chang]

我贡献下自己的shadowsocks吧。配置在ss.ibat.me。只是自己的博客服务器，除了自己没什么人用。别做违法美国法律的事情就行（比如挂bt）。

You received this message because you are subscribed to the Google Groups "USTC_LUG" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.

[Bojie Li]

2015-06-10 9:22 GMT+08:00 Rizza Ssz <rizza2...@gmail.com>:

很奇怪是怎么中上这个dll的？难道是某同学手工拷进去的？还是win的某个未知漏洞？

我觉得以下两种可能性比较大：

(1) 通过 Windows 或者浏览器、PDF 阅读器等软件的 0day。0day 对大多数人（比如我）来说很难找到，但对有积累的安全组织来说并不难。一个白帽子组织遵循一定的代码审计和渗透测试方法，可以相对稳定地发现 0day。黑帽组织的技术实力也没有理由差很多。不过，发现 0day 距离利用 0day 还有很大距离。发现一个缓冲区溢出漏洞也许不难，但要利用这个漏洞执行任意代码，而不只是让目标崩溃，却是难比登天。

(2) 通过 U 盘等传播。前些天发现张静宁的 Win8.1 出现异常行为，怀疑是感染病毒导致的，于是在备份数据到移动硬盘、格式化本地硬盘后，对移动硬盘和 U 盘进行了全面扫描。在移动硬盘里发现一个 autorun 类型的木马，还有一个目录里有上百个病毒样本，另有两个流氓软件。在 U 盘里发现了一个 autorun 类型的木马（与移动硬盘里的那个不同）和若干受该木马感染的文件夹。由于我已经重装系统，无法确认我的电脑是不是被这些木马感染过。这个 U 盘和移动硬盘近期都在我的电脑上用过，而且当时学校版的 ESET NOD32 4.0 没有报毒（不确定是杀软不给力，还是当时木马还没进来）。如果入侵者是通过这种方式进来，这绝对算得上是 APT（高级持续威胁）了。

[Bojie Li]

2015-06-10 9:42 GMT+08:00 linda linda <lds...@gmail.com>:

vpn  有人管么      没有vpn 不幸福啊

目前 VPN 和 freeshell 暂时保护性关闭。这两个服务的恢复计划相互独立。期末考试后我们会采用新架构进行重建，解决之前一些积重难返的问题。

4 月 29 日，在选课查询系统引起争端期间，LUG 现任核心会员开会，决定对现在管理比较混乱的一些网络服务进行重构。学习会议精神后，我考虑到本学期以来各种网络服务已经基本交接，新人们能够胜任维护工作，以及我即将离校，决定移交大部分服务器的权限，转向技术顾问。但当时权限移交得不够彻底，因此黑客在 5 月底还是通过我的账号入侵进多台服务器并取得了最高权限。

本次服务器受到黑客入侵，技术组花了很多时间和精力才修复。5 月 31 日以来的连续五个晚上，活动室 12 点之前还是灯火通明，Alkaid、Yifan 等同学甚至在通宵修复服务。我把这次服务恢复作为技术组熟悉网络服务的一个机会，没有直接插手服务恢复，只是做了一些必要的技术支持，比如升级和重新编译 PHP sandbox、调试内核调查问题原因。由于这些服务很多没有文档，而且原来是 wheezy 的系统升级到 jessie 之后也出现了一些不同，折腾了比较长时间。经过这次故障之后，技术组应该是能完全接手 LUG 现有的网络服务了。

[Zhang Cheng]

​非常赞！大家都辛苦了！

事故是最好的老师，打小怪升小级，打Boss成Boss！

--

Cheng,

Best Regards

[Bojie Li]

这个事情感觉是蛮蹊跷的，我们已经找 jameszhang 聊过了。基本上一手搭建了科大整个校园网络，把大半辈子都奉献给了科大校园网和安徽省教育网的 james 老师说，没见过影响这么恶劣的入侵事件。按照常理，黑客要么是悄悄地来，偷走了敏感数据又悄悄地走；要么是改首页挂个黑页，或者通过其他途径公布 “战果” 来炫耀；要么是植入木马，悄悄地感染访问者（例如篡改 mirrors 上的软件包）。把数据都破坏掉又不留名的黑客还没见过。我本人和 LUG 也没有招惹什么人，不应该是出于 “报仇”。大概是一个想锻炼技术、获得成就感的黑客，又不讲道德，不懂道上的规矩，进来之后就大搞破坏。

这个入侵过程大致梳理如下：

1. 入侵妹子电脑（猜的）
2. 在 U 盘里植入木马（猜的）
3. 木马感染我的电脑（猜的）
4. 5.20 晚，浏览器中 webshell
5. 5.21 凌晨，用浏览器作为跳板攻陷学校两个网站，并在白帽子大赛报漏洞
6. 5.24 晚，在 cygwin 里放键盘记录器
7. 取走键盘记录和 SSH key
8. 5.29 至 5.30，登录服务器搜集信息
9. 5.31 凌晨，用窃取的密码密钥登录各服务器，并用公共账号密码提权
10. 5.31 凌晨，在 mirrors 服务器上修改另一用户的密码，并从国外登录
11. 5.31 中午，找到 freeshell 控制 API 的注入漏洞，从控制节点获取计算节点 root 权限
12. 在获取到 root 的各服务器上插入隐藏的内核模块，一有网络连接就随机破坏硬盘数据（其中搞 mirrors 的时候搞挂重启了一次）
13. 破坏部分日志，走人
    
14. 服务恢复过程中，利用没来得及 revoke 的密码密钥登录服务器（猜的），再次插入恶意内核模块，形成内核模块会开机自启动的假象（事实上该恶意模块并没有保存在硬盘上，重启即失）
15. 服务恢复后仍然念念不忘，又发起漏洞扫描，导致 blog 服务器日志填满硬盘

如果攻击路径真的是这样，可以算得上 APT 攻击了吧……（当然，黑客是不是还干了其他坏事，只有天知道）其中 cygwin 键盘记录器和服务器上的恶意内核模块都应该是没有大范围传播的，有可能是该黑客自用的工具，甚至为了此次攻击专门写的工具。不知道这次成功的入侵背后有多少次失败的尝试，这个攻击的成本我估计至少是六位数了吧。

能被作为 APT 攻击的目标，我感觉还是蛮 “荣幸” 的，原来我有这么高的入侵价值（是不是想多了）。大多数小伙伴甚至公司，恐怕从来没有遇到这么高级和针对性的入侵吧。这也让我们刷新了三观，什么 Win8 裸奔也很难中毒，Chrome 浏览器很安全，Win8 很难放键盘记录器（人家是放到了 cygwin 里），公共密码只有内部知道无所谓，开了 AppArmor 就可以阻止大部分入侵，内部 API 没有人会注入，都是没有见过真正黑客的人的心理安慰。安全一定要纵深防御：

• 技术人员的个人电脑（退 Windows 保平安、用靠谱的杀软）
• 服务器账号认证和授权体系（两步验证？限制内网访问？）
• 服务器上的监控和日志机制
• 内核模块签名
  
• 内部 API 也要防注入
• 数据完整性校验（在恶意模块被插入后的一小时内，MySQL 就崩溃了，因为它检测到数据表文件 CRC 不一致。而其他应用都开心地运行着）

[Hugo]

我对防御中第二条 “服务器账号认证和授权体系（两步验证？限制内网访问？）” 有兴趣，这种情况下如果把服务器登陆限制在一个专用 vpn 网络内，并且登陆 vpn 网络本身需要来源于不同设备的多因素认证（比如电脑上的证书+手机上的验证码），会有多大帮助？

此外，我有个建议。恢复 freeshell 后，能不能在网页控制台上增加用 ssh key 新建服务器的功能？最好把密码登录默认禁止掉。。。

这次的事情看上去好厉害的样子（其实我什么都不懂 -_-!），祝愿 lug 的服务能早日恢复！

On 2015年06月14日 01:31, Bojie Li wrote:

2015-06-08 20:24 GMT+08:00 Zhuoyun Wei <wzyb...@gmail.com>:

2015-06-08 20:23 GMT+08:00 old9 <qi.j...@gmail.com>:

听 着惊心动魄的，该不是被白帽子比赛引过来的吧……

白帽子不会干破坏文件系统这么恶劣的事情吧……

之前不是有人说可能是 LUG VPN 引来的么……（阴谋论：GFW 御用 cracker）

这个事情感觉是蛮蹊跷的，我们已经找 jameszhang 聊过了。基本上一手搭建了科大整个校园网络，把大半辈子都奉献给了科大校园网和安徽省教育网的 james 老师说，没见过影响这么恶劣的入侵事件。按照常理，黑客要么是悄悄地来，偷走了敏感数据又悄悄地走；要么是改首页挂个黑页，或者通过其他途径公布 “战果” 来炫耀；要么是植入木马，悄悄地感染访问者（例如篡改 mirrors 上的软件包）。把数据都破坏掉又不留名的黑客还没见过。我本人和 LUG 也没有招惹什么人，不应该是出于 “报仇”。大概是一个想锻炼技术、获得成就感的黑客，又不讲道德，不懂道上的规矩，进来之后就大搞破坏。

这个入侵过程大致梳理如下：

1. 入侵妹子电脑（猜的）
2. 在 U 盘里植入木马（猜的）
3. 木马感染我的电脑（猜的）
4. 5.20 晚，浏览器中 webshell
5. 5.21 凌晨，用浏览器作为跳板攻陷学校两个网站，并在白帽子大赛报漏洞
6. 5.24 晚，在 cygwin 里放键盘记录器
7. 取走键盘记录和 SSH key
8. 5.29 至 5.30，登录服务器搜集信息
9. 5.31 凌晨，用窃取的密码密钥登录各服务器，并用公共账号密码提权
10. 5.31 凌晨，在 mirrors 服务器上修改另一用户的密码，并从国外登录
11. 5.31 中午，找到 freeshell 控制 API 的注入漏洞，从控制节点获取计算节点 root 权限
12. 在获取到 root 的各服务器上插入隐藏的内核模块，一有网络连接就随机破坏硬盘数据（其中搞 mirrors 的时候搞挂重启了一次）
13. 破坏部分日志，走人
    
14. 服务恢复过程中，利用没来得及 revoke 的密码密钥登录服务器（猜的），再次插入恶意内核模块，形成内核模块会开机自启动的假象（事实上该恶意模块并没有保存在硬盘上，重启即失）
15. 服务恢复后仍然念念不忘，又发起漏洞扫描，导致 blog 服务器日志填满硬盘

如果攻击路径真的是这样，可以算得上 APT 攻击了吧……（当然，黑客是不是还干了其他坏事，只有天知道）其中 cygwin 键盘记录器和服务器上的恶意内核模块都应该是没有大范围传播的，有可能是该黑客自用的工具，甚至为了此次攻击专门写的工具。不知道这次成功的入侵背后有多 少次失败的尝试，这个攻击的成本我估计至少是六位数了吧。

能被作为 APT 攻击的目标，我感觉还是蛮 “荣幸” 的，原来我有这么高的入侵价值（是不是想多了）。大多数小伙伴甚至公司，恐怕从来没有遇到这么高级和针对性的入侵吧。这也让我们刷新了三观，什么 Win8 裸奔也很难中毒，Chrome 浏览器很安全，Win8 很难放键盘记录器（人家是放到了 cygwin 里），公共密码只有内部知道无所谓，开了 AppArmor 就可以阻止大部分入侵，内部 API 没有人会注入，都是没有见过真正黑客的人的心理安慰。安全一定要纵深防御：

• 技术人员的个人电脑（退 Windows 保平安、用靠谱的杀软）
• 服务器账号认证和授权体系（两步验证？限制内网访问？）
• 服务器上的监控和日志机制
• 内核模块签名
  
• 内部 API 也要防注入
• 数据完整性校验（在恶意模块被插入后的一小时内，MySQL 就崩溃了，因为它检测到数据表文件 CRC 不一致。而其他应用都开心地运行着）

[Bojie Li]

2015-06-14 16:39 GMT+08:00 Hugo <hu...@fireuponsky.com>:

我对防御中第二条 “服务器账号认证和授权体系（两步验证？限制内网访问？）” 有兴趣，这种情况下如果把服务器登陆限制在一个专用 vpn 网络内，并且登陆 vpn 网络本身需要来源于不同设备的多因素认证（比如电脑上的证书+手机上的验证码），会有多大帮助？

去年底 Google 发了一篇论文说它将不再区分内外网，逐步淘汰内网 VPN。也就是所有公司内部网络服务公网可见，依靠客户端证书、客户端信用分级和单点登录系统来完成认证。这个原因主要是公司内网的边界不能完全信任。

Google 这么说，是因为 Google 是有名的对员工信任，在公司网络内不设防。有传言说普通的 Google 员工就可以拿到 95% 以上的公司内部代码。但 2010 年，据传言中国的工程师窃取了谷歌内部代码并用来攻击 Gmail，公司内部的墙就逐渐加高了。Google 这次说的不再区分内外网，要结合其公司文化才能理解。主要强调的是内部网络不可信任，各种内部应用需要使用单点登录，并重视应用程序自身的安全性。Google 就算不再区分内外网，也不可能 ssh google.com 就能直接登录进服务器（IP 地址都不够！）更不可能某员工在家里登录一个 Web 系统，就能把用户数据下载下来。

MS 内部的邮件 Outlook 和即时通信 Lync 就是从公网可以访问的。在手机上要使用公司 Exchange 账号的话，需要设置锁屏密码，这就是对终端安全的一种强制要求。当然公司的大多数内部服务仍然是只能内网可见，需要连 VPN 才能使用。MS 内网除了使用不同权限的 “域” 来控制访问范围，每种资源还有自己的授权机制。MS 的域机制，跟 Google 正在推行的机制并没有很多区别：单点登录之后对用户的终端认证，然后访问各种域内资源可以分别授权。MS 是操作系统公司，用的是操作系统级的认证；Google 是网络公司，是在 Web 上做的认证。这体现了 “纵深防御” 和 “最小权限原则”：关键服务要有多层防护，一层网络防火墙，还有一层应用认证授权。对于潜在的入侵者来说，找到入口是很重要的一件事，如果服务都暴露在公网上，那么入口直接就暴露在外了。需要利用公司内部的肉鸡做跳板，这就提高了入侵门槛。

内外网的另外一点区别是 traceability（可追踪性）。大公司内网上的网络行为都会受到监控和记录，如果突然有异常流量就会触发警报。Internet 上用肉鸡干了坏事，却是很难追查的。比如 Google 的单点登录暴露在外，如果设计并发量是不超过几万，我调集几十万肉鸡去 DDoS，这个单点登录入口就卡死了；但如果限制公司内网可见，谁在公司内部对单点登录系统发起 DoS 攻击，那是一查一个准。

Google 这个论文给我最大的启示是：终端安全（包括客户端和服务器）才是最重要的，网络上的防火墙和入侵检测系统都是次要的。比如我们 LUG 的网络服务暴露在公网上，没有防火墙，也很少被发现应用层面的漏洞；学校的大多数网站躲在 WAF（revproxy.ustc.edu.cn）后面，但还是难逃各种注入；这次黑客通过入侵我的个人电脑窃取了密码密钥，也是我从未想到的入侵途径。一个不安全的终端系统（客户端或者服务器软件），不论网络上加多少防火墙、入侵检测系统（IDS），也只是在增加入侵的难度。

因此我赞成采取大多数公司的做法，把服务器登录限制在一个专用 VPN 网络里。同时也不要给这个 VPN 网络太多信任，VPN 只是一种辅助手段，还是要加固客户端和服务器端的安全。比如：

• 给每个客户端颁发证书，仅有受信的证书才能登录 Web 内部系统，这比用户名密码方便又安全；
• SSH 只允许 key 登录，禁用密码登录，或者密码登录必须开启两步验证；
• 建立专门的日志服务器，各服务器把登录、sudo 等日志实时发送到日志服务器；
• 登录操作发邮件通知登录者；
• 每天把各服务器的登录、sudo、内核信息等发一封汇总邮件到管理员组。
  

此外，我有个建议。恢复 freeshell 后，能不能在网页控制台上增加用 ssh key 新建服务器的功能？最好把密码登录默认禁止掉。。。

SSH key 登录早就想有了……这是个好建议！

[hugo]

厉害，受教了。还有我觉得重要的日志连续的提交到一个权限控制细致，并且带版本控制的系统比较好。比如 amazon s3，可以保存所有的历史版本，并且可以控制访问权限，使得用户不能更改过去的版本。这样就可以防止入侵后日志被破坏。

 

发件人: ustc...@googlegroups.com [mailto:ustc...@googlegroups.com] 代表 Bojie Li
发送时间: 2015年6月14日 21:47
收件人: USTC_LUG
主题: Re: [USTC-LUG] BLOG和FREESHELL出现故障，正在抢修中

[Zhang Cheng]

2015-06-14 21:46 GMT+08:00 Bojie Li <boj...@gmail.com>:

因此我赞成采取大多数公司的做法，把服务器登录限制在一个专用 VPN 网络里。同时也不要给这个 VPN 网络太多信任，VPN 只是一种辅助手段，还是要加固客户端和服务器端的安全。比如：

• 给每个客户端颁发证书，仅有受信的证书才能登录 Web 内部系统，这比用户名密码方便又安全；
• SSH 只允许 key 登录，禁用密码登录，或者密码登录必须开启两步验证；
• 建立专门的日志服务器，各服务器把登录、sudo 等日志实时发送到日志服务器；
• 登录操作发邮件通知登录者；
• 每天把各服务器的登录、sudo、内核信息等发一封汇总邮件到管理员组。
  

​我觉得Google的做法，无论其内在的文化是什么样的，至少传达出了这样的意思：警告所有的人，每一个人，都要有安全意识，不能因为自己处在“内网”就觉得非常安全。

现在许多人（包括许多搞技术的人）都不是很在乎安全方面的问题，有些人是觉得自己没什么价值没有人对我感兴趣；有些人是觉得安全的事情跟我无关，公司的IT部门吃这碗饭的；而还有一些人对安全倒是重视，但是有着错误的安全观，觉得什么东西藏起来每人看见就安全了。

刚才在网络上看到一句话：

The commonly agreed upon tenants of strong security is that it requires a combination of "something you know, something you have, and something you are." Two factor authentication includes both of those - usually something you know and something you have.

在日常生活中还有一些简单易行的方案可以提高安全性。举例来说，不要将ssh key保存在电脑上，而是保存在U盘中。专门用一个U盘存放key，这个U盘可以随身携带，U盘本身加密存储。当要使用key时，插一下U盘用完就立刻拔掉，在自己常用的机器上，也可以插上U盘将key添加到ssh agent里面就把盘拔掉，这样在下一次重启之前都不需要再次插U盘了。这样，即使黑客入侵了电脑，除非蹲点很难获得你的key。这个U盘，建议选择支持物理只读锁的，日常使用时都物理只读，避免中毒。U盘里存放的东西也都要加密，ssh key本身支持加密，带有密码的key黑客拿到了也无法使用。

--

Cheng,

Best Regards

[Bojie Li]

2015-06-15 0:57 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

在日常生活中还有一些简单易行的方案可以提高安全性。举例来说，不要将ssh key保存在电脑上，而是保存在U盘中。专门用一个U盘存放key，这个U盘可以随身携带，U盘本身加密存储。当要使用key时，插一下U盘用完就立刻拔掉，在自己常用的机器上，也可以插上U盘将key添加到ssh agent里面就把盘拔掉，这样在下一次重启之前都不需要再次插U盘了。这样，即使黑客入侵了电脑，除非蹲点很难获得你的key。这个U盘，建议选择支持物理只读锁的，日常使用时都物理只读，避免中毒。U盘里存放的东西也都要加密，ssh key本身支持加密，带有密码的key黑客拿到了也无法使用。

这倒提醒我了，我觉得我们可以试试基于时间的动态令牌。银行是早就在用了，一些重视安全的互联网公司（如 DNSPod）也在推行自己的实体动态令牌。比起 Google Authenticator 之类，不必担心手机刷机后令牌丢失，或者手机感染木马后令牌被盗；缺点是要随身带着个实体的令牌，比较麻烦，而且这个小东西也可能会丢。

这种令牌有贵的也有便宜的，我找了一个比较便宜的，可以买来试试。

http://item.taobao.com/item.htm?spm=a1z10.5-c.w4002-1240213935.10.Nm8pWQ&id=10580856995

[Zhang Cheng]

2015-06-15 1:17 GMT+08:00 Bojie Li <boj...@gmail.com>:

这倒提醒我了，我觉得我们可以试试基于时间的动态令牌。银行是早就在用了，一些重视安全的互联网公司（如 DNSPod）也在推行自己的实体动态令牌。比起 Google Authenticator 之类，不必担心手机刷机后令牌丢失，或者手机感染木马后令牌被盗；缺点是要随身带着个实体的令牌，比较麻烦，而且这个小东西也可能会丢。

​随身带个小东西其实还好吧，挂载钥匙串上。​

这种令牌有贵的也有便宜的，我找了一个比较便宜的，可以买来试试。

http://item.taobao.com/item.htm?spm=a1z10.5-c.w4002-1240213935.10.Nm8pWQ&id=10580856995

​原来有这么便宜的解决方案。我前两年在公司还在讨论要不要使用基于硬件key的安全方案，不过当时只是讨论，没有实际去调研，以为这类方案成本会比较高。这种价格应该不错。

我现在在开发公司的一个后台管理系统，我不想使用基于密码的验证方案，因为运营人员对于密码的安全意识并不高，有时候会为了方便而将密码告诉其他人。而且这个后台还有一些用户并不在公司待着，IT管不着，也没法做安全培训。我现在计划的方案是使用一次一密，每次登录时发送一个随机密码到用户的手机上。如果这种动态令牌能很容易的集成到我们的系统里，那就太好了。

--

Cheng,

Best Regards

[Bojie Li]

2015-06-15 1:30 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

这种令牌有贵的也有便宜的，我找了一个比较便宜的，可以买来试试。

http://item.taobao.com/item.htm?spm=a1z10.5-c.w4002-1240213935.10.Nm8pWQ&id=10580856995

​原来有这么便宜的解决方案。我前两年在公司还在讨论要不要使用基于硬件key的安全方案，不过当时只是讨论，没有实际去调研，以为这类方案成本会比较高。这种价格应该不错。

刚发现这家竟然还卖加密狗。加密狗分发者首先使用一个自己设置的口令，把 RSA 公钥和私钥写进加密狗里，用户就可以用这个加密狗来加密数据，或者读取公钥来验证签名。加密算法是硬件的，私钥永不可被读出。这个加密狗的核心是个 51 单片机，可编程，可存储少量密码、密钥，也就是可以在加密狗里写入一段程序来完成自定义的加密、签名等功能。只要加密狗分发者的口令不被窃取（完全可以随机生成一个，用后即焚），就彻底杜绝了私钥泄露的问题。

http://item.taobao.com/item.htm?spm=2013.1.w4023-1240213930.7.dM0mV4&id=9260526965

看起来挺好的，可以买一个来玩玩。不知道是否容易跟 ssh、openvpn 之类的软件集成。

[Zhuoyun Wei]

2015-06-15 1:30 GMT+08:00 Zhang Cheng <steph...@gmail.com>:
> 原来有这么便宜的解决方案。我前两年在公司还在讨论要不要使用基于硬件key的安全方案，不过当时只是讨论，没有实际去调研，以为这类方案成本会比较高。这种价格应该不错。

我工作的公司里现在用的那套硬件令版 2FA 是我搭的，用的 RSA Labs 的产品 RSA SecurID，大概长这样：
https://upload.wikimedia.org/wikipedia/commons/8/8f/SecureID_token_new.JPG

这东西需要配合一台专门的认证服务器使用，每个 agent 需要和中心服务器进行 UDP 通讯，中心服务器返回「正确」或「错误」等结果（有点像 HSM？）。

Agent 支持安装在 Linux PAM 和 Windows 上，于是就给 GNU/Linux 跳板机开启了
2FA，登录跳板机需要输令牌上的数字。但是每次输有人嫌烦，GNU Screen / Tmux 又不是人人愿意用，最后的妥协就是
ControlMaster 了，在断网之前反复登录跳板机的话，只需一次 2FA，后续的不需要……

--
Zhuoyun Wei

[Zhuoyun Wei]

2015-06-14 1:31 GMT+08:00 Bojie Li <boj...@gmail.com>:
> 如果攻击路径真的是这样，可以算得上 APT 攻击了吧……（当然，黑客是不是还干了其他坏事，只有天知道）其中 cygwin
> 键盘记录器和服务器上的恶意内核模块都应该是没有大范围传播的，有可能是该黑客自用的工具，甚至为了此次攻击专门写的工具。不知道这次成功的入侵背后有多少次失败的尝试，这个攻击的成本我估计至少是六位数了吧。
>

那位 cracker 这么了解你（连你妹子是谁都找出来了），应该也在阅读本邮件列表吧？问问他/她？ :-)

> 能被作为 APT 攻击的目标，我感觉还是蛮 “荣幸”
> 的，原来我有这么高的入侵价值（是不是想多了）。大多数小伙伴甚至公司，恐怕从来没有遇到这么高级和针对性的入侵吧。这也让我们刷新了三观，什么 Win8
> 裸奔也很难中毒，Chrome 浏览器很安全，Win8 很难放键盘记录器（人家是放到了 cygwin 里），公共密码只有内部知道无所谓，开了
> AppArmor 就可以阻止大部分入侵，内部 API 没有人会注入，都是没有见过真正黑客的人的心理安慰。安全一定要纵深防御：

我过去的记忆中，日常生活中和周围遇到的都是低级别的攻击，比如用公开的漏洞或公版的木马等，专门为某次攻击写个 dll 甚至 ko
这种高成本、高级别攻击，感觉都是网络战或影视作品中的事件，是遥不可及的。然而现在竟然就这么目睹了一次发生在身边的高级别攻击。触动很大啊……

我也觉得 Windows 8.1 这种较新的系统 + UAC + Windows Firewall + Windows Defender +
Windows Update 应该不会有什么问题吧？看来这种想法是不对的……


--
Zhuoyun Wei

[Bojie Li]

2015-06-15 11:22 GMT+08:00 Zhuoyun Wei <wzyb...@gmail.com>:

我工作的公司里现在用的那套硬件令版 2FA 是我搭的，用的 RSA Labs 的产品 RSA SecurID，大概长这样：
https://upload.wikimedia.org/wikipedia/commons/8/8f/SecureID_token_new.JPG

RSA SecurID 就是 2011 年私钥泄露闹得沸沸扬扬的产品啊，这应该也是 2FA 领域鼎鼎大名的产品了。只是不知道在哪里买，也不知道要多少钱（进口的东西应该比山寨货贵吧……

[Zhuoyun Wei]

2015-06-15 12:09 GMT+08:00 Bojie Li <boj...@gmail.com>:
> RSA SecurID 就是 2011 年私钥泄露闹得沸沸扬扬的产品啊，这应该也是 2FA
> 领域鼎鼎大名的产品了。只是不知道在哪里买，也不知道要多少钱（进口的东西应该比山寨货贵吧……

还有这样的大新闻啊，搜了一下，似乎是因为 RSA 公司里还有一份私钥引起的。

这个东西买来是一大板令牌和一张光盘，光盘外壳上有火漆，刮开有「导入密码」，光盘里存储着 XML 格式的 SN
和私钥对照表，用导入密码导入到认证服务器之后，认证服务器就知道每个令牌的私钥了。

按说这些私钥在令牌的芯片里存一份，然后光盘里存一份，别的地方就不应该存了，RSA 公司自己也不应该有了。没想到 RSA
公司还有一份私钥的存档啊……难道是为了提供客户服务用？比如客户丢失了光盘什么的……

采购价格的话，我不是很清楚，采购并不是我负责的，只是别的部门采购好之后我来搭建的。在搭建前我甚至都不知道 RSA
公司还有这种产品…中国大陆的官网是大概是这个
http://china.emc.com/security/rsa-securid/index.htm

赔偿价格的话，已知 $BABA 员工丢一个是赔偿 ¥100，$BIDU 员工赔偿 ¥450，供参考。

--
Zhuoyun Wei

[丰]

这几天更新了两次 Debian testing，昨天还更了一次，用的就是科大源，需要做什么处理吗？

[SJ Zhu]

On Mon, Jun 15, 2015 at 2:34 PM, 丰 <hxf...@gmail.com> wrote:
> 这几天更新了两次 Debian testing，昨天还更了一次，用的就是科大源，需要做什么处理吗？

并不需要，debian自带包检验的，所以并不怕被篡改。

--
Best regards,
Zhu Shengjing

[丰]

2015年6月15日 15:11于 "SJ Zhu" <zsj9...@gmail.com>写道：
>
> 并不需要，debian自带包检验的，所以并不怕被篡改。
>

棒，Debian 真是适合我这样的懒人用啊。

[Bojie Li]

话说现在有哪个比较大的发行版不带软件包校验的吗？发行版都会考虑到软件包分发过程中可能出错或者被篡改的问题吧。

--

[hugo]

我个人更赞成像 U盾 那样的 usb-key 方案啊，基于验证码的方案似乎不抵抗中间人攻击吧。

其实我这封邮件的重点是，你们敲定方案后能不能把方案和实现都和大家共享一下，我一直很希望能实现在 usb-key 内生成 ssh-key 并直接用 usb-key 登录，如果你们到时候能共享就太感谢了！

最后关于 openssh 的加固有一篇文章推荐下：

https://stribika.github.io/2015/01/04/secure-secure-shell.html

基于这篇文章，我做了一个自动的脚本，也厚着脸皮贴上来：）

https://github.com/FireUponSky/Secure-SSH-script


-----邮件原件-----
发件人: ustc...@googlegroups.com [mailto:ustc...@googlegroups.com] 代表 Zhuoyun Wei
发送时间: 2015年6月15日 13:16
收件人: ustc...@googlegroups.com

主题: Re: [USTC-LUG] BLOG和FREESHELL出现故障，正在抢修中

[Zhang Cheng]

2015-06-16 17:42 GMT+08:00 hugo <hu...@fireuponsky.com>:

我个人更赞成像 U盾 那样的 usb-key 方案啊，基于验证码的方案似乎不抵抗中间人攻击吧。

​你指的验证码方案是什么？你指的中间人攻击，能展开说一下是什么场景么？​

 

其实我这封邮件的重点是，你们敲定方案后能不能把方案和实现都和大家共享一下，我一直很希望能实现在 usb-key 内生成 ssh-key 并直接用 usb-key 登录，如果你们到时候能共享就太感谢了！

最后关于 openssh 的加固有一篇文章推荐下：

https://stribika.github.io/2015/01/04/secure-secure-shell.html

基于这篇文章，我做了一个自动的脚本，也厚着脸皮贴上来：）

https://github.com/FireUponSky/Secure-SSH-script

​我没有明白你这个脚本的目的是什么。为什么要替换/root/下的配置？

你可以参考下面这篇文章，将ssh-key存储在U盘中，如果要在某台机器上使用这个key，只需要挂载U盘，将key通过ssh-add添加到ssh-agent中，就可以将U盘卸载了。

http://tammersaleh.com/posts/building-an-encrypted-usb-drive-for-your-ssh-keys-in-os-x/​

--

Cheng,

Best Regards

[hugo]

抱歉，我表达的不清楚。我指的验证码方案，就是类似 google authenticator 这样的令牌提供的两步验证方案。比如在一个没有保存服务器 host keys 的计算机上，首次登录时不知道服务器 host keys 的指纹， 用 密码+google authenticator 两步验证登录，就不能防止中间人攻击。

 

那个脚本主要是用来设置 ssh 登录时采用的加密算法组合，还有 dhparam 的参数长度等。类似于设置 ssl 的加密算法组合，root 目录下是备份的 /etc/ssh 目录，我当时主要是写了自己用，没有加什么注释，读起来确实不好。不过读

https://stribika.github.io/2015/01/04/secure-secure-shell.html
这篇文章就好。

 

再请教一个问题，邮件服务器反垃圾反病毒有什么好办法么？

 

发件人: ustc...@googlegroups.com [mailto:ustc...@googlegroups.com] 代表 Zhang Cheng
发送时间: 2015年6月16日 18:58
收件人: USTC LUG
主题: Re: 答复: [USTC-LUG] BLOG和FREESHELL出现故障，正在抢修中

--
-- 来自USTC LUG

[丰]

说到硬件私钥，可以看看 Niibe Yutaka 的 FST-01。

Niibe 是 GnuPG 的开发者之一，他主页是 http://www.gniibe.org/ 。

FST-01 是基于自由软件的硬件私钥，这个网页里有购买链接：http://www.gniibe.org/shop/neug_1_0_x-on-fst-01.html

[Zhang Cheng]

2015-06-16 22:00 GMT+08:00 hugo <hu...@fireuponsky.com>:

抱歉，我表达的不清楚。我指的验证码方案，就是类似 google authenticator 这样的令牌提供的两步验证方案。比如在一个没有保存服务器 host keys 的计算机上，首次登录时不知道服务器 host keys 的指纹， 用 密码+google authenticator 两步验证登录，就不能防止中间人攻击。

​如果你首次登录之前不知道服务器的host keys，那么无论用什么方法都不可能防止中间人的。要防止中间人，通信双方肯定都需要预先知道对方的一些信息，或者借由第三方做公正。

用google authenticator做两步认证，最主要解决的是密码泄露的问题。或者换个角度说，丢失一个验证凭证的可能性很大，但是同时丢失两个凭证（并且被同一个黑客拿到）的概率非常小，这就是两步验证的意义。​

 

那个脚本主要是用来设置 ssh 登录时采用的加密算法组合，还有 dhparam 的参数长度等。类似于设置 ssl 的加密算法组合，root 目录下是备份的 /etc/ssh 目录，我当时主要是写了自己用，没有加什么注释，读起来确实不好。不过读

https://stribika.github.io/2015/01/04/secure-secure-shell.html
这篇文章就好。

​这些参数的调整，都是加固ssh通信协议本身，增大针对协议本身的破解难度。这些加固措施有意义，不过似乎跟前面讨论的方向不是很相关。现实生活中，一般很少有人会针对协议去攻击，这种攻击的成本非常高，只有在利益关系非常大的场景（比如政府机构）才会利用。​

 

再请教一个问题，邮件服务器反垃圾反病毒有什么好办法么？

​

建议开新的主题讨论。​

--

Cheng,

Best Regards

[hugo]

应该只要1）服务器知道客户端的 ssh public key；2）客户端知道服务器的 host keys，两者之一就可以避免中间人了。所以如果使用 usb-key 进行 rsa authorization登录，即便在一台新的计算机上首次登陆，也不存在中间人攻击的风险。

 

我自己应用的情况来说，服务器上运行的任务简单，而且可以限制服务器只开放与应用有关的端口，并限制只允许 publickey 的方式登录，经常更新的情况下，这边的风险相对可控，所以风险主要在客户端计算机上。

 

基于以上考虑，我认为1）对抵抗中间人攻击来说，客户端认证风险要小于服务器端认证，因为客户端文件（例如 known_hosts）被修改的风险更大；2）因为多个服务器共用一个 ssh-key 登陆，私钥被盗是最不能接受的，密码并不能有效保护私钥，因为已经入侵客户端计算机的黑客完全可以安装键盘记录器，把私钥保存在 U盘里并全盘加密确实有一定作用，但不能完全防御这一风险；3）不同于通常中间人攻击难以实施的情况，对于已经被入侵的客户端，实施中间人或类似中间人的攻击是容易的，而且如果不能获得登录凭证（比如使用了两步认证），这种攻击说不定会被考虑。所以这又回到第1）条。

 

以上就是为什么我对利用 usb-key 这种客户端认证方式登录非常感兴趣的原因。我前两年拿到的工行的 U盾还有显示屏，在确认之前能看到自己到底授权了什么信息，我觉得这个更好，即便电脑中病毒了，电脑显示的信息被篡改，也仍然能看到自己到底是付了多少钱，付给了谁。

 

PS：那个脚本确实是加固 ssh 通讯协议本身的，我觉得就像配置 ssl 一样，正确的使用加密组合也很重要，而且之前 ssl 系算法爆出的有些漏洞似乎并不需要很高的成本。。。不管怎么说，加固一下也不是很麻烦，所以我就做了：）

 

 

发件人: ustc...@googlegroups.com [mailto:ustc...@googlegroups.com] 代表 Zhang Cheng

发送时间: 2015年6月16日 23:32
收件人: USTC LUG
主题: Re: 答复: 答复: [USTC-LUG] BLOG和FREESHELL出现故障，正在抢修中

--
-- 来自USTC LUG

[Zhang Cheng]

2015-06-17 0:25 GMT+08:00 hugo <hu...@fireuponsky.com>:

应该只要1）服务器知道客户端的 ssh public key；2）客户端知道服务器的 host keys，两者之一就可以避免中间人了。所以如果使用 usb-key 进行 rsa authorization登录，即便在一台新的计算机上首次登陆，也不存在中间人攻击的风险。

​我不理解为什么使用usb-key就可以避免中间人攻击？usb-key中含有服务器的finger print？​

 

 

PS：那个脚本确实是加固 ssh 通讯协议本身的，我觉得就像配置 ssl 一样，正确的使用加密组合也很重要，而且之前 ssl 系算法爆出的有些漏洞似乎并不需要很高的成本。。。不管怎么说，加固一下也不是很麻烦，所以我就做了：）

 

​加固协议的目的不是为了防止爆漏洞。对于爆漏洞来说，你只有及时更新并祈祷在你更新之前每人搞你。

你这里用到的加固协议的方法，不过是因为一些协议本身设计的时候强度不够高，在现有计算能力越来越强的情况下，有些协议以前是“在合理时间内无法破解的”，现在变成“在合理时间内可以破解”了，于是要避免使用这些协议。

再强的协议，如果爆一个漏洞，你照样分分钟被搞定。​

--

Cheng,

Best Regards

[Bojie Li]

我觉得针对协议本身的攻击是不能掉以轻心的。不能以为自己没有价值，没有招惹黑客，就不会遭到入侵。协议分析和密码破译确实成本很高（主要是时间成本），但如果一个有这方面技术的人凭兴趣去做，当成一种挑战，那么就不能按成本来算了。

一个加密通信系统，出问题的地方很少是加密算法本身，而一般是错误的使用方法（协议）和有漏洞的实现。

比如二战时期的 Enigma，以当时的计算能力来说暴力破解和词频分析都是很难的；但它在使用的时候有一些致命的缺陷，比如密钥发送两遍造成了重复（密钥不是加密发送的吗，重复发送也没问题吧？）一些看似是加固安全的措施，比如一个字母永远不能被加密成自身，反而为解密者提供了信息（这个的现代版是 Debian OpenSSL 为了优化性能，引入了 shortcut，导致 timing attack）。

今天的 OpenSSL 也许就像二战时期的 Enigma，看起来固若金汤，或者有点小纰漏也不致引起严重后果。但专业的密码分析者手上有比我们先进得多的理论和工具，一点小纰漏就可能导致整个密码体系被攻破。二战的时候，恐怕大家都只知道词频分析，选择明文攻击、两次加密攻击还不为大众所知。现在，如果我要攻击一个加密的 SSH 连接，也不会挖空心思去解密消息，而更可能从数据包的发送间隔和大小的角度去分析（能知道哪一段是你输入的密码，输入的是哪个密码，尽管不知道这个密码具体是什么）。

加密仅仅是安全的第一步。既然已经有了安全建议，如果不致带来太多的麻烦，采用这些安全加固措施总是没错的。不要像我一样，人家攻进来造成了严重的破坏，才惊讶 “这么高级的攻击手段也会用在我身上啊”。

--

[Zhang Cheng]

是的，计算能力的增长是连续的，而协议的更新并不是，所以随着时间一点点推进，一些协议就会渐渐的变得不安全，这种变化一般的人很难觉察也很难意识到。

所以一些对安全要求比较高的公司，其security director的一项工作就是定期的review线上实用的所有安全相关的协议，我在AA时，AA的SD就是如此，所有地方要使用加密算法或者协议时，都不能随便选择，必须由他来审核。

我回复hugo的内容，并不是说加固协议不重要，而是说跟前面讨论的使用两步验证法所针对的问题不一样。当然，这都不跑题，也感谢hugo的分享！

--

Cheng,

Best Regards

[hugo]

计算机显示服务器的 host keys 的 fingerprint 应该只是为了让人来确认接收到的 host keys 的正确性。知道服务器的完整 host keys 后，客户端确认服务器身份应该是1）利用服务器的公钥加密一个密钥，然后用这个密钥与客户端对称加密通讯，并利用 HMAC确保信息完整，或者2）用服务器的公钥签名一个 DH 参数，做密钥交换然后加密通讯（题外：现在应该采用后者，因为向前安全）。

 

反过来的过程是一样的，如果服务器已经知道了客户端的公钥，也可以利用客户端的公钥1）加密一个随机密钥，发送给客户端，然后双方利用这个密钥对称加密通讯。2）与客户端交换一个 DH 参数，然后加密通讯。

 

无论以上两者哪一种，客户端都可以确保中间没有人能解密通讯，而且因为可以使用 HMAC 来确保信息完整性，中间人伪装也是不可能的。对授权的情形，如果服务器端知道客户端的公钥，完全可以 challenge 客户端来确保授权对象持有私钥。

 

用 usb-key 登录，与把ssh-key 存储在电脑上的 publickey 登录是一回事，只不过私钥存储在不同的位置，加密签名运算不是由电脑 CPU 完成的而已。属于服务器知道客户端公钥的情形。

 

 

发件人: ustc...@googlegroups.com [mailto:ustc...@googlegroups.com] 代表 Zhang Cheng

发送时间: 2015年6月17日 12:08
收件人: USTC LUG
主题: Re: 答复: 答复: 答复: [USTC-LUG] BLOG和FREESHELL出现故障，正在抢修中

--
-- 来自USTC LUG

[hugo]

抱歉，刚才说的有问题。客户端持有服务器公钥以后交换 DH 参数的过程应该是：

 

1、  服务器用私钥签名一个 DH 参数

2、  客户端用服务器公钥确认 DH 参数

3、  交换密钥加密通讯

 

服务器持有客户端公钥时，过程是类似的。

 

发件人: ustc...@googlegroups.com [mailto:ustc...@googlegroups.com] 代表 hugo
发送时间: 2015年6月17日 15:04
收件人: ustc...@googlegroups.com
主题: 答复: 答复: 答复: 答复: [USTC-LUG] BLOG和FREESHELL出现故障，正在抢修中