Python 2.7 的延伸支援

Python 2 在大約四年前 2020/04/18 推出了最後一版 Python 2.7.18 後,後續的安全性更新就變成要找第三方支援了。

在 2023/09 出的 Trac 1.6 總算是換到 Python 3 後,手上就沒有遇到要用 Python 2.7 的東西了...

剛剛在「PyPy v7.3.16: release of python 2.7, 3.9, and 3.10」這邊看到跟 Python 2.7 有關的消息,一時興起翻了翻有哪些延長的商業支援可以買,看起來有兩個:

真的遇到的話再來寫信問問看好了...

CloudFront 端出 Embedded Points of Presence

看到 CloudFront 的產品新聞稿:「Amazon CloudFront announces availability of Embedded Points of Presence」,AWS 在 CloudFront 上端出了 Embedded Points of Presence 服務,看名字就是更彈性的 CDN PoP,不過想知道更細節的東西得去看 FAQs 的部分...

從這段可以看到應該是 AWS 的 appliance,然後放到實體機房裡面提供服務:

These embedded POPs are owned and operated by Amazon and deployed in the last mile of the ISP/MNO networks to avoid capacity bottlenecks in congested networks that connect end viewers to content sources, improving performance.

比較特別的消息是,這個不會額外收費:

Q. Is there a separate charge for using embedded POPs?
No, there is no additional charge for using CloudFront embedded POPs.

另外這個服務會是 opt-in 選擇加入,但不需要額外設定 distribution,而且 CloudFront 會針對有 opt-in 的 distribution 自動混搭:

Embedded POPs are an opt-in capability intended for the delivery of large scale cacheable traffic. Please contact your AWS sales representative to evaluate if embedded POPs are suitable for your workloads.

No, you do not need to create a new distribution specifically for embedded POPs. If your workload is eligible, CloudFront will enable embedded POPs for your existing distribution upon request.

You don't have to choose between CloudFront embedded POPs or CloudFront POPs for content delivery. Once your CloudFront distribution is enabled for embedded POPs, CloudFront's routing system dynamically utilizes both CloudFront POPs and embedded POPs to deliver content, ensuring optimal performance for end users.

下一章「Compliance」的部分有提到 embedded POPs 是不包括在 PCI DSSHIPAA 以及 SOC 這些 compliance 的,所以也可以回頭看到在提到推薦掛上來的內容,有避開掉敏感服務,主要是以大家都會看到一樣的內容的東西為主:

Embedded POPs are custom built to deliver large scale live-streaming events, video-on-demand (VOD), and game downloads.

看起來有點像是 NetflixOpen Connect 或是 GoogleGGC,讓 ISP 或是 MNO 可以放 cache service 降低對外消耗的流量。

這應該會回到老問題,ISP/MNO 當然是希望 CloudFront 花錢放機器進來,不會是 ISP/MNO 自己申請放,這不是技術問題而是商業問題...

SourceHut 被 DDoS 後的報告

SourceHut 在 DDoS 後發表了報告:「SourceHut network outage post-mortem」。

這次的攻擊在 L3 層,直接塞爆 upstream bandwidth:

At around 06:00 UTC on January 10th, a layer 3 distributed denial-of-service (DDoS) attack began to target SourceHut’s PHL infrastructure.

上游 Cogent 選擇 null route 掉:

In response to the attack, Cogent announced null routes for our downstream AS, causing our PHL network to become unreachable both for SourceHut staff and the general public.

中間有試著問 Cloudflare 以及其他的方案,但依照他們的說法,費用上無法承受:

We initially researched a number of solutions, and spoke to Cloudflare in particular due to their ability to provide a rapid response to ongoing incidents. However, given our complex requirements, Cloudflare quoted us a figure which was not attainable within our financial means as a small company. Other options we researched (though we did not seek additional quotes) had similar economical constraints.

後來的解法是在 OVH 放 proxy server (搭配 OVH 的 DDoS 保護服務),然後導到沒有公開的 subnet:

However, we found that OVH’s anti-DDoS protections were likely suitable: they are effective, and their cost is amortized across all OVH users, and therefore of marginal cost to us. To this end the network solution we deployed involved setting up an OVH box to NAT traffic through OVH’s DDoS-resistant network and direct it to our (secret) production subnet in AMS; this met our needs for end-to-end encryption as well as service over arbitrary TCP protocols.

GitHub 在還沒被 Microsoft 併購前 (2018 年) 也有被打的記錄,2015 年的時候 Google 有放一些資料,當年有寫一篇記錄下來:「Google 對 GitHub 先前遭受 GFW 的 DDoS 攻擊的分析」,不過當年這波是 L7 的。

另外 2016 年的時候 GitHub 也有整理一篇關於 TCP SYN flood 的阻擋方式,這個看起來比較接近這次的攻擊:「GitHub 對抗 TCP SYN Flood 的方式:synsanity」。

