保护好你的远程卡

远程卡的好处不要多说,已经成为众多厂商的标配了,但是很多公司不乏很多上规模(比如这个)的公司,忽略了远程卡的安全,然后,然后就被搞了。
我们在很早期的时候也遇到过类似的情况。两年前我们上的某批机器,当时为了途方便(那时候我还没有部署 vpn ),远程卡都是放的是公网 IP,再加上当时的自动化做得不是很好,有一台疏忽了修改其默认的用户名密码,导致了这台机器被一个小 cracker 搞了一把。回顾下当时的情景,大致是这样的:
那天晚上正准备睡觉,突然收到短信说服务器被重启了,后续连续收到几条类似的报警。立马登陆到远程卡上 launch console,发现需要发送共享的请求。当时除了我有权限登陆到远程卡之外,没有人可以登陆,当时只是觉得很奇怪,但是没有意识到已经被入侵了。再请求了几次之后竟然可以 launch 了,打开控制界面发现服务器又在重启。后来反应过来,遭入侵了。通过控制卡的回放功能,确认果真被入侵了。那个小哥尽管进了远程卡,但是没有办法登陆,只能通过重启的办法,重置了我们的 root 密码。刚重置完发现发现了,然后,然后就跑了。
接着就是吸取教训写 post-mortem,快速的加固系统,远程卡出问题,当然是从远程卡入手。最容易入手的包括如下的几点:
1. 远程卡全部隐藏到内网里,回收所有不需要公网机器的 IP
2. 修改其用户名密码,登陆端口
当时机器的数量还在两位数,再加上当时对自动化方面没有太大的需求,尤其是这类不涉及系统层面的自动化,花了一天不到的时间,一台台人肉修改完了所有的机器(想象当年多无知)。后来所有新上架的机器都按照这个标准继续执行,当然不再是人肉执行了。

对于这台被入侵的机器,本来是打算直接重装的,经过再三的权衡,再加这是台 db server,上面有很重要的数据,最终并没有选择重装,把能检查的地方都检查了一遍,后续的几天密切的关注这台机器的所有进出口的流量、涉及的进程等等。
后来经过对入侵机器以及几台相关机器的追踪观察,确认没有造成更大的损失,事件到此为止。

接下来的几天,还做了以下的几件事:
1. 所有的机器实行 ssh 的公私钥登陆,取消默认的密码登陆
2. 对服务器的访问权限所了一个比较粗的控制,尤其是开放了公网机器的,基本就是 iptables + tcpwrappers

针对这次远程卡入侵做的事情基本就是这样,后面还陆陆续续的做了些其他的事情,不过我觉得,也只能防住八成的小黑客,或许连八成都没有,即使有专职的安全工程师,这个比例也不会高到哪儿去。有点需要注意的是,绝对不可能做到 100%,只要不是 100%,就有乘虚而入的机会。
老板不重视安全是一回事,被搞了以后重视安全是另外一回事,在平时就很注重安全的更是粉毛麟角了。很不幸的是大部分的老板都属于前两者。为此带来的结果就是安全工程师在公司的地位相对比较低,见过不少公司都是把安全工程师划分到 IT support 部门,而非主流的运维、基础架构甚至单独成立一个安全部门,这个在非互联网公司更明显。尽管我个人很尊敬做安全,并且我也很清楚做安全的其实很有技术含量,但是大陆的整体环境就那样,这个近期好像无解。

two-factor 认证的问题

