Month: July 2011

Gnome 3 还好

我把Ubuntu 从11.04 升级到了11.10 的开发版。（令我感到意外的是——尽管升级过程并不顺利（强迫重启了2次），但升级后的新系统记过一些调整后却很似乎很稳定，没见到太多的软件包本身的bug，比之前从10.10 升级到11.04 alpha 轻松多了。）

升级后，我并没感到Unity 桌面环境有什么大的改进。相反，对于新的ctrl+tab 的功能设置我实在无法接受，我以前都用它切换浏览器标签的。。。

11.10 的一个好处是GNOME shell 可以和Unity 共存，所以我又安装了GNOME shell，这东西比我想象中的要好。最主要的就是响应速度上了，比那个基于糟糕compiz 的Unity 好太多了。举个例子，在GNOME shell 和Unity 环境中分别按下Windows 键，GNOME shell 几乎是立即就弹出那个Acitivites 界面了，而Unity 底下往往得卡个一两秒钟。。

GNOME shell 另一个明显强于Unity 的地方就是屏幕左边那个“panel”了。使用Unity 时，鼠标往屏幕左边移动时都得很小心，以防止把那个panel 给激活了；而在GNOME shell 中则是无需担心的，屏幕左上角才是用户需要“担心”的。

目前就这点感觉吧。。。

Nginx with SSL

因为有了StartSSL 这样的可以免费申请SSL证书的机构，所以我觉得把自己的一些站点放到https 下还是值得去做了的。（至少，总还是会有一部分人会对在非SSL加密下的登录页面感到不舒服吧）

SSL 的性能问题

SSL 增强了安全，但它有些问题。它会导致服务器的资源消耗比http 大（但对现在一般的机器来说似乎已经不再是个问题了）。很多情况下人们对于https 的链接还是有一个感觉——慢，准确点来说应该是初次连接到服务器时会感觉慢，而一旦连接建立后，速度上感觉是与明文的http相差无几的。这主要是因为本地浏览器与服务器端初次建立连接握手时需要进行（非对称）密钥交换，密钥交换的协议和密钥的加密算法、长度都会对这个时间有影响。但是连接建立后，内容是以密钥长度短得多的对称加密的方式在传输，而且现代的浏览器同样也能对https链接的内容进行缓存等操作，所以也就感觉不到什么差别了。

因为慢，所以要对它作些调节。但知道了原因后也就好办了。

  • 密钥交换协议的选择。可以在Nginx 配置文件的ssl_ciphers 指令中添加“!kEDH”禁用先对耗时更长的DH 密钥交换机制，而使用RSA【1】。从1.0.5 版本开始，Nginx 默认的SSL ciphers是“HIGH:!aNULL:!MD5”，我们可以把它改为“HIGH:!aNULL:!MD5!kEDH”。应该看到如下变化：


使用DHE_RSA 进行key 交换

更改后的使用RSA key交换机制

  • 服务器公钥长度的选择。长度越长的服务器公钥一般来说是越安全的，但建立连接的时间也会越长，所以这就需要作些取舍了。像Google 和Facebook 这两家规模巨大但提供了许多全程加密的web 服务的公司就使用了相对“弱”的1024位公钥（openssl s_client -connect domain.com:443 查看），这也许降低了建立连接的安全性，但更重要的是降低了连接建立时间。（BTW，Google 还在传输过程中对Chrome 浏览器使用了比HTTP 更快的SPDY 协议，并且key exchange 机制也是RSA 的。）

其它还有要注意的地方有服务器ssl_session_cache, ssl_session_timeout, keepalive_time 等指令的使用等。

——

一些有用的链接：

【1】. http://matt.io/technobabble/hivemind_devops_alert:_nginx_does_not_suck_at_ssl/ur

http://nginx.org/en/docs/http/configuring_https_servers.html

http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

http://blog.httpwatch.com/2011/01/28/top-7-myths-about-https/

http://blog.httpwatch.com/2009/01/15/https-performance-tuning/

Iptables default DROP 策略和hitcount

记一下。当使用了默认为DROP 的策略时，iptables 限制连接次数的脚本应该可以这么写：

[sourcecode language=”bash”]
#!/bin/sh

# Flush all existing rules.
iptables -F

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
…
iptables -A INPUT -i $INET_IF -p tcp -d $INET_ADDR –dport 22 -m state –state NEW -m recent –update –seconds 300 –hitcount 5 -j DROP
iptables -A INPUT -i $INET_IF -p tcp -d $INET_ADDR –dport 22 -m state –state NEW -m recent –set -m state –state NEW,ESTABLISHED -j ACCEPT
…
[/sourcecode]

使用default DROP 策略时，–update 应该是要位于–set 之前的。因为之前把iptables 和PF 有些记混了，记成了iptables 也是“最后匹配”的，所以写成了先–set， 然后–update 的顺序，结果测试发现根本就无法达到限制连接数的作用。
PS：之所以限制SSH server 端口的连接次数只是为了让auth.log 简洁一点，算不上什么安全策略。确保SSH server 安全正确的做法应该还是禁止密码验证方式吧。