2014/2015 年的 Smart Home & IoT 裝置?

昨天的「What's that touchscreen in my room? (laplab.me)」這篇頗有趣的,原文「What's that touchscreen in my room?」是在租屋處看到牆上有一片平板,研究這到底是什麼的文章:

作者在一包文件裡找到手冊以後 (應該是屋主當初直接拿給他的一包文件?),知道這是 NetThings 的設備 (看起來已經是歷史了,這邊留個 LinkedIn 上的連結...):

然後連了半天發現連不上,到公共區域發現他還有一台主機要打開,但因為沒有保險絲,所以沒通電:

在裝了保險絲開機之後就是黑這台機器的過程...?

在各種嘗試中得知,port scan 過程發現有 tcf-agent 可以直接對檔案系統操作,首先是試著撈出 root 加密過的密碼來 john 但不順利,後來是發現可以修改 /etc/shadowroot 密碼清空,並且修改 /etc/ssh/sshd_config,就順利連上了這台機器...

這是一台 ARM9 的機器,有大約 118MB 的記憶體,而且 CPU 可以直接跑 Java bytecode (Jazelle)。

另外這台平板是 Android 5 的系統,透過 webview 從主機上拉狀態出來。

然後裡面有不少 (以現在來看) 古董:

Along with the Pulse app, there is the second part of the application. A Node.js app reads CSV files populated with energy usage data and displays them to the user in the web UI. It uses Node.js 0.10.26, Express.js 4.13.3 and Socket.io 1.3.6.

是個 2014/2015 年左右的產品...

MySQL 5.7 已經 EoL

查資料發現忘記這件事情了... 先前就有寫過 MySQL 5.7 到今年十月就 EoL 了:「MySQL 5.7 的支援只到今年十月 (Oct 2023)」。

最後一版是 2023/10/25 釋出的 5.7.44:「Changes in MySQL 5.7.44 (2023-10-25, General Availability)」。

MySQL 5.7.44 is the final release of the MySQL 5.7 series.

然後 MySQL 8.1 也是十月 EoL。

雖然目前已經有 MySQL 8.2 了,但 MySQL 8.0 是 LTS,目前預定支援到 2026 年四月 (大約還有兩年多),所以除非有需要用到 MySQL 8.2 的新功能或是特性,不然應該還是會先繼續用 MySQL 8.0...

然後翻了一下 Percona Server for MySQL,看起來還是沒有提供 ARM 的 binary 可以裝,所以在 ARM 上面的機器比較方便的還是裝 MariaDB 了...

OpenSSL 1.1.1 EoL

看到 OpenSSL 官方的公告,1.1.1 版 EoL:「OpenSSL 1.1.1 End of Life」(btw,我不知道他們為什麼網址上會放兩個 /blog/...)。

OpenSSL 1.x 與 3.x 最大的差異就是他的 license 了,1.x 版是 dual license,但這兩個 license 都與 GPL 不相容:

OpenSSL was dual-licensed under the OpenSSL License and the SSLeay License, which means that the terms of either licenses can be used. The OpenSSL License is Apache License 1.0 and SSLeay License bears some similarity to a 4-clause BSD License.

As the OpenSSL License was Apache License 1.0, but not Apache License 2.0, it requires the phrase "this product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit" to appear in advertising material and any redistributions (Sections 3 and 6 of the OpenSSL License). Due to this restriction, the OpenSSL License and the Apache License 1.0 are incompatible with the GNU GPL.

後續 3.x 的版本則改成 Apache License 2.0 了:

OpenSSL announced in August 2015 that it would require most contributors to sign a Contributor License Agreement (CLA), and that OpenSSL would eventually be relicensed under the terms of Apache License 2.0.

不過 Apache License 2.0 與 GPLv2 還是不相容 (但相容於 GPLv3),這個更換只是換成一個比較常見的 license:

The Free Software Foundation considers all versions of the Apache License to be incompatible with the previous GPL versions 1 and 2.

話說 Ubuntu 20.04 內的 OpenSSL 是 1.1.1f,看起來光是標準的 LTS (到 2025/04) 期間都得自己維護了?其他作業系統應該也會有類似的問題...

Tor 的 Onion 導入防禦機制,在遭受 DoS 的時候要求用戶端執行 PoW 任務

在「Introducing Proof-of-Work Defense for Onion Services」這邊看到 0.4.8 的新機制,當 Onion 服務受到 DoS 時,會需要 client 提供 PoW 證明,有證明的會優先處理:

Tor's PoW defense is a dynamic and reactive mechanism, remaining dormant under normal use conditions to ensure a seamless user experience, but when an onion service is under stress, the mechanism will prompt incoming client connections to perform a number of successively more complex operations. The onion service will then prioritize these connections based on the effort level demonstrated by the client.

