英國政府對電腦的資安管理機制:Ubuntu 14.04 LTS 的部份

Ubuntu Insights 上看到「UK Government issues Ubuntu 14.04 LTS Security Guidance」,英國政府發布了 Ubuntu 14.04 LTS 的資安規範:「End User Devices Security Guidance: Ubuntu 14.04 LTS」,在裡面甚至還包括了 script 幫你處理。

可以在「End User Devices Security and Configuration Guidance」的「Per-platform Guidance」看到其他作業系統的資安管理規範。

在企業規劃內部的資安規範時也可以拿來參考看看?

幾個新發現:IPv6 與 Facebook 台灣機房...

無意間測試時發現的...

Ubuntu 14.04 的 PPPoE 撥上 HiNet 後,會拿到 IPv6 address (我記得申請完後之前一直拿不到),然後一次拿好幾個 (不知道什麼原因,應該要去翻翻看 IPv6 是不是有什麼特性):

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:1.163.x.x  P-t-P:168.95.x.x  Mask:255.255.255.255
          inet6 addr: 2001:b011:3008:282:xxxx:xxxx:xxxx:xxxx/64 Scope:Global
          inet6 addr: 2001:b011:3008:282:xxxx:xxxx:xxxx:xxxx/64 Scope:Global
          inet6 addr: 2001:b011:3008:282:xxxx:xxxx:xxxx:xxxx/64 Scope:Global
          inet6 addr: 2001:b011:3008:282:xxxx:xxxx:xxxx:xxxx/64 Scope:Global
          inet6 addr: fe80::xxxx:xxxx:xxxx:xxxx/10 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:24632377 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16553423 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:30408127665 (30.4 GB)  TX bytes:2344774062 (2.3 GB)

然後到處亂測發現 Facebook 在台灣有機房:

gslin@GSLIN-HOME1404 [~] [00:32/W3] mtr --report www.facebook.com
Start: Thu Mar 19 00:32:25 2015
HOST: GSLIN-HOME1404              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- ipv6.dynamic.hinet.net     0.0%    10    6.2   6.5   6.2   7.3   0.0
  2.|-- 2001:b000:82:5:22:2201:1:  0.0%    10    6.1   9.0   6.1  26.4   6.3
  3.|-- 2001:b000:82:4:3201:3302:  0.0%    10    6.7   6.6   6.3   6.8   0.0
  4.|-- 2001:b000:80:3:80:82:3:2   0.0%    10   11.6  10.7   6.9  16.6   2.8
  5.|-- 2001:b000:80:4:3011:3311:  0.0%    10    6.9   7.3   6.4  10.0   1.1
  6.|-- 2001:b000:80:7:0:3:2934:1  0.0%    10   16.8   8.3   6.9  16.8   3.0
  7.|-- po126.msw01.01.tpe1.tfbnw  0.0%    10    7.9   8.0   7.5   8.9   0.0
  8.|-- edge-star6-shv-01-tpe1.fa  0.0%    10    7.3   7.2   6.8   7.6   0.0

再回頭測了 IPv4:

gslin@GSLIN-HOME1404 [~] [00:32/W3] mtr --report -4 www.facebook.com
Start: Thu Mar 19 00:33:18 2015
HOST: GSLIN-HOME1404              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- h254.s98.ts.hinet.net      0.0%    10    6.9   6.4   5.8   6.9   0.0
  2.|-- SNUH-3301.hinet.net        0.0%    10    6.3  12.2   6.2  60.9  17.1
  3.|-- SNUH-3201.hinet.net        0.0%    10    6.2   6.6   6.2   6.8   0.0
  4.|-- TPDT-3011.hinet.net        0.0%    10    7.8   8.8   7.6  10.5   0.7
  5.|-- tpdb-3311.hinet.net        0.0%    10    6.4   6.7   6.3   7.8   0.3
  6.|-- 203-75-228-33.HINET-IP.hi  0.0%    10    7.4   7.3   7.0   7.6   0.0
  7.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  8.|-- edge-star-shv-02-tpe1.fac  0.0%    10    7.3   7.3   6.8   7.7   0.0

而且 Facebook 上的圖片會導到 scontent-tpe.xx.fbcdn.net,這樣產生的量應該不小?而用 Googlescontent-tpe.xx.fbcdn.net,可以看到大約是在 2015/02/14 上線的。

透過幾個不同的 ISP 看了一下 routing,應該是跟國內幾個 ISP 有 peering,沒有的就走 TPIX 交換。

