Home » Computer » Network » Cloud » Archive by category "AWS" (Page 53)

AWS Storage Gateway 推出新的模式...

AWS Storage Gateway 推出新的「磁帶」模式:「Create a Virtual Tape Library Using the AWS Storage Gateway」。

原先的 AWS Storage Gateway 只支援兩種模式:

  • Gateway-Cached Volumes:實際資料在 Amazon S3 上,在本地有 cache。
  • Gateway-Stored Volumes:實際資料在本地,定時備份到 Amazon S3 上。

上面兩種方式對於 client 都還是 block storage (random access),可以用 iSCSI 掛上來用。

新的 Gateway-Virtual Tape Library (Gateway-VTL) 則是模擬磁帶架構,除了可以丟到 Amazon S3 上以外,也可以丟到 Amazon Glacier 上!XD

很有趣的架構啊... XD

AWS Direct Connect 向下提供 50Mbps 的連線頻寬...

在「AWS Direct Connect - More Connection Speeds, New Console, Multiple Accounts」這篇文章裡面提到了 AWS Direct Connect 可以接受 50Mbps~500Mbps 的頻寬了,而先前只接受 1Gbps 與 10Gbps...

不過 500Mbps 的頻寬與 1Gbps 頻寬的 port 價錢是相同的,都是 USD$0.3/hour,其他較低的速度就依照 500Mbps 的比率計算。

比較特別的是 50Mbps,是用 QoS 限制頻寬嗎?這樣的速度還蠻特別的...

NSA 與 GCHQ 對抗 Tor 的方式

衛報網站上公開了 NSA (美方) 以及 GCHQ (英方) 如何對抗 Tor 的方式,包含了內部的投影片:「'Tor Stinks' presentation – read the full document」。

投影片上可以看到,居然還有 workshop 可以參加...

下面列出這份投影片的內容,要注意這是 2012 年的資訊了。

事實的介紹

先說明了不可能辨識出所有 Tor 使用者,只能透過人工找出少數的使用者。

接下來說明了目前的概況。目前只能掌握少數的 Tor 節點,其中 entry node 與 exit node 會是辨識出 Tor 使用者的重點,如果能夠增加這些節點的數量,會對於辨識有很大的幫助。

要如何分析這些資訊

透過 cookie 的交叉比對,有機會將 Tor 使用者與真實世界的流量連接起來,像是透過 DoubleclickID 這個值。

接下來是想辦法建立資料庫,將 IP 與時間點的對應建立起來。利用這些資訊才有辦法知道這個 IP 的情況。

技術分析

接下來可以看到各種技術分析。包括對 Hidden Service 的攻擊 (2012 年當時沒有進度),另外試著用 Timing Attack 攻擊 (2012 年當時也沒有進度,不過有在研究了)。

另外在 AWS 上建立節點也是 2012 年當時就進行的項目。

攻擊 Tor

各種攻擊手段,包含了如果有 ISP 可以配合攔截封包時的作法。以及攻擊不屬於自己的節點的方式。再來就是有沒有辦法癱瘓 Tor 節點...

總結

情報單位其實花了非常多力氣研究 Tor,但沒有很好的成果。Tor 算是直接再技術上 (數學上) 抵抗的相當頑強。這部內部文件流出後可以預期會有不少「應用」(只要是英美政府不喜歡的「應用」) 會往上發展。

多增加 Tor 的節點看起來會是目前最直接的抵抗方式,而且這個抵抗方式對於一般人相對容易,達到了擴散容易的效果。

Amazon CloudFront 上 Protected Content 的 URL Sign...

Amazon CloudFront 也可以設定要簽名才能抓檔案,只是 URL Sign 設計的觀念跟 Amazon S3 完全不一樣,這不一致的調調很... 詭異...

