觀察上一節內容中簡單的攻擊手段其中的截圖和代碼，問題發生在（2）建立L2CAP層的鏈接處，考慮藍牙鏈路的建立可以視作是標準的“三次握手”，我們發現它是發送大量僞造的連接請求，使被攻擊方資源耗盡(CPU滿負荷或內存不足)的攻擊方式。服務器端將爲了維護一個非常大的半連接列表而消耗非常多的資源。即使是簡單的保存並遍歷也會消耗非常多的CPU時間和內存。
有鑑於此，我思考了一下：
1.每一藍牙設備都有一個全球唯一的遵循IEEE802標準的48位地址，人們常用藍牙設備地址來標識藍牙設備。由於藍牙設備地址的唯一性，如果一個特定的藍牙設備屬於一個特定的人，那麼這個人的習性和活動就會和該設備地址有很高的關聯性。而藍牙設備地址又是公開的，人們可以通過人機接(ManMachineInterface,MMI)的交互取得,也可以通過藍牙的查詢規則自動獲得。當藍牙設備和另一個藍牙設備進行通信時，人們很容易發現這個藍牙設備地址。如果跟蹤和監視這個設備地址，比如在什麼時間什麼地方出現，就會使該設備的所有者的隱私權處於易受攻擊的地位。
那麼可以考慮用週期性地改變藍牙設備地址來抵制跟蹤問題，但是藍牙設備地址又不能隨便更改，要保持藍牙地址的唯一性，至少應該是局部唯一性，這樣可以防止在一個散射網或匹克網裏出現兩個地址相同的藍牙設備導致混亂。可以指定一些機構專門從事藍牙地址的管理工作，就象管理因特網的域名一樣。需要更改藍牙地址的用戶到指定機構處申請，管理機構從可用的藍牙設備地址庫中隨機選出個一藍牙設備地址分配給申請者，同時收回申請者的原藍牙設備地址。爲了充分利用藍牙設備地址可以把收回的藍牙設備地址放入可用藍牙地址庫以備下一次利用。
但顯然這是十分耗費精力的措施，而且藍牙的普及程度還十分低，恐怕沒有廠商或者別的組織會幹這現在看來尚不明朗的且沒有利益的事，但是更改藍牙設備地址也會給鑑權和加密帶來影響，因爲鑑權和加密都是基於藍牙設備地址。藍牙是對設備鑑權而不是對用戶鑑權，更改了藍牙地址就等於換了一臺新設備，以前與其他藍牙設備確立的關係已不存在，因此完全沒有必要。同時想到了物理地址的軟改寫是非常容易的，而藍牙傳輸採用時分雙工通信，在硬件設計和軟件設計過程中藍牙時鐘是可知的，完全可以根據時鐘按照特定個整數時隙軟改寫地址以提高對此類攻擊方法的安全性。
2.設想過純粹增加內存的方法，無異於飲鴆止渴。
3.根據藍牙協議棧的層次以及藍牙耳機語音傳輸建立的過程，考慮在HCI層做防護：（1）藍牙HCI提供了一個調用和訪問基帶控制器和鏈路控制器以及硬件狀態和控制寄存器的命令接口。這一接口提供了一個訪問藍牙基帶功能的統一方法。HCI由兩部分組成，實現命令接口的軟件和用來連接藍牙子系統和主機的物理硬件。HCI軟件的目的是使構成接口的硬件對系統高層軟件來說是屏蔽的。通過HCI可以方便地實現設備與藍牙模塊接口，從而無需深入研究複雜的藍牙協議細節就可以利用藍牙無線連接技術。HCI固件位於主機控制器。HCI固件通過對基帶命令、鏈接管理器命令、硬件狀態註冊器、控制註冊器和事件註冊器的訪問，實現藍牙硬件HCI指令。主機控制器意味着具有主機控制接口功能的藍牙器件。HCI驅動位於主機。若某事件發生，用HCI事件通知主機，而主機將收到HCI事件的異步通知。當主機發現有事件發生時，它將分析收到的事件包並決定何種事件發生。主機意味着具有主機控制器接口功能的軟件部件。可以在HCI指令分組和HCI時間分組的缺省參數中加入特定的生成進制數以區別。（2）考慮藍牙鏈路的建立可以視作是標準的“三次握手”，那麼我們考慮到SYN cookie防火牆的原理也是切實可行的：
1. L2CAP_req----------- - - - - - - - - - ->
2. <------------L2CAP_connection_res
3. ACK----------- - - - - - - - - - ->
4. - - - - - - - L2CAP_req --------------->
5. <- - - - - - - - - ------------ L2CAP_connection_res
6. - - - - - - -ACK--------------->
7. -----------> relay the ------->
<----------- connection <-------
1: L2CAP_req從AG發送到HS；
2：防火牆在這裏扮演了HS的角色來回應L2CAP_connection_res給AG；
3：C發送ACK包，接着防火牆和AG的連接就建立了；
4：防火牆這個時候扮演AG的角色發送一個L2CAP_req給HS；
5：HS返回L2CAP_connection_res給防火牆；
6：防火牆扮演AG發送一個ACK確認包給HS，這個時候防火牆和HS的連接也就建立了；
7：防火牆轉發AG和HS間的數據；
如果系統遭受攻擊，那麼第三步就不會有，而且無論在防火牆還是HS都不會收到相應在第一步的L2CAP_req，所以我們就擊退了這次攻擊。
關於藍牙攻擊與防護的內容在這裏暫時告一段落。
