设置SPF记录,防止邮件地址被盗用

因为某些原因,我的域名被各种广告机认为是企业域名,然后疯狂的给我群发各种代开发票偷税漏税的邮件。嗯,我就不说我真的不需要这些了。
由于更多的原因,我的邮箱是开启了“错误地址转发”功能的,也就是说如果给一个不存在的邮箱地址发送邮件,那么它会被投递到我的主邮箱中。方便我使用的同时也就导致了大量垃圾邮件的产生。
最近我频繁收到一些奇怪的退信,大致的意思就是我发到他们那边的邮件邮箱是不存在的。而我却压根没有发过那些邮件。检查了一下其中一封邮件,如下:

您好!您的邮件不能成功的递送到指定地址。这是一个永久的错误,因此不得不放弃继续递送。

<zengcheng@chinalightsolar.com>, the user's maildir is over the allowed quota (size : 105328857)

--- Below this line is a copy of the message.
Received: from SCWT-18.yinksoft.com ([115.63.10.56])
(envelope-sender <wljgipl9400@best33.com>)
by 192.168.16.101 with ESMTP
for <zengcheng@chinalightsolar.com>; Sun, 05 May 2013 03:25:13 +0800
Date: Sun, 5 May 2013 03:25:16 +0800
Subject:  Dz,
From: " " <Wljgipl9400@best33.com>
Reply-To: " " <Wljgipl9400@best33.com>
To: <zengcheng@chinalightsolar.com>
(以下省略)

很明显,我是不会有Wljgipl9400@best33.com这么一个邮箱的。看Received字段,有一个很神奇的域名:yinksoft.com。Google之,发现是一个垃圾邮件发送公司,鄙视。
稍微思考了一下,这封退信是这么到我的邮箱里面来的:这个叫yinksoft的公司(或者是它卖的软件)其中投递了一封邮件给zengcheng@chinalightsolar.com。而zengcheng这个倒霉鬼的邮箱早就被发爆掉了,所以chinalightsolar的邮件服务器就把这封邮件退回来了。那么退到哪里呢?好死不死的,这个yinksoft的发信软件把发件人地址填成了我域名下的邮箱wljgipl9400@best33.com。由于chinalightsolar是一个正规的邮件投递者,Gmail就没有把它当成垃圾邮件过滤,从而经过错误地址转发到达我的邮箱。
那么事情就很明显了,我的域名best33.com被盗用,盗用者伪装成我的域名下面的邮件地址给别人发送邮件。好吧,这种情况真够神奇的,由于SMTP的协议缺陷,这样做是完全没有问题的。那么要怎么解决呢?答案就是传说中的“SPF”记录了。
SPF记录的工作原理也很简单。把一条TXT记录加入到你域名下就能工作。工作的时候,接收邮件的服务器对你的DNS服务器进行查询,确认你的SPF记录,而后对SPF记录中记载的服务器进行查询,和收到邮件的IP地址比对就能确认这封邮件是不是你发送的。
由于SPF记录其实就是一条TXT记录,现在的主流解析商比如DNSPod都已经支持了。在@下的TXT记录下加入一句SPF记录就好了。我这里是Gmail的,其它邮箱的请查询你自己的提供商:
v=spf1 include:_spf.google.com ~all
只需这么一个记录就能将垃圾邮件阻挡在外啦~解析完成后可以自己dig查询一下:

$ dig best33.com txt

; <<>> DiG 9.9.2-P1 <<>> best33.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34100
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;best33.com.                    IN      TXT

;; ANSWER SECTION:
best33.com.             600     IN      TXT     "v=spf1 include:_spf.google.com ~all"

;; Query time: 102 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri May 10 13:47:00 2013
;; MSG SIZE  rcvd: 87

嗯,看起来毫无问题,尝试外发和收信都无压力,问题算是解决了。

在nginx下配置并使用ssl

嘛,具体的效果可以看https://best33.com,我已经部署了StartSSL的证书了。

