Home » Computer » Archive by category "Security" (Page 3)

DNSFilter 使用 InfluxDB 與 TimescaleDB 的過程

DNSFilter 這篇講 InfluxDBTimescaleDB 的文章頗有趣的:「Towards 3B time-series data points per day: Why DNSFilter replaced InfluxDB with TimescaleDB」。

在沒有實際用過之前,其實都只能算是一方之詞... 另外這種轉換其實也跟每個公司內的組織組成有關,像是熟悉 PostgreSQL 的單位就比較有機會用 TimescaleDB 解決 time series data 的問題。

不過有個地方倒是讓我想記錄起來:

Comparing TimescaleDB to InfluxDB at the same time — we realized we were losing data. InfluxDB relied on precisely timed execution of rollup commands to process the last X minutes of data into rollups. Combined with our series of rollups, we realized that some slow queries were causing us to lose data. The TimescaleDB data had 1–5% more entries! Also we no longer had to deal with cardinality issues, and could show our customers every last DNS request, even at a monthly rollup.

會掉資料等於是跟 InfluxDB 的使用者發出警訊,要大家確認自己手上的資料是否正確... 這對於正確性要求 100% 的應用就不是開玩笑了 @_@

GitHub 在 2/28 遭受的攻擊...

GitHub 在 2/28 遭受 DDoS 攻擊,蠻快就把事故報告丟出來了:「February 28th DDoS Incident Report」。

不過跟 GitHub 其他文章不太一樣,這篇算是 PR 稿吧,簡單來說就是花錢買 Akamai Prolexic 的過濾服務解決... Akamai 方的 PR 稿則是在「Memcached-fueled 1.3 Tbps attacks - The Akamai Blog」這邊可以看到。

17:21 UTC 發現問題,然後判斷超過 100Gbps,所以 17:26 決定讓 Akamai Prolexic 接管過濾:

At 17:21 UTC our network monitoring system detected an anomaly in the ratio of ingress to egress traffic and notified the on-call engineer and others in our chat system. This graph shows inbound versus outbound throughput over transit links:

Given the increase in inbound transit bandwidth to over 100Gbps in one of our facilities, the decision was made to move traffic to Akamai, who could help provide additional edge network capacity. At 17:26 UTC the command was initiated via our ChatOps tooling to withdraw BGP announcements over transit providers and announce AS36459 exclusively over our links to Akamai. Routes reconverged in the next few minutes and access control lists mitigated the attack at their border. Monitoring of transit bandwidth levels and load balancer response codes indicated a full recovery at 17:30 UTC. At 17:34 UTC routes to internet exchanges were withdrawn as a follow-up to shift an additional 40Gbps away from our edge.

就這樣而已,完全就是 PR 稿 XDDD

加州在四月將會開放無人自駕車上路了...

TechCrunch 看到加州要開放自駕車上路了:「California to allow testing of self-driving cars without a driver present」。

California’s Department of Motor Vehicles established new rules announced Monday that will allow tech companies and others working on driverless vehicle systems to begin trialling their cars without a safety driver at the wheel. The new rules go into effect starting April 2.

不過不是完全獨立運作,而是有附加條件,讓遠端的控制中心可以在必要時介入:

This doesn’t mean test vehicles will be out there on the roads without any kind of human intervention backup – the DMV will require that those testing autonomous cars without a driver present have a dedicated communications channel that ties the car to a remote operator, who can take over if needed. The cars will also need to be hardened against cyber attacks and be able to provide their owner and operator info to any other parties in the event of an accident.

馬上想到刷機 JB... XD

Let's Encrypt 的 Wildcard Certificate 將會再延...

先前有提到 Let's Encrypt 的 Wildcard Certificate 從一月延到二月底 (表訂 2/27,參考先前的「Let's Encrypt 的 Wildcard SSL Certificate 延至二月底推出」這篇),今天想說歐美的時區也差不多要過完 2/27 了,結果翻資料發現在「ACMEv2 and Wildcard Launch Delay」這邊又宣佈延期了,這次也不給時間了 XDDD

主要是 TLS-SNI 認證方式的前提有問題,導致 Let's Encrypt 臨時調度人力處理這個包 (可以參考「2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure」這篇,裡面有提到共用產生的問題假設):

The biggest reason for this delay is the recent TLS-SNI deprecation. This unexpectedly pulled most engineering resources away from ACMEv2 and wildcard support for approximately two weeks.

然後 2/27 的說明提到目前是沒什麼大問題,但目前還在 QA 階段,然後目前先不給 release date:

Feb 27 Update: There are no known major issues with the ACMEv2/wildcard test endpoint. ACMEv2 and wildcard support quality assurance is continuing. No release date to announce yet.

就只能繼續等了... XD

Inter-Region VPC Peering 的範圍大幅增加

AWS 的 Inter-Region VPC Peering 又多了不少區域了:「Inter-Region VPC Peering is Now Available in Nine Additional AWS Regions」。

本來是支援 us-{east,west}-{1,2} 這四個,現在又多了 9 個,來到了 13 個:

Starting today, Inter-Region Virtual Private Cloud (VPC) Peering is available in AWS EU (London), EU (Ireland), EU (Paris), Asia Pacific (Mumbai), Asia Pacific (Sydney), Asia Pacific (Singapore), Asia Pacific (Tokyo), Canada (Central) and South America (São Paulo) Regions in addition to AWS US East (Northern Virgina), US East (Ohio), US West (Northern California), US West (Oregon) Regions.

與現在的 region 表格比較,剩下的是 ap-northeast-2 (南韓首爾) 與 eu-central-1 (德國法蘭克福),其他公開使用的區域都在這波的公告全上了。(也就是美國政府專屬區域與中國區不算在內)

Archives