辭職工資怎么結(jié)算(提前一個辭職工資怎么結(jié)算)
2023-07-10
更新時間:2023-07-10 09:02:43作者:未知
DDoS是什么意思,DDoS介紹與防御方法。這個問題本站為您提供更多相關(guān)信息讓你了解。
https://github.com/poornigga/tfn2k.git
https://github.com/cxueqin/falcon.git //tfn2k web版本
https://github.com/GinjaChris/pentmenu.git
https://github.com/OffensivePython/Saddam.git
https://github.com/649/Memcrashed-DDoS-Exploit
SYN FLOOD攻擊是在TCP三次握手過程中產(chǎn)生的。攻擊者通過發(fā)送大量偽造的帶有SYN標志位的TCP報文,與目標主機建立了很多虛假的半開連接,在服務器返回SYN+ACK數(shù)據(jù)包后,攻擊者不對其做出響應,也就是不返回ACK數(shù)據(jù)包給服務器,這樣服務器就會一直等待直到超時。這種攻擊方式會使目標服務器連接資源耗盡、鏈路堵塞,從而達到拒絕服務的目的。
ACK FLOODACK FLOOD攻擊是利用TCP三次握手過程。這里可以分為兩種。
第一種:攻擊者偽造大量的SYN+ACK包發(fā)送給目標主機,目標主機每收到一個SYN+ACK數(shù)據(jù)包時,都會去自己的TCP連接表中查看有沒有與ACK的發(fā)送者建立連接 ,如果有則發(fā)送ACK包完成TCP連接,如果沒有則發(fā)送ACK+RST 斷開連接。但是在查詢過程中會消耗一定的cpu計算資源。如果瞬間收到大量的SYN+ACK數(shù)據(jù)包,將會消耗服務器的大量cpu資源,導致正常的連接無法建立或增加延遲,甚至造成服務器癱瘓、死機。
第二種:利用TCP三次握手的ACK+SYN應答,攻擊者向不同的服務器發(fā)送大量的SYN請求,這些SYN請求數(shù)據(jù)包的源IP均為受害主機IP,這樣就會有大量的SYN+ACK應答數(shù)據(jù)包發(fā)往受害主機,從而占用目標的網(wǎng)絡帶寬資源,形成拒絕服務。
TCP RST FloodTCP協(xié)議頭部有一個標志位稱為“RST”位,正常的數(shù)據(jù)包中該位為0,一旦該位設置為1,則接收該數(shù)據(jù)包的主機將立即斷開TCP會話。TCP Reset攻擊中,攻擊者可以偽造TCP連接其中的一方給另一方發(fā)送帶有RST位的包來斷開TCP連接,但是要確保這個數(shù)據(jù)包的源IP地址、源端口號、目的IP地址、目的端口號、序列號等特征符合已有TCP連接的特征。UDP協(xié)議與TCP協(xié)議不同, UDP是一個無連接協(xié)議。使用UDP協(xié)議傳輸數(shù)據(jù)之前,客戶端和服務器之間不建立連接,UDP Flood屬于帶寬類攻擊,黑客們通過僵尸網(wǎng)絡向目標服務器發(fā)起大量的UDP報文,可以使用小數(shù)據(jù)包(64字節(jié))進行攻擊,也可以使用大數(shù)據(jù)包(大于1500字節(jié),以太網(wǎng)MTU為1500字節(jié))進行攻擊。大量小數(shù)據(jù)包會增大網(wǎng)絡設備處理數(shù)據(jù)包的壓力;而對于大數(shù)據(jù)包,網(wǎng)絡設備需要進行分片、重組,迅速造成鏈路擁塞。
BlackNurse攻擊基于Type3(Destination Unreachable) Code3(Port Unreachable)——端口不可達,當目標端口不可達,所發(fā)出的ICMP包都會返回源。攻擊者可以通過發(fā)這種特定的ICMP包令大多數(shù)服務器防火墻的CPU過載。一旦設備拋棄的包到了臨界值15Mbps至18Mbps(每秒4萬到5萬個包),設備就會直接停止響應。
ICMP Smurf攻擊攻擊者向網(wǎng)關(guān)發(fā)送ICMP請求包,并將該ICMP請求報文的源地址偽造成受害主機IP地址,目的地址為廣播地址。路由器在接受到該數(shù)據(jù)包,發(fā)現(xiàn)目的地址是廣播地址,就會將該數(shù)據(jù)包廣播出去,局域網(wǎng)內(nèi)所有的存活主機都會受到一個ICMP請求包,源地址是受害主機IP。接下來受害主機就會收到該網(wǎng)絡內(nèi)所有主機發(fā)來的ICMP應答報文,通過大量返回的ICMP應答報文來淹沒受害主機,最終導致網(wǎng)絡阻塞,受害主機崩潰。
防御:
SYNCheck:使用防護設備,3次握手變成了6次握手,由防護設備檢測SYN請求是否合法,通過后再由防護設備將報文轉(zhuǎn)發(fā)給服務器,后續(xù)報文仍由防護設備代理。
Micro blocks:管理員可以在內(nèi)存中為每個SYN請求創(chuàng)建一個小索引(小于16字節(jié)),而不必把整個連接對象存入內(nèi)存。
RST cookies:在客戶端發(fā)起第一個SYN請求后,服務器故意回應一個錯誤的SYN+ACK報文。如果合法用戶收到這個報文,就會給服務器響應RST報文。當服務器收到這個報文時,就將這個主機的IP記錄進合法IP列表,下次該主機發(fā)起SYN請求時,就可以直接通過了。
STACK tweaking:管理員可以調(diào)整TCP堆棧以減緩SYN泛洪攻擊的影響。這包括減小超時時間,等到堆棧存釋內(nèi)放時再分配連接,否則就隨機性地刪除傳入的連接。
最初防火墻對UDP Flood的防御方式就是限流,通過限流將鏈路中的UDP報文控制在合理的帶寬范圍之內(nèi)。
防火墻上針對UDP Flood的限流有三種:
基于目的IP地址的限流:即以某個IP地址作為統(tǒng)計對象,對到達這個IP地址的UDP流量進行統(tǒng)計并限流,超過部分丟棄。
基于目的安全區(qū)域的限流:即以某個安全區(qū)域作為統(tǒng)計對象,對到達這個安全區(qū)域的UDP流量進行統(tǒng)計并限流,超過部分丟棄。
基于會話的限流:即對每條UDP會話上的報文速率進行統(tǒng)計,如果會話上的UDP報文速率達到了告警閾值,這條會話就會被鎖定,后續(xù)命中這條會話的UDP報文都被丟棄。當這條會話連續(xù)3秒或者3秒以上沒有流量時,防火墻會解鎖此會話,后續(xù)命中此會話的報文可以繼續(xù)通過。
針對UDP Flood的指紋學習功能。
從下面的抓包中可以看出,到達相同目的IP地址的兩個UDP報文的載荷是完全一樣的,如果防火墻收到大量的類似這樣的UDP報文,那么就有可能是發(fā)生了UDP Flood攻擊。
不難發(fā)現(xiàn),UDP Flood攻擊報文具有一定的特點,這些攻擊報文通常都擁有相同的特征字段,比如都包含某一個字符串,或整個報文內(nèi)容一致。這些字段來自于DDoS工具自帶的默認字符串,所以防火墻是通過收集這些字符串來檢測UDP Flood。這種防御算法在現(xiàn)網(wǎng)使用很多,主要因為黑客為了加大攻擊頻率,快速、長時間擠占攻擊目標所在網(wǎng)絡帶寬,在使用攻擊工具實現(xiàn)時直接在內(nèi)存存放一段內(nèi)容,然后高頻發(fā)送到攻擊目標,所以攻擊報文具有很高的相似性。而正常業(yè)務的UDP報文一般每個報文負載內(nèi)容都是不一樣的,這樣可以減少誤判。
指紋學習是通過分析客戶端向服務器發(fā)送的UDP報文載荷是否有大量的一致內(nèi)容,來判定這個UDP報文是否異常。防火墻對到達指定目的地的UDP報文進行統(tǒng)計,當UDP報文達到告警閾值時,開始對UDP報文的指紋進行學習。如果相同的特征頻繁出現(xiàn),就會被學習成指紋,后續(xù)命中指紋的報文判定這是攻擊報文,作為攻擊特征進行過濾。
防火墻防御UDP Flood攻擊主要有兩種方式:限流和指紋學習,兩種方式各有利弊。限流方式屬于暴力型,可以很快將UDP流量限制在一個合理的范圍內(nèi),但是不分青紅皂白,超過就丟,可能會丟棄一些正常報文;而指紋學習屬于理智型,不會隨意丟棄報文,但是發(fā)生攻擊后需要有個指紋學習的過程。目前,指紋學習功能是針對UDP Flood攻擊的主流防御手段,在華為防火墻產(chǎn)品中廣泛應用。
細化的流程大概就是:
第一步進行報文合法性檢查,過濾一些畸形報文攻擊;
第二步進行特征過濾,即基于報文特征匹配進行過濾,主要過濾一些UDP Flood和UDP反射放大攻擊;
第三步進行虛假源認證,可過濾一些虛假源發(fā)起的TCP SYN Flood;
第四步進行應用層源認證,過濾各類型的應用層攻擊,例如DNS Query Flood, HTTP Get Flood.
HTTP Post Flood. HTTPS Flood等;
第五步進行會話分析,即進行會話檢查來防范一些會話類攻擊,例如TCP ACK Flood, FIN/RST Flood, TCP連接耗盡攻擊、TCP重傳攻擊、DNS緩存投毒、SSL-DoS/DDOS, HTTP slow header/post
攻擊等;
第六步進行行為分析,根據(jù)用戶訪問流量的突發(fā)性和攻擊流量的頻率均勻
且資源均勻的不同,可識別出CC攻擊、慢速SYN Flood和報文負載有特征的UDP
Flood;
第七步進行智能限速,像ICMP沒有對應業(yè)務系統(tǒng),可以直接限速。完成前六步的過濾后流量依然超過鏈路負載閾值
時,利用基于各種協(xié)議的精細化限速使得流量大小穩(wěn)定在安全范圍內(nèi)。
DPDK全稱Intel Data Plane Development Kit,是intel提供的數(shù)據(jù)平面開發(fā)工具集,為Intel architecture(IA)處理器架構(gòu)下用戶空間高效的數(shù)據(jù)包處理提供庫函數(shù)和驅(qū)動的支持。通俗地說,就是一個用來進行包數(shù)據(jù)處理加速的軟件庫。
DPDK不同于Linux系統(tǒng)以通用性設計為目的,而是專注于網(wǎng)絡應用中數(shù)據(jù)包的高性能處理。具體體現(xiàn)在DPDK應用程序是運行在用戶空間上利用自身提供的數(shù)據(jù)平面庫來收發(fā)數(shù)據(jù)包,繞過了Linux內(nèi)核協(xié)議棧對數(shù)據(jù)包處理過程。它不是一個用戶可以直接建立應用程序的完整產(chǎn)品,不包含需要與控制層(包括內(nèi)核和協(xié)議堆棧)進行交互的工具。
傳統(tǒng)Linux內(nèi)核讀取數(shù)據(jù)包使用中斷模式驅(qū)動首先當數(shù)據(jù)包到達網(wǎng)卡后,網(wǎng)卡產(chǎn)生硬中斷,將網(wǎng)卡加入到輪詢輸入數(shù)據(jù)包的網(wǎng)卡隊列中,然后關(guān)閉硬中斷并開啟軟中斷,此時硬中斷處理結(jié)束,軟中斷被激活后輪詢設備,讀取指定量的數(shù)據(jù)包后清空設備隊列,至此結(jié)束軟中斷。對于在大流量下的服務器來說會在硬中斷和軟中斷上浪費大量的時間,所以DPDK采用輪詢模式驅(qū)動,收到數(shù)據(jù)包后直接通過DMA方式傳送到預分配內(nèi)存并直接處理,避免了中斷下文切換開銷,對于高并發(fā)大流量的系統(tǒng)來說會極大的提高數(shù)據(jù)包處理效率和性能。另外DPDK的輪詢模式驅(qū)動還用到了用戶空間設備驅(qū)動程序(Userspace I/O, uio),將絕大部分程序放到用戶空間實現(xiàn),減少了內(nèi)核空間的程序,使得uio的開發(fā)與維護都很方便,避免了過度依賴內(nèi)核版本導致開發(fā)調(diào)試復雜。DPDK在使用uio的同時還利用mmap技術(shù)將網(wǎng)卡緩存映射到用戶空間,使得報文不需要經(jīng)過內(nèi)核空間處理,減少了報文從內(nèi)核空間到用戶空間的拷貝。
傳統(tǒng)Linux內(nèi)核的多核系統(tǒng)中運行程序會使用負載均衡機制,即某個進程在哪個核中運行是不確定的,內(nèi)核根據(jù)各CPU負載情況來統(tǒng)一調(diào)度,這樣會造成一個進程在運行過程中會在各CPU之間頻繁切換,導致資源開銷增大。此外切換CPU時從內(nèi)存中預先獲取的CPU Cache也會失效,降低了CPU Cache的命中概率。DPDK利用線程的CPU親和綁定機制使得特定任務能夠被指定在某個特定的核上執(zhí)行,這樣可避免線程在不同核之間頻繁轉(zhuǎn)換而導致的因cache miss和cachewrite back造成的性能損失。
檢測是否為 slow header 攻擊的demo,通過是否包含連續(xù)的兩個 rn 來進行判斷
int process_http_pkt(
struct FeatureExtractCoreConfig* config, uint32_t src_ip, uint16_t http_payload_len,uint8_t* http_payload){
uint8_t atk_type = -1;
char* find = strstr(http_payload, “rnrn”);
if(find == NULL){
atk_type = ATK_TYPE_HTTP_POST;
}else{
switch (http_payload[0]){
case ‘G’:
atk_type = ATK_TYPE_HTTP_GET;
break;
case ‘P’:
atk_type = ATK_TYPE_HTTP_POST;
break;
default:
break;
}
}
if(atk_type != -1){
update_feature(config->featureTableList[atk_type], src_ip, http_payload_len);
}
return 0;
}
開源的基于DPDK的 抗D工具:
https://github.com/AltraMayor/gatekeeper
在計算機網(wǎng)絡中,Hook鉤子在操作系統(tǒng)中用于在調(diào)用前或執(zhí)行過程中攔截網(wǎng)絡數(shù)據(jù)包。Linux內(nèi)核中暴露了多個鉤子,BPF程序可以連接到這些鉤子上,實現(xiàn)數(shù)據(jù)收集和自定義事件處理。XDP全稱為eXpress Data Path,是Linux內(nèi)核網(wǎng)絡棧的最底層。它只存在于RX路徑上,允許在網(wǎng)絡設備驅(qū)動內(nèi)部網(wǎng)絡堆棧中數(shù)據(jù)來源最早的地方進行數(shù)據(jù)包處理,在特定模式下可以在操作系統(tǒng)分配內(nèi)存(skb)之前就已經(jīng)完成處理。XDP暴露了一個可以加載BPF程序的網(wǎng)絡鉤子。在這個鉤子中,程序能夠?qū)魅氲臄?shù)據(jù)包進行任意修改和快速決策,避免了內(nèi)核內(nèi)部處理帶來的額外開銷?;赬DP實現(xiàn)高效的防DDoS攻擊,其本質(zhì)上就是實現(xiàn)盡可能早地實現(xiàn)「丟包」,而不去消耗系統(tǒng)資源創(chuàng)建完整的網(wǎng)絡棧鏈路,即「early drop」。
XDP暴露的鉤子具有特定的輸入上下文,它是單一輸入?yún)?shù)。它的類型為 struct xdp_md,在內(nèi)核頭文件bpf.h 中定義,具體字段如下所示:
*/
struct xdp_md {
__u32 data;
__u32 data_end;
__u32 data_meta;
/* Below access go through struct xdp_rxq_info */
__u32 ingress_ifindex; /* rxq->dev->ifindex */
__u32 rx_queue_index; /* rxq->queue_index */
};
程序執(zhí)行時,data和data_end字段分別是數(shù)據(jù)包開始和結(jié)束的指針,它們是用來獲取和解析傳來的數(shù)據(jù),第三個值是data_meta指針,初始階段它是一個空閑的內(nèi)存地址,供XDP程序與其他層交換數(shù)據(jù)包元數(shù)據(jù)時使用。最后兩個字段分別是接收數(shù)據(jù)包的接口和對應的RX隊列的索引。當訪問這兩個值時,BPF代碼會在內(nèi)核內(nèi)部重寫,以訪問實際持有這些值的內(nèi)核結(jié)構(gòu)struct xdp_rxq_info。
在處理完一個數(shù)據(jù)包后,XDP程序會返回一個動作(Action)作為輸出,它代表了程序退出后對數(shù)據(jù)包應該做什么樣的最終裁決,也是在內(nèi)核頭文件bpf.h 定義了以下5種動作類型:
enum xdp_action {
XDP_ABORTED = 0, // drop packet while raising an exception
XDP_DROP, // drop packet silently
XDP_PASS, // Allow further processing by the kernel stack
XDP_TX, // Transmit from the interface it came from
XDP_REDIRECT, // Transmit packet from another interface
};
可以看出這個動作的本質(zhì)是一個int值。前面4個動作是不需要參數(shù)的,最后一個動作需要額外指定一個NIC網(wǎng)絡設備名稱,作為轉(zhuǎn)發(fā)這個數(shù)據(jù)包的目的地。
啟用XDP后,網(wǎng)絡包傳輸路徑是這樣的:
可以看到多了3個紅色方框圈起來的新鏈路,我們來一一介紹:
offload模式,XDP程序直接hook到可編程網(wǎng)卡硬件設備上,與其他兩種模式相比,它的處理性能最強;由于處于數(shù)據(jù)鏈路的最前端,過濾效率也是最高的。如果需要使用這種模式,需要在加載程序時明確聲明。目前支持這種模式的網(wǎng)卡設備不多,有一家叫netronome。
native模式,XDP程序hook到網(wǎng)絡設備的驅(qū)動上,它是XDP最原始的模式,因為還是先于操作系統(tǒng)進行數(shù)據(jù)處理,它的執(zhí)行性能還是很高的,當然你的網(wǎng)絡驅(qū)動需要支持,目前已知的有i40e, nfp, mlx系列和ixgbe系列。
generic模式,這是操作系統(tǒng)內(nèi)核提供的通用 XDP兼容模式,它可以在沒有硬件或驅(qū)動程序支持的主機上執(zhí)行XDP程序。在這種模式下,XDP的執(zhí)行是由操作系統(tǒng)本身來完成的,以模擬native模式執(zhí)行。好處是,只要內(nèi)核夠高,人人都能玩XDP;缺點是由于是仿真執(zhí)行,需要分配額外的套接字緩沖區(qū)(SKB),導致處理性能下降,跟native模式在10倍左右的差距。
當前主流內(nèi)核版本的Linux系統(tǒng)在加載XDP BPF程序時,會自動在native和generic這兩種模式選擇,完成加載后,可以使用ip命令行工具來查看選擇的模式。
struct bpf_map_def SEC(“maps”) c_map = {
.type = BPF_MAP_TYP_PERCPU_ARRAY,
.key_size = sizeof(int),
.value_size = sizeof(long),
.max_entries = 256,
};
void sample_packet(void *data, void *data_end) {
// mark the packet to be sampled
}
static inline void update_rule_counters(int rule_id) {
long *value =
bpf_map_lookup_elem(&c_map, &rule_id);
if (value)
*value += 1;
}
static inline int rule_1(void *data, void *data_end) {
// if any of the rule conditions is not met
// return XDP_PASS;
update_rule_counters(1);
sample_packet(data, data_end);
return XDP_DROP;
}
// static inline int rule_2(..)
SEC(“xdp1”)
int xdp_prog(struct xdp_md *ctx) {
void *data = (void *)(long)ctx->data;
void *data_end = (void *)(long)ctx->data_end;
int ret;
ret = rule_1(data, data_end);
if (ret != XDP_PASS)
return ret;
ret = rule_2(data, data_end);
if (ret != XDP_PASS)
return ret;
//..
return XDP_PASS;
}
XDP的程序在這里的主要作用是完成early drop ,而不是識別,相當于執(zhí)行者,通過我們的分析工具下發(fā)攔截指令,并實施攔截。大體的玩法就是:
1, 自研的模塊負責識別DDOS攻擊包
2, 自研的規(guī)則下發(fā)攔截規(guī)則,完成告警并記錄
3, XDP負責阻止黑名單里的IP繼續(xù)訪問
DDOS大體介紹了一遍,了解即可,上面都是臟活累活即可,交給專門做防DDoS的廠商去做,一般都直接使用CDN和高防即可,比如,知道創(chuàng)宇的加速樂,騰訊云的大禹等等。
以上就是本站網(wǎng)?DDoS是什么意思(DDoS介紹與防御方法)的相關(guān)內(nèi)容了,更多精彩請關(guān)注本站號公眾號。
聲明:本文由貓小編【創(chuàng)業(yè)者資源平臺】作者編輯發(fā)布,更多技術(shù)關(guān)注貓小編技術(shù)!