首先我们需要一个SSL证书。可以看Freehao123上的文章StartSSL免费SSL证书成功申请-HTTPS让访问网站更安全,也可以在Linux服务器下自签名证书。至于为什么使用StartSSL,无非就是让访客访问的时候不提示“不受信任的安全连接”罢了。自签名的证书和经过CA认证的证书一样是能够保障连接安全的,只是它不被浏览器信任罢了。
Update:在火狐下,如果你的网页有除了https的其它内容,那么火狐仍然会显示你的网页,只是地址栏上没有小锁图标;IE或者某些其它浏览器下,非https的内容压根就不会显示。所以要保证站点引用的都是https的资源,包括css啦,js这些的都要是https的,这样才能显示小锁图标。
在Linux的VPS下要生成一个SSL证书也很简单。首先我们需要生成一个key:

openssl genrsa -des3 -out ssl.key 1024

生成的时候要输入一个密码。因为nginx加载证书的时候会需要输入这个密码,所以我们要把这个密码再去掉。执行:

openssl rsa -in xxx.key -out ssl.key

输入密码后,ssl.key的密码就被去掉了。然后我们用这个key去生成一个csr请求,执行:

openssl req -new -key ssl.key -out ssl.csr

这一步会要输入一大堆的东西。嘛……如果不介意的话一路回车下来就好了。
在这里我们得到了一个csr文件。执行cat ssl.csr就可以看到一堆的被编码的文件,在生成StartSSL的时候可以用到。(在输入密码那一步,点击skip然后粘贴进去。这样的好处就是生成的证书有详细的描述)
得到StartSSL的证书后,把它保存为ssl.crt放到同一个目录下即可。

如果没有StartSSL帮你签名的话,就自签名就好了。将csr请求和key一起生成我们要用到的crt证书,执行:

openssl x509 -req -days 3650 -in ssl.csr -signkey ssl.key -out ssl.crt

然后我们就会在当前目录下得到ssl.key和ssl.crt两个文件。刚刚的ssl.csr可以删掉。
Update:据说如果这个文件不和StartSSL的根证书合并的话,依然不能用。从网上下载StartSSL的根证书并合并到ssl.crt:

wget http://cert.startssl.com/certs/sub.class1.server.ca.pem
cat sub.class1.server.ca.pem >> ssl.crt

然后我们把这两个文件移动到一个合适的地方,比如/home/www/,并给与对应的权限:

mv ssl.* /home/www/
chown www:www /home/www/ssl.*

现在找到nginx的配置文件。我用的是军哥LNMP,那么执行:

vim /usr/local/nginx/conf/vhost/你的虚拟主机名

找到其中的server段,在listen 80;下方加入:

                #ssl config
                listen 443;
                ssl on;
                ssl_certificate /home/www/ssl.crt;
                ssl_certificate_key /home/www/ssl.key;
                ssl_protocols SSLv2 SSLv3 TLSv1;
                ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
                ssl_prefer_server_ciphers on;
                #end of ssl config.

注意把其中的路径换成你的路径。完事之后重启nginx,尝试访问你的https站点吧~

Google Authenticator / D令牌 网页版

Google的两步验证想必大家都有听说过或者用过吧,至于D令牌则是DnsPod的两步验证,用的其实也是Google Authenticator的一模一样的算法,而Google Authenticator的算法实际上是一个叫做HOTP(参考)的东西。
由于算法是开源的,那也就是说可以用任何方法来实现它。这里我直接选了我最熟悉的php来写。考虑到这个东西肯定有人已经写过了,所以Google一下找到了这么一个神奇的类库(参考)。这个类库可以实现一些简单的功能,比如生成当前时间的二次认证的token,比如验证一个token和它的secret key是不是一致(前后差距可以有两分钟)之类的。用法我就不仔细说了,自己戳到参考链接里面可以看到详细的用法和完整的源码,这里我来说说我写的这个HOTP网页版怎么用。