主要原因是傳統遇到 DoS 時可以透過 IP address 之類的資訊設計阻擋機制,但在 Onion 服務裡面沒有這個資訊,所以需要其他方式阻擋:

The inherent design of onion services, which prioritizes user privacy by obfuscating IP addresses, has made it vulnerable to DoS attacks and traditional IP-based rate limits have been imperfect protections in these scenarios. In need of alternative solutions, we devised a proof-of-work mechanism involving a client puzzle to thwart DoS attacks without compromising user privacy.

這個 PoW 機制的說明可以在「torspec/proposals/327-pow-over-intro.txt」這邊看到,看起來是三年前 (2020/04/02) 就提出來了,直到 0.4.8 才推出。

裡面有提到 PoW 的演算法是用 Equi-X

For our proof-of-work function we will use the Equi-X scheme by tevador [REF_EQUIX].

看起來是個方法,而且從 cryptocurrency 後大家對 PoW 的用法愈來愈熟悉了,在這邊用還不錯...

Imgur 改變使用條款,把 Imgur 的圖片都搬回本機上

Hacker News 上看到 Imgur 的使用者條款改變的消息:「Imgur will ban explicit images on its platform this month」,在 TechCrunch 文章標題提到的東西對 blog 影響不大,反倒是公告裡面另外提到的事情比較傷。

Imgur 在「Imgur Terms of Service Update [April 19, 2023]」這邊提到了:

Our new Terms of Service will go into effect on May 15, 2023. We will be focused on removing old, unused, and inactive content that is not tied to a user account from our platform as well as nudity, pornography, & sexually explicit content.

所以很少被存取的內容也會有機會被移除掉,這導致一堆小的 blog 或是 forum 用到的內容也會爛掉。

所以決定先搬出來,掃了一下 WordPress 資料庫裡面的內容,把檔案先拉下來,弄個 CloudFront 擋在前面 (有 free quota 的關係),然後把資料庫裡面的連結整批換掉。

另外是新的內容要丟哪裡,所以用 PHP 寫了一個很簡單的 self-hosted image server,程式碼在 GitHub 上面可以翻到:「i.gslin.com」。

裡面除了 PHP 以外,也練了一下 javascript,收 paste 事件把 image/png 的資料用 fetch() 傳到 server 端處理。

現在功能還很陽春,但至少能開始用,之後再逐步加功能上去。等功能變多變複雜之後,可能會用 Composor 掛套件上去... 但現在還算簡單,一個 upload.php 處理所有事情就好。

ISC DHCPD 要 EoL

看到「ISC DHCP Server has reached EOL」這個,月初的時候 ISC 宣佈了 EoL,除非有嚴重的安全性問題冒出來,不然官方打算停止維護了:

The 4.4.3-P1 and 4.1-ESV-R16-P2 versions of ISC DHCP, released on October 5, 2022, are the last maintenance versions of this software that ISC plans to publish. If we become aware of a significant security vulnerability, we might make an exception to this, but it is our intention to cease actively maintaining this codebase.

ISC 則是在推 Kea

Network and system administrators deploying DHCP in new environments should look beyond ISC DHCP for a solution, as it would be irresponsible to invest in new deployments of this software which is now end-of-life. Naturally, ISC suggests new users consider our Kea DHCP server, but there are alternatives.

從維基百科上的「Comparison of DHCP server software」這頁可以看到目前 DHCP server 的選擇。最直接的差異是,其他非 ISC 的全部都是 GPL,只有 ISC 的是 non-GPL。

不過一般不太會自己架 DHCP server,大多是用設備內建裝的跑,以後如果有機會要裝的話,也許得去熟悉 Kea 了...

Let's Encrypt 更新了 ToS

在「Let's Encrypt’s subscriber agreement changes on Sept 21 (letsencrypt.org)」這邊看到的,Let's Encrypt 有提供 diff 的內容,在「LE-SA-v1.2-v1.3-diff.docx」這邊,你也可以用 Google Docs Viewer 看:「LE-SA-v1.2-v1.3-diff.docx」。

看起來主要是用語上的改變 (可能是律師的建議?),除了 revoke 的章節外看起來沒什麼大變化。而 revoke 的章節部份增加了這兩段文字:

You warrant to ISRG and the public-at-large, and You agree, that before providing a reason for revoking Your Certificate, you will have reviewed the revocation guidelines found in the “Revoking Certificates” section of the Let’s Encrypt documentation available at https://letsencrypt.org/docs/ , and that you will provide Your corresponding revocation reason code with awareness of such guidelines.

You acknowledge and accept that ISRG may modify any revocation reason code provided by You if ISRG determines, in its sole discretion, that a different reason code for revocation is more appropriate or is required by industry standards.

不確定自動化的 client 需不需要重新再 accept 一次?