大致上有這些差異:

  • Amazon S3 用的是 HMAC-SHA1 的機制簽名 (shared secret,也就是 Amazon S3 與你都有同一把 key),而 Amazon CloudFront 則是用 RSA key 簽名 (public key,也就是 Amazon CloudFront 存放 public key,你自己存放 private key)。
  • 也因為是使用 RSA key,有人會誤解跟 Amazon EC2 用的 RSA key 相同。但實際上需要在 Security Credentials 頁裡設,有專門對 Amazon CloudFront 用的 RSA key 的段落。
  • 自己對 Base64 編碼再處理,避開使用 += 以及 /。但不是有標準可以用嗎,為什麼要自己發明呢...
  • 引入 Policy 的彈性機制,不僅可以對時間控制,也可以對 IP address 控制,但 Policy 這是帶在 URL 裡傳進去的... 你可以看到我的程式碼內產生出 $json_str 後簽完名帶到 URL 內了。

官方的 CloudFront Signed URLs in PHP 這篇的範例程式碼其實很清楚了,要直接拿去用其實也沒麼問題。我自己整理後是這樣:

<?php

$key_pair_id = 'APKA...';
$pem_file = '';
$resource = 'http://test2-cdn.gslin.org/test.txt';

$expires = time() + 3600;

$json_str = json_encode(
    array(
        'Statement' => array(
            array(
                'Resource' => $resource,
                'Condition' => array(
                    'DateLessThan' => array(
                        'AWS:EpochTime' => $expires
                    )
                )
            )
        )
    ),
    JSON_UNESCAPED_SLASHES
);

$buf = file_get_contents($pem_file);
$key = openssl_get_privatekey($buf);

openssl_sign($json_str, $signed_policy, $key, OPENSSL_ALGO_SHA1);

openssl_free_key($key);

$signature = str_replace(
    array('+', '=', '/'),
    array('-', '_', '~'),
    base64_encode($signed_policy)
);

echo "${resource}?",
    "Expires=${expires}&",
    "Signature=${signature}&",
    "Key-Pair-Id=${key_pair_id}\n";

反正你搞不太懂 Amazon 為什麼要這樣設計的... =_=

Amazon S3 上 Protected Content 的 URL Sign...

Amazon S3 可以在上傳時設定為 non-public,這種檔案如果要讓使用者讀取,就必須透過 URL 簽名的方式...

官方的文件是「Authenticating REST Requests」這篇,不過官方文件把所有細節都寫上去,如果第一次接觸的人反而不知道要怎麼辦...

Thomas Riboulet 給了一個 Quickstart 的範例:「Signing Amazon S3 URLs」,裡面雖然是 Ruby code,不過 code 的邏輯很簡單...

以 test.gslin.org 為例,想要產生出從現在開始 3600 秒內有效的 url 可以這樣寫,用過一次後再回去看官方文件,就會發現其實就是官方文件的「REST Authentication Example 3: Query String Authentication Example」這段,如果以 PHP 寫會長這樣:

<?php

$access_key = "";
$secret_key = "";

$timestamp = time() + 3600;
$data = "GET\n\n\n${timestamp}\n/test.gslin.org/test.txt";

$sign = urlencode(
    base64_encode(
        hash_hmac('sha1', $data, $secret_key, true)
    )
);

echo "http://test.gslin.org.s3.amazonaws.com/test.txt?" .
    "AWSAccessKeyId=${access_key}&" .
    "Expires=${timestamp}&" .
    "Signature=${sign}\n";

接下來來研究 CloudFront 的部份...

Amazon RDS 可以直接產生 Read Replica Replication 了...

以往要在 Amazon RDS 產生 Read Replica Replication 需要複雜的 snapshot 處理,但現在 AWS 直接提供這個功能了,而且可以同時生很多台:「New Read Replica Capabilities for Amazon RDS」。

這有多重要呢?以前因應流量瞬間爆增時的方式是增加 web server,並且利用 cache (可能是 memcached) 降低對後端的 query 數量。但因為引入 cache,平常就得處理 cache invalidate 的問題。

而這個方式平常只要處理讀寫分離就可以了。當量爆增時除了 web server 增加,直接增加後端的 RDS server (Read Replica Replication),甚至可以分層:

以目前的步調來看,之後有可能會推出 Master-Master 的 HA 架構?

Update:照 comment 提到的,Multi-AZ 本身就是 HA 架構了...

Archives