研究了下 google 出的 google-authenticator,准备用在 ssh 的登陆上,安装配置确实很简单,参照这个文档一步步往下就可以。
很不幸的是,如果要在 ssh 的登陆过程中使用,就没那么理想了。
目前我们所有的服务器都是通过公私钥验证,理论上说,只要私钥不被窃取,是不可能登陆到我们服务器的。但是试用了 two-factor 之后,则必须要开启密码验证的方式,然后再输入那个随机生成的一串字符。根据这两个(1, 2)文档所示,目前没有好的方式可以让公钥认证跟密码登陆共存,这也就意味着,我们是不可能同时使用 two-factor 结合公私钥来登陆服务器的。除非不使用标准的 openssh。
这样看来,two-factor 并不是一个很好的选择。看到有不少公司把它拿来做跳板机,有钱的当然直接买 RSA 了,这或许是一个比较好的选择,不过这样意味着需要一些集中的用户管理方案。
很早之前,我无意发现有同事把自己电脑的整个 ~ 给同步到 github.com 上去了,这个目录里面包含要进入我们的内网环境的 VPN 证书文件,登陆服务器的私钥文件。不幸的是,这个项目还有不少的 fork,虽然事后做了大量的工作,不过现在看来,是不是上个 two-factor 能够最大程度的减小这类悲剧发生之后的影响。

BIOS 对服务器性能的影响

节能在降低能耗的同时也意味着性能的下降。下面介绍的是在 BIOS 这个层面涉及到的一些节能开关,比较具有通用性。
1. Turbo boost
跟超频有关,详细的请看这里

2. C1E, C state
hardwaresecrets 有一篇介绍 Cx state 的文档,比 wiki 上的介绍的更详细。

3. cpu stepping
CPU 版本控制的机制

tomshardware 的这篇测试量化了使用了各种节能设置后,对 SSD 的影响,仅仅开启了 C1E 对整体的性能没有特别大的影响,如果是将所有跟 C states、Active State Power Management相关选项的都开启,会看到明显的下降。另外,文章建议开启 C1E 模式,这个对整体的性能没有太大的影响,同时又能降低功耗。另外需要注意的是,这些功耗的开关对于 HHD 并没有显著的提高,仅对 SSD 有效。

dell 官方有一篇 《low latency env》的参考配置,里面涉及到不少 BIOS 层面的东西。主要分为 "System Profile Setting" 以及 "Memory setting" 和 "Processor Setting" 这三大块,其中效果最明显的应该是第一个 "System Profile Setting"。这个会在下面的 syscfg 里面提到。

Continue reading

多 IP 绑定的问题

主要涉及内核的 promote_secondaries 这个参数。

目前 eth0 接口只有 10.18.101.5 这个 ip:
# ip add sh eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 54:04:a6:98:bf:d6 brd ff:ff:ff:ff:ff:ff
    inet 10.18.101.5/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5604:a6ff:fe98:bfd6/64 scope link
       valid_lft forever preferred_lft forever


给 eth0 新添加几个 ip:
# ip addr add 10.18.101.6/24 dev eth0
# ip addr add 10.18.101.7/24 dev eth0
# ip addr add 10.18.101.8/24 dev eth0

# ip add sh eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 54:04:a6:98:bf:d6 brd ff:ff:ff:ff:ff:ff
    inet 10.18.101.5/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet 10.18.101.6/24 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet 10.18.101.7/24 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet 10.18.101.8/24 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5604:a6ff:fe98:bfd6/64 scope link
       valid_lft forever preferred_lft forever

Continue reading

《The Startup Kids》 观后

The Startup Kids》是一部讲欧美小青年做(移动)互联网创业的纪录片,采访了不少的 startup,包括我一直在使用的 dropbox、vimeo,曾经用过的  Soundcloud 以及从未用过的 Kiip、Scribd、drop.io 等等。

要成功无非分为内在与外在因素,其中内在的起绝对的主要作用,包括热爱激情坚持专业等等的内在素养。这里主要说说外因,外因对一个公司的发展也有非常大的影响,感受最深的几点是:

这些 startup 能非常容易的廉价的租用各种云,这个在大陆基本是不现实的,如果你服务的是大陆客户但是使用的墙外类如 ec2 的基础设施,这意味着严重的访问延时严重的丢包,最不幸的是直接被墙。而大陆的几家云,具体的我就不评价了,要是靠谱的话,被收购后某些业务早就迁移过去了,而不是现在是用物理机的传统方案。

