ocean

匿名

10 月 122011
 

阿舍在用指令操作 Ubuntu 的時候,經常會需要知道檔案的路徑,所以,也就常常會用到搜尋檔案的指令,阿舍比較常用的是 whereis 和 find,其實,還有 locate 和 which 二個指令可用,這四個指令都有不同的功能,阿舍一直時間去搞清楚,今天花了點時間,就把它整理如下了。

find
這個算是功能最多的指令,可以用依檔名、擁有者、群組和權限…等等一堆來搜尋檔案,不過,find 指令是一定要指定搜尋的路徑,否則就只有搜尋目前所在的資料夾,例如,阿舍在家目錄用 find hosts 的指令來搜尋 hosts 檔的話,就一定找不到東西,如果改用 find /etc hosts 的話,就會出現一堆檔案名稱裡有 hosts 這個四個字的所有檔案出來,如果再改成 sudo find /etc -name hosts 就會找出更接近我們要找的檔案列表出來的。

locate
這個指令和其他三個指令不同的地方是,locate 指令並不是宜的去搜尋檔案,而是去搜尋由 updatedb 指令所建立和更新的資料庫並讀入記憶體中,所以,locate 指令的搜尋速度遠比其他的指令來的快, Continue reading »

10 月 122011
 

Ubuntu 並沒有像 Windows 7 一樣的把 DNS Cache 納入預設的功能,所以,Ubuntu 預設是沒有 DNS Cache 的功能的,如果想要讓 Ubuntu 有 DNS Cache 的功能,那得就要自己安裝才行哩 ! 阿舍找了一下,好像大家都用 dnsmasq 這一套比較多,不然,就是 nscd daemon 這一套,後來,還找到 Unbound 這一套哩 !

阿舍比較了一下,第一套的 dnsmasq 除了 DNS Cache 的功能外,也有 DNS Server 的功能,而第二套和第三套都是單純的 DNS Cache,但是,第三套的 Unbound 還多了一個 Recursive DNS Server,所以,阿舍就選這個 Ubound 來用用囉 !

首先,要先安裝 Unbound 這套軟體,請用下面的指令來安裝。 Continue reading »

10 月 122011
 

一般的 DNS Server ( Authoritative DNS Server ) 是要用來回答該 DNS Server 所負責或擁有的一個或多個網域的主機名稱和IP位址的查詢,而 Recursive DNS Server 則是相反,Recursive DNS Server 也算是一個 Cache (快取) 的 DNS Server,它會在電腦上儲存多個網域的資料,但電腦上的應用程式 (像是瀏覽器) 需要用主機名稱查詢IP位址是,Recursive DNS Server 就可以提供它所儲存的網域資料給該應用程式。

但是,為什麼叫做 Recursive 呢 ? 這是因為 Recursive DNS Server 可以經由 Recursive (遞迴) 方式,從網域名稱的樹狀結構的根 ( Root ) 來進行遞迴式的查詢以找到需要的網址,這和實際的連結到 Authoritative DNS Server 進行的方式是類似的,不過,並不是所有的 DNS Server 內建都有支援 Recursive DNS Server 的,如果有要用 Recursive DNS Server 的功能的話,在選擇 DNS 時,就要注意一下哩 !

你可以在自己的電腦上加一台 Recursive DNS Server 給自己用,可以稍微的加快瀏覽網站的速度,尤其是在低頻寛的連線或是沒有吃到飽的 3G 連結,透過 Recursive DNS Server 的使用者,都可以減少一些封包的傳送,另外,也是可以裝一台在公司內部給大家一起用的,這樣可以降低一些網路的流量的哩 ! Continue reading »

10 月 122011
 

DNS安全扩展(DNSSEC),是由IETF提供的一系列DNS安全认证的机制(可参考RFC2535)。引入DNS SEC技术是为了防范在 DNS 中发现的一些无法避免的漏洞,攻击者可以利用这些漏洞劫持这一使用名称在 互联网 上搜寻某个人或某个站点的过程。这种攻击的目的是取得对会话的控制以实施某种操作,例如使用户进入劫持者自己设立的欺骗性网站,以便收集用户的帐户和密码。

本文描述的如何在你的Linux(Ubuntu)和Mac系统上启用DNSSec支持,防止域名劫持。通过安装和配置开源 DNS服务软件unbound,就可以在本地启用DNSSec的支持。 Continue reading »

10 月 122011
 

Posted on May 11, 2010 by Duan Haixin

5月5日ICANN已经成功的将DNSSEC部署到13个跟域名服务器了,没有出现人们担心的千年虫问题,7月份将使用正式的Key。

那些山寨版的Root Server仍然可以继续“行骗”,只要ISP仍然控制着路由。如果Resolver 也配置了DNSSec,这些山寨版的root server可能要露出马脚了。

当然,国内可以控制域名服务器,让国内的resolver不使用 DNSSec。然而,他们控制不了国外的resolver。

