AWS 提供 VPC Traffic Mirroring 的功能

以前在機房可以在 switch 上用 port mirror 看流量內容找問題,現在在 AWS 上也提供類似的功能 VPC Traffic Mirroring:「New – VPC Traffic Mirroring – Capture & Inspect Network Traffic」。

所以所有以前在傳統機房使用 switch 的技術,都可以在 AWS 上重新發展出來,所以不算太意外的是第一波就有一堆 partner 提供服務,或是一些公司提供經驗。

另外 AWS 的 VPC Traffic Mirroring 比以前 switch 的 port mirror 更彈性,可以把整個網路當來源,或是指定特定的 ENI 當來源:

Mirror Source – An AWS network resource that exists within a particular VPC, and that can be used as the source of traffic. VPC Traffic Mirroring supports the use of Elastic Network Interfaces (ENIs) as mirror sources.

然後除了可以打到 ENI 上,也可以打到 NLB 上:

Mirror Target – An ENI or Network Load Balancer that serves as a destination for the mirrored traffic. The target can be in the same AWS account as the Mirror Source, or in a different account for implementation of the central-VPC model that I mentioned above.

不免俗的,可以過濾封包:

Mirror Filter – A specification of the inbound or outbound (with respect to the source) traffic that is to be captured (accepted) or skipped (rejected). The filter can specify a protocol, ranges for the source and destination ports, and CIDR blocks for the source and destination. Rules are numbered, and processed in order within the scope of a particular Mirror Session.

然後有判斷 session 的能力 (看這邊的敘述,應該就是指 stateful connection?):

Traffic Mirror Session – A connection between a mirror source and target that makes use of a filter. Sessions are numbered, evaluated in order, and the first match (accept or reject) is used to determine the fate of the packet. A given packet is sent to at most one target.

而且這一次公佈就幾乎開放所有區域了,費用看起來也不太貴:

VPC Traffic Mirroring is available now and you can start using it today in all commercial AWS Regions except Asia Pacific (Sydney), China (Beijing), and China (Ningxia). Support for those regions will be added soon. You pay an hourly fee (starting at $0.015 per hour) for each mirror source; see the VPC Pricing page for more info.

nginx 1.15.2 開始支援單一 Port 多服務...

nginx 的新功能,單一 port 支援多服務:「Running SSL and Non-SSL Protocols over the Same Port with NGINX 1.15.2」,最常見的還是混搭 SSH 了:

One key feature in this release is the new $ssl_preread_protocol variable, which allows you to distinguish between SSL/TLS and other protocols when forwarding traffic using a TCP (stream) proxy. This is useful if you want to avoid firewall restrictions by (for example) running SSL/TLS and SSH services on the same port.

雖然 L7 firewall 還是可以看出來 (並且擋下),但簡易的 firewall 就可以用這個方式穿過去了...

Cloudflare 推出 Spectrum:65535 個 TCP Port 都可以轉的 Proxy...

Cloudflare 推出了 Spectrum,文章標題提到的 65533 應該是指 80 & 443 以外其他的 port:「Introducing Spectrum: Extending Cloudflare To 65,533 More Ports」。

然後因為 TCP proxy 不像 HTTP proxy 與 WebSocket proxy 可以靠 Host header 資訊判斷,在 TCP proxy 需要獨占 IP address 使用 (i.e. 一個 IP address 只能給一個客戶用),而因為 IPv4 address 不夠的關係,這個功能只開放給 Enterprise 客戶用:

Today we are introducing Spectrum, which brings Cloudflare’s security and acceleration to the whole spectrum of TCP ports and protocols for our Enterprise customers.

雖然現在限定在 Enterprise 客戶,但 Cloudflare 還是希望看看有沒有其他想法,目前提出來的選項包括了開放 IPv6 address 給所有人用,或是變成獨立付費項目:

Why just Enterprise? While HTTP can use the Host header to identify services, TCP relies on each service having a unique IP address in order to identify it. Since IPv4 addresses are endangered, it’s quite expensive for us to delegate an IP per application and we needed to limit use. We’re actively thinking about ways to bring Spectrum to everyone. One idea is to offer IPv6-only Spectrum to non-Enterprise customers. Another idea is let anyone use Spectrum but pay for the IPv4 address. We’re not sure yet, but if you prefer one to the other, feel free to comment and let us know.

類似的產品應該是 clean pipe 類的服務,但一般 clean pipe 是透過 routing 重導清洗流量,而非像 Cloudflare 這樣設計... 不知道後續會有什麼樣的變化。

透過 memcached UDP (Port 11211) 的攻擊...

Cloudflare 發表了一篇關於公開的 memcached 伺服器,利用 UDP (Port 11211) 的放大攻擊:「Memcrashed - Major amplification attacks from UDP port 11211」。

用地圖展示後可以清楚看出來哪些區域受到的攻擊比較大:

另外 Shodan 上的資料頁可以參考,不過就不保證都有開 UDP/11211 了:

這種伺服器還是藏到內部網路啦...

Cloudflare 推出的 Wrap 讓你不用在本地端開對外的 Port 80/443

Cloudflare 推出了 Wrap 服務:「Want to try Warp? We just enabled the beta for you」。

本地端的 web server 可以只開 127.0.0.1:{80,443},然後 Wrap 的程式會連到 Cloudflare 上面接 web request 回來打到你本地端的電腦上,官方舉的例子用 port 8080:

$ cloudflare-warp --hostname warp.example.com http://localhost:8080

然後也支援多台機器接同一個 hostname (load balancing,順便做 high availability):

$ cloudflare-warp --hostname warp.example.com --lb-pool origin-pool-1 http://localhost:8080