由于代码比较长,所以我把代码贴到了Gist里,!猛戳这里查看!,直接从上面把代码复制下来放到一个php文件里面就好了。

看到开头的配置部分,修改对应的参数就能使用了。第一个密码是打开这个网页的需要密码,为了保密性而防止其他人使用的一个验证措施。后面是对应的账户标题和密钥。前面的标题可以随便写,只要自己能记住这个密钥是哪个账户的就行了,而后面的密钥要怎么获取呢?在DnsPod和Google绑定两步令牌的时候,我们看到的都是二维码。但是这个二维码下面会有一行小字,类似于“无法扫描二维码?”或者“手动输入绑定”之类的,点击就能看到一个密钥。把里面的空格去掉,无视大小写粘贴到php里面就行了。
首次打开的时候会让你输入密码,输入在php里面设定的那个密码就行。或者你也可以这样访问它:http://your/path/to/totp.php?key=你的密码 , 这样就不需要输入密码也能够看到你的令牌了。它会30s自动刷新,要保证你的服务器时间和标准时间误差不超过2分钟哦,不然密码就没用了。至于时区倒是不那么重要,反正是基于GMT标准时的。

入手zml.pw,十一名(11th)优惠码 – 可能是最便宜的pw域名购买方法

手贱,买了一个pw域名,在十一名买的,人民币结算,价格公道,首年仅CNY 9.99。搭配下面的优惠码,可获得4%的折扣(折后9.5元,能省则省,虽然还不到5毛)。

L3S0RQU1F7H6