不過學術網路 (TANet) 得繞到香港 HKIX 再回來,這就有點虧了,不曉得 Facebook 對學網是不是吐其他的 endpoint 出去。(有租用國際線路 transit 的學校應該會走租用的國際線路,通常是 TWGate 就交換到 TPIX,不會這樣繞...)

用 mermaid 畫流程圖...

mermaid 這個專案畫出來的圖還蠻順眼,雖然與 DOT graph 的語法不太一樣,不過還是很簡單,看一下介紹就會用了。

cdnjs 上有 hosting,把 code 放到 div 裡面,設定 class="mermaid",然後直接 script 掛進來就可以了。不過最近 CloudFlare 的速度一直很不順,在意的人可以考慮自己 hosting 一份。

簡單的像是這樣:

比較複雜點的:

Amazon Elastic Transcoder 更新:支援 GIF...

本來是不太寫 Amazon Elastic Transcoder 的,但是看到這個實在是...:「Amazon Elastic Transcoder Update – New Formats & Conversion Controls」。

最新支援:影片轉成動態 GIF!

Amazon 你控制一下好嗎 XDDD

MySQL 5.7 的 InnoDB 的全文搜尋

在「InnoDB Full-Text : N-gram Parser」這邊看到對 MySQL 5.7 InnoDB 的全文搜尋功能介紹。開頭就有很重要的說明:

I’m now very happy to say that in MySQL 5.7.6 we’ve made use of the new pluggable full-text parser support in order to provide you with an n-gram parser that can be used with CJK!

這對資料量在中等或是更少的公司相當方便,你可以架 replication server 專門跑 search,而不需要利用 reliable queue 確保更新後推進 SolrElastic (改名了,之前叫 ElasticSearch)。

不過,如果資料量很大的話應該還是得用 Solr 或 Elastic 的方案...

用 Facebook Chat 當作 VPN tunnel...

在同一天的 Hacker News Daily 上看到這兩篇,這是怎樣 XDDD:

RMS 對 Facebook 的意見就不提了,來討論後面這個專案:

The idea of this project is to tunnel Internet traffic through Facebook chat (packets are sent as base64), the main component is tuntap and also the Google's Gumbo parser which does the interaction with Facebook (login, send/receive messages, etc.).

用 C++ 寫的... 不過 Facebook 可以通的環境通常可以有其他的 VPN 選擇吧 @_@

再度改善對 RC4 的攻擊效率...

在「RC4 must die」這個網站寫的真直接,正式標題是「Attacks Only Get Better: Password Recovery Attacks Against RC4 in TLS」。

可以在 226 次嘗試取得 TLS 裡傳輸的 password,相較於之前的 234 低了非常多。另外論文裡也說明了他們成功實作 PoC,取得 IMAP (TLS) 與 HTTP Basic Auth (TLS) 的密碼部份。

不過 RC4 的使用率比想像中高好多 (出自 ICSI Certificate Notary project 的「Connection Cipher Details」數據):

Despite 2013's high-profile attacks on the RC4 algorithm in TLS, its usage is today (March 2015) still running at about 30% of all TLS traffic.

現在的超級低標應該是 TLS 1.0 的 3DES (給 Windows XP + IE8 的情況下用),不過也已經不夠安全,能拔掉的就先拔...

SSD 硬碟的「寫到掛」測試

Slashdot 上的「Endurance Experiment Kills Six SSDs Over 18 Months, 2.4 Petabytes」看到的,針對萬元以下的 SSD 硬碟大量寫入測試 (算是家用級別?),在經過 18 個月後總算都掛光了...

報導出自「The SSD Endurance Experiment: They're all dead」:

最快死透的是 Intel 的,不過也到了 800TB 的寫入量才掛,如果以每天寫 1TB 的量來算也超過兩年了,看了一下我們家比較忙的 database server 也沒這個量啊,這幾年改善好多...

Rowhammer Bug:攻擊記憶體的值...

GoogleProject Zero 實做 Rowhammer Bug:「Exploiting the DRAM rowhammer bug to gain kernel privileges」。

開頭就很科幻:

“Rowhammer” is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows.

然後就提到實做了:

We tested a selection of laptops and found that a subset of them exhibited the problem. We built two working privilege escalation exploits that use this effect.

給出了 NaCl sandbox escape 與 Kernel privilege escalation 兩種方式。

這頭快炸了...