这样的环境下,DNSSec能够防范域名劫持吗?我还在怀疑和观察中……

=====PS:不知原作者的观察结果如何?

10 月 122011
 

Posted on May 16, 2011 by Duan Haixin

作者:段海新,清华大学信息网络工程研究中心

摘要:DNSSEC是为解决DNS欺骗和缓存污染而设计的一种安全机制。本文概要介绍DNSSEC的背景、工作原理、在BIND上的配置,最后介绍国际上的布署情况和它可能对互联网安全体系的影响。

1  DNSSEC的背景和目的

域名系统(Domain Name System,DNS)是一些“Too simple, Too Naive”的互联网先驱者设计的,它象互联网的其他协议或系统一样,在一个可信的、纯净的环境里运行得很好。但是今天的互联网环境异常复杂,充斥着各种 欺诈、攻击,DNS协议的脆弱性也就浮出水面。对DNS的攻击可能导致互联网大面积的瘫痪,这种事件在国内外都屡见不鲜。

尽管DNS的安全问题一直被互联网研究和工程领域广为关注,但是有一种普遍存在的攻击却始终没有解决,即DNS的欺骗和缓存污染问题。DNS安全扩 展(DNS Security Extension, 即DNSSEC)主要是为了解决这一问题而提出的(尽管它还有其他用途)。因此,在介绍DNSSEC的原理之前有必要简单介绍DNS欺骗和缓存污染攻击的 原理。

1.1   DNS欺骗攻击和缓存污染

用户在用域名(www.example.com)访问某一个网站时,用户的计算机一般会通过一个域名解析服务器(Resolver Server,也称递归服务器(Recursive Server))把域名转换成IP地址。解析服务器一般需要通过查询根域名服务器(root)、顶级域名服务器(TLD)、 权威域名服务器(Authoritative Name Server),通过递归查询的方式最终获得目标服务器的IP地址,然后交给用户的计算机。如图1所示。

图1 DNS域名欺骗和缓存污染攻击

对于上述任何一个请求(1,2,3,4)过程,攻击者都可以假冒应答方(根、顶级域、权威域、或解析服务器)给请求方发送一个伪造的响应,其中包含 一个错误的IP地址。发送请求的用户计算机或者解析服务器很傻、很天真地接受了伪造的应答,导致用户无法访问正常网站,甚至可以把重定向到一个伪造的网站 上去。由于正常的DNS解析使用UDP协议而不是TCP协议,伪造DNS的响应报文比较容易;如果攻击者可以监听上述过程中的任何一个通信链路,这种攻击 就易如反掌。 Continue reading »

10 月 102011
 
  • webluker边缘服务器默认缓存策略

在默认情况下,Webluker边缘缓存服务器是不缓存任何内容,只有您在服务信息里配置的允许缓存的内容才会被缓存,且会按照策略的 一定的先后顺序进行匹配。

在您配置的要缓存的内容中,出现以下任何一种情况时也将不会被边缘服务器缓存

  • 服务器响应的header中包含Cache-Control,明确不让缓存的,如:private,no-cache等
  • 服务器响应的header中包含Set-Cookie字段(默认,也可以通过忽略Set-Cookie来调整)
  • 服务器响应的header中不包含Last-modified、Date 字段

如果您在源站服务器中通过header配置了内容的过期时间(Expires),Webluker会严格遵循。
服务信息里配置的过期时间只会对您没有配置header的内容生效

10 月 102011
 

时下在互联网服务领域,CDN无疑是一大热点,它从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的网络响应速度缓慢等难题,推动了互联网应用的发展。然而,随着市场的发展,越来越多的CDN服务商开始抱怨市场竞争激烈、客户挑剔;与此同时,用户也在被各种眼花缭乱的CDN服务介绍所迷惑。

破除CDN节点数量的“迷信”

众所周之,CDN服务是在现有互联网络中增加一层新的网络架构,通过CDN节点将客户网站的内容发布到最接近用户的网络“边缘”,使用户可以就近取得所需的内容,从而解决网络拥挤的状况,提高网民访问速度。由于节点在CDN服务中起到了非常关键的数据存储作用,因此长期以来,人们对于CDN领域一直有一种“迷信”–节点数量的多少决定CDN加速能力的快慢。为了在当前的竞争中占据优势,某些国内的CDN服务商一直乐此不疲地修改自己的节点地图,其销售人员面对客户时更是不厌其烦地介绍自己的节点数量,而不管这些节点是否为客户提供服务。

其实,在通常情况下,客户使用配置的节点不会超过20个,因此CDN服务商的节点部署数量对最终用户使用速度的影响并不大。CDN服务加速效果的好坏更重要是节点的正确分布和配置,单纯的认为节点越多越好并不科学。其实,如果节点过多的话,相应缓存的命中率也会下降,反而会降低速度。从实际应用的角度来看,CDN服务对节点质量的要求远大于对节点数量的要求。 Continue reading »