看了下11th的域名价格,挺公道的,不过我也是第一次接触这家域名商,对它的服务了解不多。之后如果有什么经历会另外写文章分享。
zml.pw,一开始取自“怎么了”,然后发现还有最美丽,早买了之类的意义,感觉还蛮有意思的,不知道最后这个域名是被我卖掉还是自己用。要是有想买的看官,可以从右边的留言板看到我的邮箱或者直接留言,价格合适的话我就出手算了。
现在pw的资源还是不少,四位数字或者三位字母的域名还是一抓一大把,不过有很多人不看好它。私以为要是自己用的话,短,快,简洁的名字能够节约自己的时间同时显得更加专业和geek;商业或者建站的话,如果意义不错还是可以拿来一用的。
注,通过我的推荐链接(http://www.11th.com/?affid=217)注册,我可以拿到5%的返利;但是如果使用L3S0RQU1F7H6优惠码,则这5%的返利中有4%是归你的(后台不能设置5%,要不然我就设置了)。如果不希望我拿这1%的返利,请从无返利链接 进入。

【旧闻】GitHub Pages 转移至github.io域名下

刚刚看自己的项目主页的时候才发现自己的项目地址变成了github.io域名而不是原来的github.com域名。Google查了一下,发现是五天前的事情了。(via GitHub 开发者页面迁至 github.io – OSChina
据称,此举主要是防止cookies盗取、CSRF和依托github.com域名的钓鱼网站。
于是,我们有了一个很简单的方法判定一个页面是否属于GitHub Pages(而不是GitHub自己)。不知道GitHub Pages在中国的命运会走向何方。

bpcs_uploader 更新:快速初始化、内置app key、正常使用离线下载

如题,这次的更新主要是以下几个方面:

1.加入快速初始化功能:只要敲入quickinit命令,即可进入快速初始化流程,只需一个y键和一个浏览器~

2.内置的app key:随快速初始化功能附赠

3.正常使用离线下载:现在百度PCS的离线下载API开放了,于是就可以离线下载HTTP文件了~

嘛,以上。欲知详情,点击bpcs_uploader项目主页~

更换到Typecho的记录

看看Hello world,更换成typecho也有两天了。

看着Google Reader离我远去,深深的感觉到本地数据为王的意义是什么了。于是,就把is-programmer的文章,完全手工复制粘贴移动到了这里。

这里是我在洛杉矶的VPS,就是之前提到过的LocVPS(via LocVPS|无推介链接)。国内访问速度一流,价钱公道,ticket响应快,到现在除去我的原因也才宕机过3分钟左右。

由于放了很重要的站点,预计会要一直续费到LocVPS倒掉(喂)。考虑到……博客还是有会消失的那么一天……嘛,谁能算计那么多呢?只能自己守着博客慢慢变老了(大雾)。

嗯……目前的感觉还不错。访问没有那么卡了,页面基本秒开,比较舒畅。

我从未想过Google Reader会被关闭

虽然我不用Google Reader,但是我明白这是一个不可多得的好工具。

从QQ邮箱订阅中看到古奥连续PO出一大堆挽回的GR的新闻,小众,月光,我所订阅的一切科技博客无不在重复这个主题。

Google Reader都要被关闭了。这个事实大概是目前为止Google关闭的服务中最重量的一个吧。

我从未想过Google Reader会被关闭。

我从来都觉得,GR和Gmail,甚至Google Search本体一样重要。因此,Google关闭它完全出乎我的意料。

当然,这好像提醒了我什么。

嗯,对。任何一个互联网服务——甚至线下的服务,无论是收费抑或免费,终究有走向终结的那一天。服务不贵,数据最贵。放在Google,或者放在其它什么地方的数据终究没有放在自己硬盘上来得放心。

之前,我的观念并不是这样子。我觉得,我的文章,我的思想和我的数据的全部,都应该放到大公司的托管下——这样,我的思想才会得以保存起来,在我无暇管理它之后也是那样。但是,我从未想过,这些托管的服务本身都是不那么靠谱的。

嘛。大约从现在开始我会慢慢的把博客搬去某个地方的Typecho吧。嗯,基于思想的传承的观点,我决定还是把博文同步到某些BSP上去。

Google Reader已死。

Evernote账户信息泄漏 – 谁动了我的帐号

今天收到一封来自Evernote的邮件,其中部分内容如下(原文截图):

亲爱的Evernote International用户,

Evernote运营和安全团队最近发现并成功阻止了一项针对Evernote网络的可疑活动,该活动可能试图有组织的接入Evernote服务的安全区 域。为预防未来的潜在数据隐患,我们决定请求所有用户进行一次密码重置。请阅读以下内容了解详情和步骤。

通过一次全面仔细的检查,我们未发现任何迹象表明你保存在Evernote中的任何内容被访问过、修改过或丢失。Evernote高级帐户的付款信息和Evernote企业帐户也没有任何被访问过的迹象。

但是检查显示,参与这次可疑活动的人员能够访问到Evernote的用户信息,包括与Evernote帐户关联的用户名、邮箱地址和加密过后的密码密文。 尽管密码密文有可能被访问,但请特别注意,保存在Evernote中的所有帐户密码密文均采用不可逆的单向加密算法(one-way encryption)生成。(用专业术语表示,即所有密码密文都是经过哈希算法处理并随机生成(hashed and salted))

从CSDN密码泄漏门,到Twitter用户密码被重置,直到这次Evernote也不幸中枪。一次又一次的针对互联网帐号的攻击事件频频发生,各大服务运营商中枪,就连推特、Evernote这样的服务也在所难免。难道我们的互联网帐号信息已经不再安全了吗?

现阶段,主流的密码加密方式即上文中提到的“hashed and salted”(哈希加盐)法。这种方法由于是单向加密,而且对密码加入了随机字符串salt,安全系数大大提高。但随着硬件的发展,要破解哈希加盐也不是很困难的事情。攻击者通过构建大型彩虹表,有一定几率来破解经过单向加密的密文。

但需要提到的是,对密码进行加密存储是用户信息安全的「最后一根稻草」。因为破解加密存储是在黑客拿到用户数据库后才可以进行的操作,假若用户数据库足够安全,只要数据库不被泄漏,那么即便是明文存储也不会有太大的风险。这并不是说被hacker攻击的twitter和Evernote做的不够好,因为在这么多年来,在数千万甚至数亿、十亿数量级的攻击下,这种事情也只发生过少数的几次。

话又说回来,最近这种事情发生的几率正在逐步攀升。不知道是现在的hacker技术变得更加高明了呢,还是现在的firewall已经无法阻止hacker前进的脚步了。

那么,作为个人用户,我们要怎样从个人角度来防止这些事件的发生呢?只有降低用户资料的价值,才能从根本上减少事件发生后的损失。作为用户,你的资料的价值是什么?对于一个网络服务来说,你的资料意味着你的用户名、密码和电子邮件地址。如果你所有的网上服务包括网银、电商、电邮、公司办公系统都是用的同一个密码,你的资料的价值无疑会很高;如果所有的服务使用不同的密码组合,那么,资料的价值就会降低到仅有的被攻击的服务那一个帐号。所以,最终的防范秘诀就是:使用密码管理方案。

密码管理方案有很多种,比如花密,LastPass都是很好的选择,这里要介绍的不是那些记录密码的工具,或者像花密那样的base+salt的方式——毕竟有时候需要离开他们——而是一种便于记忆的管理的方案。我称之为分级管理模式。

一个完善的密码系统,应该包括至少三个级别:

低级密码,即「用一次就丢」的密码。这样的密码最好还搭配一个另外的用户名,以满足各种「一次性」的帐号需求。这种密码只需要有一个,然后在各个小网站、不确定安全性的网站和用一次就丢的网站使用。

高级密码,即「相当重要」的密码。这类密码不要和你已有的密码雷同,而是采用全新的组合,最好是包括大小写字母符号数字等,用于独立的重要服务,例如电邮、IM工具(QQ、MSN等)和财务(电商、网银等)。

最多最常用的密码,也就是「不是相当重要也不是用一次就丢」的中级密码。这样的密码是使用最为频繁、又有一定价值的。如果让所有的这类中级网站共用一个密码,也不是一个好的方法:黑客仍然可以通过获取其中一个来得到其它的。或许有人会想到一串固定字符加上网站的主域名,我只能说黑客也一眼就能看出来你的密码中有个域名从而破解。这里介绍一种思路,或许会对你的密码有帮助。

这种思路的灵感是从md5来的。md5是一种「摘要」算法,那么我们也可以将域名的所谓「摘要」放到密码中去。这么说还不明白的话,看一个简单的例子。比如对「Google」的域名,我们可以摘它的最后一位「e」,然后放到密码中的某一位。比如密码的基准是「BestWishesTo」,我把摘要字母放到最后一位并大写,也就是「BestWishesToE」,这样的话即使是得到密码的黑客也不会知道你其它网站的密码——除非它最后一位也是E。如果觉得还不够安全的话,可以继续摘录并进行适当的运算。比如摘「Google」的第一位「G」,在字母表上将他往后挪动3位变成「J」然后小写放到刚刚密码的最后面,加入「Google」这个单词的长度6放到第一位,成为「6BestWishesToEj」,这样还看得出来你的密码的本来面目吗?除非还有一个网站叫「Gxxxxe」,否则你的密码也不会被用到其它网站上去——这样的可能性不是很大,而且你会在一个叫做「Geoeoe」的网站用上你的中级密码吗?

这样一来,帐号丢失所损失的价值就减少了不少。当一个网站的密码被盗时,并不会牵连到太多的网站。

另外,加强自己的帐号保护意识,对电脑定期杀毒(其实有点扯,主要是防键盘记录类的木马神马的),并且在输入帐号的时候注意网站是否安全(检查网站域名、检查https等)就好了。这样一来,即使是某个网站被爆出使用明文存储密码而且数据库被大量泄漏的话,你也可以安然不动,笑看众人疯狂改密码了。(完,本文由oott123纯原创,转载请保留出处。)