對於安全架構多了一些選擇可以用...

AWS 推出 Cloud Native Networking,在每個 Container 內都有自己獨立的網路卡

AWSAmazon ECS 變得更好用了:「Introducing Cloud Native Networking for Amazon ECS Containers」。

Today, AWS announced task networking for Amazon ECS. This feature brings Amazon EC2 networking capabilities to tasks using elastic network interfaces.

awsvpc 模式下會給每個 container 一個獨立的網路卡 (Elastic Network Interface,ENI):

這樣有兩個好處。第一個是 port 就不需要拆開,所有 container 如果都是跑 nginx,都可以跑在同一個 port (80 或是 443),這對於前端應用程式會簡單一些。第二個整合了 AWS 的 security group,這對在 AWS 上本來就會使用 security group 的大多數人來說就可以輕鬆整合了。

SSH 在 Port 22 的故事

雖然現在全世界都在用 OpenSSH,但當初 SSH 其實是 SSH Communications Security 所發展出來的。最近上面在講當初申請 port 22 的故事:「How SSH Port Became 22」。

選 port 22 是因為剛好要取代 port 21 的 ftp 與 port 23 的 telnet:

Anyway, I designed SSH to replace both telnet (port 23) and ftp (port 21). Port 22 was free. It was conveniently between the ports for telnet and ftp. I figured having that port number might be one of those small things that would give some aura of credibility. But how could I get that port number? I had never allocated one, but I knew somebody who had allocated a port.

而後來就寫信去要 port 22 這個位置...

掃整個 Internet 的 Port 22...

平常都是掃 Port 80/443,然後就有人跑去掃 Port 22:「We scanned the Internet for port 22」。依照原文說的,這次給的數據只是 60% 的 Internet,其他 40% 的資料有問題,他要再想辦法修...

這是 Top 20 的 unique banner 數據:

 1730887 SSH-2.0-OpenSSH_4.3
 1562709 SSH-2.0-OpenSSH_5.3
 1067097 SSH-2.0-dropbear_0.46
  824377 SSH-2.0-dropbear_0.51
  483318 SSH-2.0-dropbear_0.52
  348878 SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
  327841 SSH-1.99-Cisco-1.25
  320539 SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze3
  318279 SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
  307028 SSH-2.0-ROSSSH
  271614 SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze2
  233842 SSH-2.0-OpenSSH_5.1p1 Debian-5
  225095 SSH-2.0-OpenSSH_5.1
  224991 SSH-2.0-OpenSSH_5.1p1 FreeBSD-20080901
  213201 SSH-2.0-OpenSSH_4.7
  209023 SSH-2.0-OpenSSH_6.0p1 Debian-4
  195977 SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7
  140809 SSH-2.0-dropbear_0.50
  135821 SSH-2.0-OpenSSH
  132351 SSH-2.0-Cisco-1.25

可以看到 OpenSSH 是最大宗,而 dropbear 應該是各種 box 的量撐起來的...

參考維基百科上 OpenSSH 的條目,OpenSSH 的各版本的發行日期分別是:

  • 3.5:2002/10/14 (FreeBSD 4.11)
  • 4.3:2006/02/01
  • 4.7:2007/09/04
  • 5.1:2008/07/21
  • 5.3:2009/10/01
  • 5.4:2010/03/08 (FreeBSD 8.3)
  • 5.5:2010/04/16 (Debian 6)
  • 5.7:2011/01/24
  • 5.8:2011/02/04 (FreeBSD 9.1)
  • 5.9:2011/09/06
  • 6.0:2012/04/22 (Debian 7)
  • 6.1:2012/08/29 (FreeBSD 8.4)

後面的作業系統是就手上有的機器來看,不過 4.3 是最多的是怎麼一回事呢... 作者這樣解釋:

Note that these counts are a bit off. Some networks have a router that forwards all connections of a certain port to a single machine. Maybe "OpenSSH_4.3" is most popular banner, or maybe the national ISP of Elbonia just reroutes all port 22 requests.

所以有可能只是個假象?XD

ISP 架設 NAT 解決 IPv4 不夠的問題...

Slashdot 上看到 PlusNet 決定測試用 CGNAT (Carrier-grade NAT) 解決 IPv4 不夠的問題:「UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6」。

用超大型 NAT 並不是特別的新聞 (某些 mobile network 上就是這樣做),但 ISP 如果用在一般網路上則很有可能會跟客戶的 NAT device (可能是公司,也可能是家庭) 發生 Private Network 相同而導致問題。

2012 年 4 月的 RFC 6598 (IANA-Reserved IPv4 Prefix for Shared Address Space) 將 100.64.0.0/10 (Shared Address Space) 這個網段保留,拿來給營運 CGNAT 的 ISP 使用:

NetRange:       100.64.0.0 - 100.127.255.255
CIDR:           100.64.0.0/10
OriginAS:
NetName:        SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
NetHandle:      NET-100-64-0-0-1
Parent:         NET-100-0-0-0-0
NetType:        IANA Special Use

在 RFC 裡規定 100.64.0.0/10 只能拿來內部使用不得交換;如果要交換必須要有能力將不同介面的 100.64.0.0/10 當作不同網段 NAT (也就是 CGNAT 會做的事情):

In particular, Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces.

另外文件裡還定義了使用 100.64.0.0/10 時對 DNS 的過濾。

如果 CGNAT 上不能打洞,那麼很多應用就很苦了 (得靠 UDP hole punching 打洞,這還得在沒有 randomized NAT port 的情況下才打的通),不過非 P2P 的應用應該不會有問題...

會不會做一做之後就維持這個方式?IPv6 遙遙無期... XD