能够方便的获取各种资源,包括但不限于技术上的资源,比如各种各样的开源技术方案;相比大陆好的多工商、税务、办公场所等等一系列的商业资源;以及最最基本的生活设施,包括空气水等等。不得不承认的是,大陆的大部分工程师还在为租房买房买车担忧的时候,对岸的则在想着 "How to make world better"。

纪录片在介绍 drop.io 的时候让我突然想到了域名的问题,同样的,如果目标是大陆的用户,并且是老老实实把服务器放大陆,使用 xxx.io 这类的比较新奇域名就是死路一条,因为中国的局域网有备案这一说法,因此还是老老实实的用 .cn, .com 域名,即使买了,也请老老实实的去拍照备案。当年我们曾经找人帮我们做加急的三天快速备案,一方面是当时有一部分的 .com 域名没有备案,另一方面是有不少类似 .io, .us "非主流"域名,后来发现,域名备案带动了一个新的产业链,从上游到下游。

影片中有不少黄皮肤,人肉了一下发现要么是纯正的中国血统(Ping Li),要么是全家移民过去的(Brain Wong),有的连 Co-founder 都是中国人。这是不是说明中国人其实还是很有创新实干能力的,只不过周围的大环境不太理想,一旦到了一个比较好的环境,还是能如鱼得水做出不少工作的。

最后,推荐大家一看。

puppet 问题记录

1. permission denied 问题
在 cliet 测试时,发现如下的问题:
# puppet agent –server jaseywang.example.com  –noop –test
info: Caching catalog for user1.example.com
info: Applying configuration version '1358997047'
err: /Stage[main]/User::Virtual/Ssh_user[user1]/File[/home/user1/.ssh/id_rsa]: Could not evaluate: Error 400 on SERVER: Permission denied – /etc/puppet/modules/user/files/keys/id_rsa Could not retrieve file metuser1ata for puppet:///modules/user/keys/id_rsa: Error 400 on SERVER: Permission denied – /etc/puppet/modules/user/files/keys/id_rsa at /etc/puppet/modules/user/manifests/definition.pp:49
notice: Finished catalog run in 0.52 seconds

看 error log 应该很简单,权限的问题:
jaseywang@example.com:/etc/puppet/modules/user/files/keys$ ll
total 20
-rw-r–r– 1 jaseywang jaseywang 6249 2013-01-23 18:59 authorized_keys
-rw-r–r– 1 jaseywang jaseywang   81 2013-01-22 23:23 config
-rw——- 1 jaseywang jaseywang 1675 2013-01-22 23:18 id_rsa
-rw-r–r– 1 jaseywang jaseywang  398 2013-01-22 23:29 id_rsa.pub

修改一下 if_rsa 的权限:
jaseywang@example.com:/etc/puppet/modules/user/files/keys$ ll
total 20
-rw-r–r– 1 jaseywang jaseywang 6249 2013-01-23 18:59 authorized_keys
-rw-r–r– 1 jaseywang jaseywang   81 2013-01-22 23:23 config
-rw-r–r– 1 jaseywang jaseywang 1675 2013-01-22 23:18 id_rsa
-rw-r–r– 1 jaseywang jaseywang  398 2013-01-22 23:29 id_rsa.pub

再次执行通过:
# puppet agent –server jaseywang.example.com  –noop –test
info: Caching catalog for user1.example.com
info: Applying configuration version '1358997047'
notice: /Stage[main]/User::Virtual/Ssh_user[user1]/File[/home/user1/.ssh/id_rsa]/ensure: current_value absent, should be file (noop)
notice: Ssh_user[user1]: Would have triggered 'refresh' from 1 events
notice: Class[User::Virtual]: Would have triggered 'refresh' from 1 events
notice: Stage[main]: Would have triggered 'refresh' from 1 events
notice: Finished catalog run in 0.57 seconds

Continue reading