作者：知乎用戶
鏈接：https://www.zhihu.com/question/31213254/answer/137153019
來源：知乎
1.檢測低交互蜜罐：
（1）配置失真與資源搶奪
我們已經知道低交互蜜罐是不能夠給敵人提供一個完整的操作系統環境，所以可以通過使用一些復雜的命令和操作，以及一些想不到的輸出解決來檢查是不是處在蜜罐環境中。另外一種情況就是出現了配置失真，也就是說在一台機器上出現了兩種不同平台的服務，舉個例子：運行一個Windows的Web服務器同時運行了一個Linux的FTP服務器，這樣的話就出現了配置失真。使用nmap -sV這個方法可以來觀察開啟的服務，如果發現了平台與服務不匹配的，說明這很有可能就是一個蜜罐。與低交互蜜罐檢測最主要的方式是通過網絡，這樣就意味着低交互蜜罐運行在一個具有正常操作系統的，只要是在操作系統中，不可能把所有的資源都分配給蜜罐，所以如果在蜜罐中執行一個很繁瑣很耗資源的操作，這樣蜜罐就會和其他服務進程去爭搶資源，最直觀的感受就是蜜罐的反應速度會慢下來。但是我們通常不具備這個權限來訪問這種類型的服務或者是進程，所以我們必須得考慮從網絡通信入手，增加蜜罐的操作負載，如果換一個角度想，可不可以讓其他的服務去和蜜罐爭搶資源，來拖慢蜜罐的反應速度，舉個例子比如說如果蜜罐系統和一個web服務器同時運行在一台機器上，我們可以從web服務器入手，去給web服務器發送大量http請求，導致web服務器搶占大量計算機資源用來處理請求。這樣就會讓蜜罐的反應慢下來。設計這樣一個實驗，假設我們有兩台機器，一台機器是蜜罐服務器（192.168.1.100），另一台機器是入侵者（192.168.1.200），首先我們需要使用nmap去探測蜜罐服務器開了那些服務，使用如下命令：sudo nmap -sV -p T:1-65535 -Pn 192.168.1.100等待一段時間之后會掃描到結果，假設其開啟了Apache2 Server、SSH兩個服務，我們可以編寫一個簡單的程序用來給Apache2 Server發HTTP數據包讓其大量處理：
# coding = utf-8
from scapy.all import *
from threading import Thread,activeCount
from random import randint
class Loop(Thread):
def __init__(self,remoteAddr):
Thread.__init__(self) self.remoteAddr = remoteAddr
def run(self):
ip = str(randint(0,255))+'.'\
+str(randint(0,255))+'.'\ +str(randint(0,255))+'.'\ +str(randint(0,255)) sr1(IP(src = ip,dst = self.remoteAddr)/TCP(dport = 80),retry = 0,verbose = 0,timeout = 3)class Main(Thread):
def __init__(self,remoteAddr):
Thread.__init__(self) self.remoteAddr = remoteAddr
def run(self):
limit = 140
total = 0
while True:
if activeCount() < limit:
Loop(remoteAddr = self.remoteAddr).start()
total = total + 1
print 'HTTP Flood Test:',total
if __name__ == '__main__':
remoteAddr = raw_input('IP=') Main(remoteAddr = remoteAddr).start()
我們利用scapy實現了一個簡單的http flood的工具，現在我們開始對蜜罐服務器的http服務發動攻擊python http_flood.py我們同時再去觀察蜜罐的響應速度，如果假設正確，此時蜜罐的響應速度應該會大幅度減慢。如果你使用HoneyD或者是LaBrea創建多個蜜罐來組建蜜網的話，只要增加其中一個蜜罐的負載，就可以影響其他蜜罐的運行速度。但是這么干的話，可能會被蜜罐所屬的服務器管理員發現，畢竟DDoS動靜很大。
（2）數據包時間戳分析
如果我們僅通過查看網絡數據包能很容易的推斷出一個機器的物理屬性，我們就很有可能辨別物理服務器和虛擬蜜罐。事實證明，TCP提供了一些直接反映底層服務器狀態的信息。TCP時間戳選項被網絡堆棧用於確定重傳超時時間。機器中的無歷史中安特定頻率更新時間戳，我們也知道，所有的物理時鍾都有一定時鍾偏差，他們或多或少於實際運行時間。通過打開一個到主機的TCP鏈接，並記錄為每個連接所提供的時間戳，就可以去觀察時間偏差。我們的希望是每個物理系統或者是操作系統顯示出來不同的偏差。如果說一個服務器上運行了多個蜜罐的話，就容易出現每一個蜜罐出現相同的時間偏差，這樣的話蜜罐就完全暴露了。這種基於對硬件檢測的思想也可以在一定程度上去實現檢測是不是蜜罐。
（3）分析低交互蜜罐產生的網絡響應來尋找差異
舉個例子，LaBrea試圖推遲入站TCP連接，這樣做是合法的，但很少用於TCP技術。任何使用Wireshark或者是tcpdump查看連接的人都可以立刻說出正在發生什么事情。如果說蜜罐系統試圖欺騙敵手，使他們相信是在和一個真的環境打交道的話，蜜罐系統在網絡行為中的任何差異都可以用來檢測它。
（4）環境不真實導致穿幫
來自Merit網絡公司的John Oberheide等人注意到，HoneyD重組IP數據包分片不正確，根據RFC791，通過匹配原地址、目的地址、標識號和協議號來識別對應的分片。不幸的是HoneyD沒有正確的實現匹配的步驟，在重組分片數據包時候忘記比較了協議號，出現問題的代碼如下：#define DIFF(a, b) do { if ((a)<(b)) return -1; if ((a)>(b)) return 1;}while(0)int fragcompare(sturct fragment *a, struct fragment *b){ DIFF(a->ip_src, b->ip_src); DIFF(a->ip_dst, b->ip_dst); DIFF(a->ip_id, b->ip_id); Return (0);}正如你所看到的，IP字段並沒作比較，這導致了honeyd把具有相同原地址、目的地址、標識號和協議號的不同協議分片進行了重組。在正常操作中其實這樣不會影響蜜罐功能，因為不太可能多個分片的四個字段只有這三個字段匹配。但是對於入侵者而言，如果是精心構造的數據包的話，honeyd可能會將這些數據包重組，而真實環境則可能會直接將數據包丟棄。John Oberheide也放出了這個利用工具：http://jon.oberheide.org/projects/winnie其實不僅僅是HoneyD，其他的蜜罐系統可能由於開發人員的疏忽或者是誤判等原因，使得不能夠完全的模擬真是環境所能得到的反饋，導致蜜罐的實際輸出和真是輸出存在着些許的不同，在設計蜜罐系統的時候一定要留意到操作系統和應用服務之前的一些彩蛋，攻擊者可能會利用這些彩蛋來完成對蜜罐系統的識別。
2.檢測高交互蜜罐
（1）檢測和禁用sebek：
（2）檢測蜜牆：
如果入侵者利用蜜網作為跳板攻擊第三方系統，大多數蜜網的管理員理當害怕承擔責任。因此，他們使用兩種常用的技術來最小化成功攻擊第三方系統的的風險：首先極其嚴格的限制出戰連接數，每天只允許15個出站TCP鏈接。不幸的是，這種控制出站流量的極端措施很容易檢測蜜罐的存在。對於這種特殊的限制策略，我們只需要初始化大量出站鏈接（到其他主機的SYN包），看一下什么時候這些連接被蜜牆阻止。最好的兼職策略就是不限制鏈接數量而是限制達到不同目標主機的上限，然而出站連接到大量不同主機的策略也容易被檢測出來。這樣的一個實驗結果可能並不總是很清晰，因為現在的一些ISP也是事了一些機制，采用類似的限制連接數的方法來遏制蠕蟲的傳播。部署Snort_inline是一種防止出站攻擊攻擊造成破壞的方式，snort_inline檢查出站流量中已知的漏洞利用代碼，並以某種方式破壞他們，使他們停止工作。蜜網管理員一般會使用一個類似肺功能字符串類似於/bln/sh來替換shellcode里面的/bin/sh，比如說下面的代碼：alert ip $HONEYPOT any->$EXTERNAL_NET any( msg: “SHELLCODE x86 stealth NOOP”; sid:651; content:”EB 02 EB 02 EB 02”; replace:”24 00 99 DE 6C 3E”;)入侵者通過構造一個包含匹配Snort_inline重寫數據庫規則字符串的通信流，並檢查接收到的所有數據包是否有改變，可以檢測蜜牆的存在。
（3）逃避蜜網記錄
我們應該去考慮降低日志的使用價值，攻擊者可以使記錄的數據無法理解，或者是日志記錄本身不可靠，或者采用一些方法式的攻擊行為根本不會被記錄。我們可以嘗試着攻擊日志主機，並從日志主機中擦除數據，但是通常不可行，如果我們加密所有的網絡通信，一個被動的或者外部的系統將不能從他獲得任何有異議的內容。這樣做的主要問題是對目標的初始漏洞利用通常是不可能加密的。有一個例外是https傳遞漏洞利用代碼。為了逃避基於主機系統的日志記錄，我們需要更詳細的了解一下sebek的工作原理：sebek能夠訪問內核sys_read函數處理的所有數據，當一個進程調用read的時候，sebek會記錄下他的PID，UID，文件描述符和前12個字符，以及被讀取的數據。例如被訪問文件的路徑和調用程序的路徑都沒有被記錄，這就意味着取證分析需要猜測誰正在讀取什么。這就允許我們向sebek日志中引入任意的干擾信息。比如說我們可以在/tmp中創建看上去正常的影子口令文件，並通過cat去讀取他。蜜網的管理員會認為我們在讀取真實的影子口令文件。當我們打算使用一些二進制文件用以決定哪個程序執行會更困難時，我們可以隨機的重命名這些文件，當我們不能直接控制我們的pid的時候，在終止父進程的時候我們就以頻繁的添加執行fork(), 以維持這個pid作為活動目標，降低日志價值的另一種方法是利用chaff命令，chaff命令沒有任何特定的目的，而是為了增加分析的復雜性，一個具有良好配置的日志系統能夠自動跟蹤我們的與會欺騙，然而，我們設法讓一個人來查看我們的chaff命令，取證分析效率會明顯降低。A.使日志不可靠：比如說在dd攻擊下，sebek的日志會變得非常不可靠。dd攻擊會提高網絡通信效率，使得需要儲存大量日志，從而造成網絡擁塞或者系統過載，以至於並非所有日志寶都能到達儲存系統，因為被丟棄的數據包數量變化較大，所以這種逃避日志記錄的方法不是很可靠。B.完全避免日志記錄：為了阻止sebek記錄被攻陷的蜜網上的活動，我們只要停止使用read()去調用就可以了，瀕危sebek所有獲得的數據來自於read()系統的調用，為了不通過read()系統調用一個文件的內容，我們可以使用mmap()函數，將文件直接映射到內存中，從而繞過日志記錄。不幸的是，設備文件和類似於/proc這樣特殊的文件系統不能以這種方式讀取。其實通過exec()執行程序也可以繞過read()，但是程序啟動的時候動態連接器將各種動態庫裝進內存中是通過mmap()實現的，但是也有可能是通過read()實現的，所以有一定概率還是能不過到入侵者的操作。
（4）檢測虛擬機
VMWare硬件虛擬化創建一個x86的硬件平台界面，允許安裝任何操作系統。我們可以利用虛擬化在同一個物理硬件上同時運行多個操作系統，除了更方便的資源管理，對於蜜罐操作者來說，主要是有點事虛擬機提供的隔離能力。還有一種方法就是提供低權限的用戶取運行客戶機操作系統，當客戶執行一個特權命令的時候，vmm接受到一個陷阱，並可以模擬期望的行為，不過其他特權狀態可能會駐留在客戶的內存里。可以把這部分內存變為寫保護。
虛擬機監視器需要提供的功能：保真度允許一個vmm運行任何軟件性能允許快速執行客戶機指令，也就是說幾乎沒有VMM的干預安全性要求VMM提供底層硬件資源的適當隔離除了虛擬化不同的操作系統之外，vmware也會虛擬硬件層，但是虛擬的硬件層里面會帶有信息，所以可以使用以下命令去對信息進行判斷，比如說：sudo dd if=/dev/mem bs=64k skip=12 count=1| string -n10輸入這條命令后，虛擬機會和物理機得到不一樣的輸出：
可以通過輸入來判斷是否進入了虛擬機，但是虛擬機不能作為衡量蜜罐的一個標准，首先由於雲計算和虛擬化技術的發展，可能你進入到虛擬機恰好是真實的生產環境，所以確定虛擬機后很難確定是否為蜜罐環境。對於這一點，可以使用一個工具來修復這個問題：http://honeynet.rstack.org/tools/vmpatch.c，該工具除了可以額更改設備標示符之外，還提供以下的功能：禁用I/O后門：該工具定位EAX與幻數0x564D5868比對的代碼序列，采用一條NOP指令替換條件轉移，實現后門功能的代碼不再會被訪問到。改變MAC地址：VMWare為其虛擬網絡接口使用三種不同的MAC前綴，用這個工具可以修改改變顯卡BIOS，這個工具可以加載一個全新的適配器。虛擬機檢測方法總共有三類：邏輯差異：在真實和虛擬的接口中，邏輯差異是不同的，例如一些非虛擬化指令執行時是有差異的，例如SIDT、SGDT和SLDT，這些差異允許在用戶級檢查特權狀態。對於兼容性來說，不要求一致的模擬這些指令，所以這里的VMM不需要必須是透明的。另一個例子就是VMM模擬芯片組，VMWare總是模擬Intel i440bx芯片組，這可能會出現配置錯亂的情況，比如說Intel主板上跑AMD的CPU。資源差異：因為VMM需要共享跨越所有客戶及操作系統的物力資源，資源的可用性並不總是能得到保證或者被公平利用。舉個例子就是轉移后援緩沖區（TLB）的大小問題，VMM中的虛擬地址映射有客戶操作系統同時競爭首先資源，通過巧妙地修改頁表表項，確定頁表的尺寸是可能的，攻擊者檢測VMM的存在，首先執行不會引起任何VMM調用的尺寸測量算法，然后再穿插VMM調用並重新計算頁表大小，第二次測量也標尺寸的時候，會發現TLB看起來會小一些。計時差異：計時的差異不僅僅是由於虛擬化的開銷，這些可以通過在更快的硬件或者軟件上運行得以改善，當在VMM下運行時候，任何兩個操作的延遲總是有變化的，舉個例子來說就是：在物理硬件上的一個PCI寄存器可能花費100個周期去讀取數據，而當這個虛擬硬件寄存器在處理機的高速緩存中時，可能只需花費一個時許周期就能完成讀操作。由於高速緩存的特性，在VMM上的這種操作的變化大大高於在物理硬件上執行時所期望的變化對於QEMU的話，假設QEMU提供對所有CPU指令的正確仿真，而真正做到這一點的話其實不太可能。Symantec的安全研究員提出了一種檢測QEMU的技術：當運行在AMD CPU下的時候，CPUID指令不能反悔正確的值。首先檢查QEMU是否運行在AMD的系統上，如果是：使用EAX=80000000h泛會所支持的最高擴展函數。這個測試確保CPUID指令接收EAX=80000002H，用於提取處理機商標的字符串，在QEMU下面是QEMU Virtual CPU Version….而不是AMD Processor。
（5）檢測UML
UML(不是你們說的那個UML，這里的UML是User Mode Linux，用戶模式Linux，一張非常特殊的虛擬機)支持從自身內運行Linux內核，客戶機操作系統運行在主機內核之上，也就是在用戶空間之上，有點類似於上面VMWare那個圖。UML的本質是一個調整過的內核，特殊性在於能夠在用戶空間中運行。用UML當做蜜罐環境有些好處，但是UML還是盡量別用在蜜罐上面，默認情況下，UML在TT（不是奧迪TT，是Tracing Thread追蹤線程模式）模式下運行，一個主線程函數ptrace()追蹤客戶機操作系統中每一個啟動的新進程，在主機操作系統上，借助ps命令可以去查看：
可以看到主線程（PID 1039）和幾個被追蹤的線程：一些內核線程（PID 1044-1066）、init（PID 1068）、ile（PID 1268）和shell（PID 1272）、dd（PID 1348）。如果hostfs模塊可用，該模塊講一個主機操作系統目錄載入到UML的文件系統，從客戶機上能夠獲得一些類似的信息：uml# mount -t hostfs /dev/hda1 /mntuml# find /mnt/proc -name exe| xargs ls -l當使用默認值的時候，UML不會有意隱藏dmesg的顯示輸出。這樣的話可以通過這種手段來是被UML。使用TUN/TAP作為后端網絡設備是UML的另一個標識，另一種暴露是被稱為/dev/ubd*的偽IDE設備，UML使用這個偽造的IDE設備代替真是的硬盤，攻擊者可以通過查看/etc/fstab內容，或者執行mount命令就可以檢測到UML的存在，啟動帶有fake_ide和fakehd選項的UML時候可能會隱藏這些信息，但是還是會留下一些信息，比如說自盤設備的大數標示（0x62），這與IDE和SCSI不一樣。查看/proc也能識別UML，這個目錄中的大多數項目都顯示了UML的標示，文件/proc/cpuinfo包含了CPU和系統特殊信息，能讓我們確定這是一個在TT下的UML。除此之外還有iomen、filesystems、interrupts和許多其他文件看起來是可疑的，包含了很多UML的特征。我們為了讓識別UML的難度更大一些，可以使用命令hppfs定制化/proc層次結構中的內容，但是有點浪費時間。此外地址空間也是一個可以看一下的地方。文件/proc/self/maps包含當前內存映射區域和當前進程的訪問許可，相比之下在UML模式下看起來會有點不同，在客戶機OS下最高地址指示了堆棧的末端，這個和UML里面的有些不同。原因是UML講Linux內核映射到每一個進程的地址空間中，這個內核占據的空間是0x00000000-0xbefff000。這意味着每個進程都能對UML的內核進行訪問或者修改，一旦攻擊者進入了客戶機的OS里面並且是以root形式，他就能夠擺脫客戶機OS去攻擊宿主機。