dns緩存污染(存儲版)
【正文】 Check為了對付1997年出現(xiàn)的Classic Glue Poison，DNS實現(xiàn)進行了所謂的Bailywick Check。來自Auth Server的正常響應報文很可能先于攻擊者偽造的響應報文到達Cache Server，這種情況下Cache Server只會接受先到達的正常響應報文，后續(xù)到達的偽造的響應報文無論其Transaction ID、源PORT是否正確都不被接受。這個問題是DNS協(xié)議設計者最初沒有想到的，由于設計上的缺陷以及多年應用帶來的積重難返，在相當長的一段時間內(nèi)這個問題都將始終存在并嚴重威脅著Internet。2008年針對這種攻擊出了一批分析文檔，絕大多數(shù)都只盯著源端口靜態(tài)的問題，認為Dan Kaminsky又在純炒冷飯，現(xiàn)在看來這種攻擊還是有可取之處的，只不過Dan Kaminsky這個人太愛作秀以致招人嫌了。如果攻擊未得手，攻擊者接著向Cache ，如此不斷嘗試直至攻擊成功。 Classic Glue Poison1997年出現(xiàn)了最早的關于DNS欺騙的安全公告，針對下述攻擊:，響應報文給了正常的A RR，但在Additional Section中附帶完全不相干的兩個RR，這兩個RR隨Answer Section中的A RR一起進入Cache Server的緩存。*k^，k等于365時，前述結果約等于23。某些商用DNS實現(xiàn)，其請求報文的源端口范圍太小，應該盡可能地擴大源端口取值范圍。絕大多數(shù)DNS Server會在啟動時隨機選取一個源PORT，以后向外發(fā)送請求時始終使用這個源PORT。后來Transaction ID字段開始隨機化，攻擊者只能窮舉猜測ID值。攻擊者一般主動向Cache Server提交A RR查詢請求，然后偽造Auth Server到Cache Server的A RR響應報文。 Server， RR。任何個人、機構未經(jīng)綠盟科技的書面授權許可，不得以任何方式復制或引用本文的任何片斷。但在現(xiàn)實世界中幾乎所有的DNS Server都支持遞歸查詢模式，同時幾乎所有的DNS Client都默認使用遞歸查詢模式。 DNS緩存污染攻擊所受限制一般都是通過偽造DNS響應報文進行DNS緩存污染攻擊。Cache Server一般向Auth Server的53/UDP發(fā)送查詢請求，假設這個請求報文的源端口是0x5121，Auth Server生成的響應報文其目標端口必然是0x5121/UDP。與此同時，攻擊者向Cache Server發(fā)送大量偽造的響應報文，其中包含偽造的A RR()，響應報文的源端口、目標端口都等于53/UDP。 Server， Server程序或者動用sniffer工具抓包。 NAT對源端口隨機化的干撓如果DNS Server位于NAT背后，NAT會干撓到由DNS Server發(fā)出的請求報文的源端口，很可能DNS Server自己隨機化了源端口，但NAT減弱了其隨機化程度。同時發(fā)送更多的響應報文，Transaction ID、源PORT一起命中的概率就更大。
醫(yī)療健康相關推薦
鄂ICP備17016276號-1