speakerhom-jayhomdate20xx0513(編輯修改稿)
2024-11-29 17:09 本頁(yè)面
【文章內(nèi)容簡(jiǎn)介】 ntrollers Bot controller DNS query check 當(dāng) botmaster想檢查某 DNS server是否被劫持， IP是否被從新導(dǎo)向其他地方時(shí)： botmaster可透過(guò)某 bot不斷去查詢此 DNS的 IP 再對(duì)照其他 DNS IP list 既可得知此 server是否已經(jīng)被劫持。 2020/11/29 12 Bot controller mand channel check 上述 DNS查詢檢查是一種有效的方法來(lái)檢測(cè) DNS的定向，但如果偵測(cè)人員隱身監(jiān)測(cè)，實(shí)際捕捉和監(jiān)控在這種情況下， DNS查詢檢查將為無(wú)效。 要偵測(cè)此類(lèi)型的方法可利用先前所介紹的方式來(lái)測(cè)試，既是用指令去測(cè)試此 bot controller是否被監(jiān)控。 例如發(fā)動(dòng) 1000臺(tái) bot做 DDoS攻擊 (但目標(biāo)是錯(cuò)誤的 )此時(shí)受監(jiān)控的 controller必定不敢妄動(dòng)發(fā)送命令給 bot。 或進(jìn)行極少用到的指令 (既使指令為無(wú)害的 ) 2020/11/29 13 Discussions 因 honeypot的檢測(cè)程序使感染的電腦造成延遲但這並不影響 bot本身，因?yàn)榇蠖?bot將作為長(zhǎng)期的攻擊工具。 因此，它不是 botmasters重要的考慮問(wèn)題。 當(dāng)部署一個(gè)偵測(cè) honeypot的 sensor bot時(shí)通常只要求發(fā)送其一（如垃圾郵件，病毒代碼的副本）到 sensor以防止流量被發(fā)現(xiàn)或阻塞。 當(dāng)連續(xù)使用的 DNS查詢，以測(cè)試 controller是否被劫持，這些 DNS查詢請(qǐng)求可能被判定為異常的 DNS查詢行為。所以為防止這類(lèi)事件： （ 1）減慢查詢的次數(shù)。（ 2）使用多個(gè) sensor進(jìn)行查詢。 （ 3）發(fā)送 DNS查詢到許多網(wǎng)路上的 DNS server。 2020/11/29 14 Experiment work system introduction 使用標(biāo)準(zhǔn)的 GenII honey： 實(shí)驗(yàn)封閉對(duì)外連線，且模仿 bot感染途徑，非使用真的 bot 2020/11/29 15 IP Tables + Snort_inline Honeypot detection—IPTables IPTables on the honeywall log： 2020/11/29 16 Honeypot被感染 開(kāi)始 對(duì)外連線 bot controller 通信狀態(tài) TCP 6 已達(dá) IPTable門(mén)檻 Honeypot detection—Snort inline Snort_inline是用來(lái)偵測(cè)對(duì)外流量，及制定規(guī)則 使用 Code Red II 並將
教學(xué)課件相關(guān)推薦
鄂ICP備17016276號(hào)-1