強化Juniper SRX DDoS的安全防護–外網介面的ddos防護(screen)

-
強化Juniper SRX DDoS的安全防護 – 外網介面的ddos防護(screen)

關於ddos的防護，我們可以從幾個方面下手，網路設定方面，路由引擎保護方面，以及聯外介面的screen防護方面來討論。
本篇文章則是討論如何配置及使用篩選(Screens)的功能來偵測並攔截來自安全區介面上的拒絕服務(DoS)攻擊。



下面內容為小弟整理自本篇文章，提供給大家快速設定參考之用。

建議要配置的篩選(screens)選項：
下列為JUNIPER SRX設備的篩選測試命令選項：
set security screen ids-option untrust-screen alarm-without-drop 
此命令表示僅記錄攻擊資訊到日誌，但是不丟棄攻擊數據包。
由於每個單位的環境都不盡相同，為了怕影響到現有的使用環境，所以在運行中的設備上，建議在增加新的篩選命令時，先加入此命令測試觀察一段時間後，待無異常狀況之後再拿掉此命令。

下列為JUNIPER SRX設備出廠預設的篩選選項：
set security screen ids-option untrust-screen icmp ping-death
set security screen ids-option untrust-screen ip source-route-option
set security screen ids-option untrust-screen ip tear-drop
set security screen ids-option untrust-screen tcp syn-flood alarm-threshold 1024
set security screen ids-option untrust-screen tcp syn-flood attack-threshold 200
set security screen ids-option untrust-screen tcp syn-flood source-threshold 1024
set security screen ids-option untrust-screen tcp syn-flood destination-threshold 2048
set security screen ids-option untrust-screen tcp syn-flood timeout 20
set security screen ids-option untrust-screen tcp land

下列為整理自本篇文章內容，建議要添加的篩選設定：
set security screen ids-option untrust-screen ip bad-option
set security screen ids-option untrust-screen ip unknown-protocol
set security screen ids-option untrust-screen icmp fragment
set security screen ids-option untrust-screen icmp large
set security screen ids-option untrust-screen tcp fin-no-ack
set security screen ids-option untrust-screen tcp syn-fin
set security screen ids-option untrust-screen tcp tcp-no-flag
set security screen ids-option untrust-screen tcp winnuke
set security screen untrust-screen ip security-option spoofing
set security flow tcp-session sequence-check
set security flow tcp-session syn-check
set security flow tcp-session strict-syn-check
set security flow syn-flood-protection-mode syn-cookie

建議要配置但數值要斟酌的篩選選項：
set security screen ids-option untrust-screen icmp flood threshold 100
set security screen ids-option untrust-screen icmp ip-sweep threshold 3000
set security screen ids-option untrust-screen udp flood threshold 1000
set security screen ids-option untrust-screen udp udp-sweep threshold 1000
set security screen ids-option untrust-screen tcp port-scan threshold 5000
set security screen ids-option untrust-screen tcp tcp-sweep threshold 2000
set security screen ids-option untrust-screen limit-session source-ip-based 50
set security screen ids-option untrust-screen limit-session destination-ip-based 10000
set security flow aging high-watermark 80 low-watermark 60 early-ageout 3
set security flow tcp-session time-wait-state session-timeout 3
set security flow tcp-session tcp-initial-timeout 25

需要根據使用環境仔細斟酌的篩選選項：
set security screen ids-option untrust-screen ip timestamp-option
set security screen ids-option untrust-screen tcp syn-frag
set security screen ids-option untrust-screen tcp syn-ack-ack-proxy threshold 5
set security screen ids-option untrust-screen ip block-frag
set security flow syn-flood-protection-mode syn-cookie

root@srx100# set security flow tcp-session no-syn-check-in-tunnel
[edit]
root@srx100# commit
[edit security flow tcp-session]
  'strict-syn-check'
    strict-syn-check not allowed when no-syn-check or no-syn-check-in-tunnel is configured
Jun 26 08:00:57  srx100 mgd[1575]: UI_CONFIGURATION_ERROR: Process: mgd, path: [
edit security flow tcp-session], statement: strict-syn-check,
strict-syn-check not allowed when no-syn-check or no-syn-check-in-tunnel is configured
error: commit failed: (statements constraint check failed)
[edit]

root@srx100#

不建議配置過時或用不到的篩選選項：
set security screen ids-option untrust-screen ip record-route-option
set security screen ids-option untrust-screen ip loose-source-route-option
set security screen ids-option untrust-screen ip strict-source-route-option
set security screen ids-option untrust-screen ip security-option
set security screen ids-option untrust-screen ip stream-option

尚未說明的篩選選項：
set security screen ids-option untrust-screen ip ipv6-malformed-header
set security screen ids-option untrust-screen icmp icmpv6-malformed
set security screen ids-option untrust-screen ip ipv6-extension-header hop-by-hop-header jumbo-payload-option
set security screen ids-option untrust-screen ip ipv6-extension-header hop-by-hop-header router-alert-option
set security screen ids-option untrust-screen ip ipv6-extension-header hop-by-hop-header quick-start-option
set security screen ids-option untrust-screen ip ipv6-extension-header routing-header
set security screen ids-option untrust-screen ip ipv6-extension-header fragment-header
set security screen ids-option untrust-screen ip ipv6-extension-header no-next-header
set security screen ids-option untrust-screen ip ipv6-extension-header shim6-header
set security screen ids-option untrust-screen ip ipv6-extension-header mobility-header

root@srx100# set security screen ids-option untrust-screen ip ipv6-extension-header ?
Possible completions:
  AH-header            Enable ipv6 Authentication Header ids option
  ESP-header           Enable ipv6 Encapsulating Security Payload header ids option
  HIP-header           Enable ipv6 Host Identify Protocol header ids option
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> destination-header   Enable ipv6 destination option header ids option
  fragment-header      Enable ipv6 fragment header ids option
> hop-by-hop-header    Enable ipv6 hop by hop option header ids option
  mobility-header      Enable ipv6 mobility header ids option
  no-next-header       Enable ipv6 no next header ids option
  routing-header       Enable ipv6 routing header ids option
  shim6-header         Enable ipv6 shim header ids option
> user-defined-header-type  User-defined header type range
[edit]
root@srx100# set security screen ids-option untrust-screen ip ipv6-extension-header-limit ?
Possible completions:
  <ipv6-extension-header-limit>  Enable ipv6 extension header limit ids option
[edit]

root@srx100#

將篩選設定套用在安全區上，以啟動它：
set security zones security-zone untrust screen untrust-screen


確認您的配置：
在配置模式下，通過輸入show security screen 命令確認您的配置。如果輸出不顯示預期配置，
請按照本示例中的配置說明重複執行操作來更正。
[edit]
user@host# show security screen
ids-option untrust-screen {
    ip {
        record-route-option;
        timestamp-option;
        security-option;
        stream-option;
    }
}
[edit]
user@host# show security zones
zones {
    security-zone untrust {
        screen untrust-screen;
    }
}
如果設備配置完畢，請在配置模式中輸入 commit。


驗證安全區段中的篩選：
驗證在安全區段中啟用了篩選。
在操作模式下，輸入show security zones 命令。
[edit]
user@host> show security zones
Security zone: untrust
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Screen: untrust-screen
Interfaces bound: 1
Interfaces:
ge-1/0/0.0


驗證安全篩選配置：
顯示有關安全篩選的配置資訊。
在操作模式下，輸入show security screen ids-option screen-name 命令。
[edit]
user@host> show security screen ids-option untrust-screen
Screen object status:
Name                           Value
IP record route option         enabled
IP timestamp option                enabled
IP security option             enabled

IP stream option               enabled




在閱讀下面文章之前，請先閱讀下列的網路連結：
Juniper SRX (Junos OS)的網路安全保護工具




篩選和流量選項Screens and Flow Options
接下來才是我們這篇文章要介紹的重點。
篩選技術(Screen technology)是SRX的一部分，自NetScreen時代就已經出現，它是功能最強大，但卻被極度誤解的特性之一，這是因為篩選的許多設定都沒有被一般用戶正確的調整或理解。由於現代網路中存在所有先進的第7層(OSI七層網路模型)威脅，因此很容易忽略第3層和第4層威脅，儘管在過去的十年中互聯網威脅的主要來源已經轉移到第7層，但第3層和第4層的威脅仍然是相當有力的，特別是如果你沒有足夠的防禦措施的話。
部署篩選的重要性在現代網路中不能被誇大。大多數管理員可能會認為3級和4級攻擊是古老的歷史，但其中仍有許多是具有永久性效果的，現今的效果仍然跟它們初始的效果一樣 – 而現在我們對這些攻擊通常有更好的保護。篩選和流量選項是這個謎題中缺少的部分，在部署中經常被忽略。在接下來，我們會探討了它們的功能，還會討論它們如何防止工作，以及如何利用它們來保護您的終端系統和SRX本身。 有了這些資訊，您就可以確保您得到充分的保護以防止此類攻擊，因此您可以將精力集中在更具挑戰性的攻擊上，例如第7層(應用層)的攻擊。
而篩選究竟是什麼呢？篩選是第3層或第4層(OSI七層網路模型)的IPS設置，可用於檢測和阻止各種異常並為這些層的活動設置特定的閾值(threshold)。它們可以有效地阻止在現今仍然具有很高效率的第3層和第4層DoS攻擊。
我們一般將DoS攻擊(DoS attacks)分為兩大類：基於漏洞(exploit based) 和 基於洪水(flood based) 的攻擊。

基於漏洞的DoS
基於漏洞的DoS攻擊是利用特定軟件漏洞創建系統或服務中斷的攻擊。停機(Outage)可能導致服務在攻擊過程中變得完全不可用或不可用。通常，基於漏洞的攻擊不是高容量攻擊，而是由於漏洞(Vulnerability)導致系統以某種形式變得不穩定。重要的是要記住，並非所有的漏洞都會導致受害者系統受到攻擊者的控制;這一切都取決於漏洞的性質以及有關易受攻擊代碼的其他幾個因素，以確定是否可以實際危害系統。通常情況下，人們可能會發現一個漏洞無法受到攻擊者的控制，但仍然可能通過用隨機數據覆蓋某些內存並導致分段錯誤或其他不可預知的執行而使系統不穩定。我們認為類似這些攻擊都是屬於基於漏洞的DoS攻擊，因為它們攻擊了一個特定的漏洞。基於漏洞的攻擊並不是Screens的主要焦點，因為在IPS中對漏洞的防護會有更有效的覆蓋。

基於洪水的DoS
基於洪氾的DoS攻擊與基於漏洞的DoS攻擊幾乎在任何情況下都有很大不同。與利用受害者系統中的漏洞的基於漏洞的DoS攻擊不同，基於洪氾的DoS攻擊以大量合法流量壓倒受害者系統，讓受害者系統因速度異常而無法使用。有時攻擊的影響只會在攻擊進行時才會感受到，但其他許多攻擊會讓系統不堪重負，因而導致系統完全崩潰，這時往往需要透過人工幹預才能將系統重新啟動。事實上，許多安全和應用工程師可能會遇到這樣的攻擊事件（或像橋迴路(bridge loop)這樣的錯誤配置），不僅會使系統脫機，而且實際上還破壞了檔案系統或應用程式。
基於洪水的DoS攻擊可以有多種形式，我們將在本章中討論。一些常見的攻擊包括SYN洪水，UDP洪水，ICMP洪水和IP數據包洪水(SYN floods, UDP floods, ICMP floods, and IP packet floods)，這些服務將壓倒受害者系統。通常，如果沒有足夠的保護，終端系統(the end systems)不僅可能成為受害者，中間網路設備，尤其是第4層以上的中間網路設備也可能受到損害。
注意：技術上來說，這是一種洪水+漏洞DoS攻擊的混合體，它利用了比標準操作消耗更多CPU週期的漏洞，但本身並不會導致DoS情況。 相反，這種攻擊必須在多個會話中進行才能產生累積效應。這類攻擊的一些例子包括針對Apache的CVE-2011-3192和針對OpenSSL的CVE-2011-1473。


DoS與DDoS - DoS Versus DDoS
如果您對這類攻擊有點陌生，分類DoS（denial-of-service）和DDoS（distributed denial-of-service）攻擊是有幫助的。一般來說，拒絕服務攻擊（DoS Attack）並沒有具體說明來源的大小。分佈式拒絕服務攻擊（DDoS Attack）由大量來源（數百，數千甚至數百萬）進行協調。通常，這些攻擊是由通過殭屍網路(Botnet)控制攻擊主機的個人或組織發起的。這種攻擊產生的協同效果比單個駭客的攻擊要難得多，這種攻擊可以從來源IP位址的角度進行類似外科手術方面的改造來達成癱瘓目標網路的目的。就本章而言，DoS和DDoS可以相互交換使用，並且篩選對防止DDoS同樣有效，因為它們都是針對平臺的限制規則來阻擋DoS攻擊。
注意：
篩選功能主要用於第3層和第4層DoS / DDoS保護，但不對第7層提供DDoS保護。儘管篩選仍然是部署在基於L7的DDoS攻擊方面的關鍵技術，但要提供完整的覆蓋範圍篩選應該與第7層防DDoS技術結合使用。 2013年，瞻博網路收購了Webscreen Technologies及其基於設備/虛擬機的DDoS解決方案(appliance/VM-based DDoS solution)，這已被重新命名為Junos DDoS Secure，用來防止第7層DDoS攻擊。


篩選理論與範例
現在我們已經檢查了導致需要第3層和第4層DoS解決方案的一些威脅，讓我們深入瞭解威脅，技術和示例。在本節中，我們將探索Screen的幾個方面，因此將它們分解為每種類型攻擊的易消化區段都很有幫助。我們探討每種類型的攻擊以及Screen如何應用。
注意：
隨著IPv6在現代網路中的出現，這些相同的攻擊可以在IPv6和IPv4上執行是合乎邏輯的。好消息是，SRX通過篩選為IPv4和IPv6提供保護。但是只適用於IPv4的IP數據包篩選之中有一些例外，例如不適用於IPv6的安全選項(Security Option)和寬鬆/嚴格路由選項(Loose/Strict Route Options)。但在大多數情況下，當啟用IPv6處理時，篩選默認情況下會為IPv6提供類似的功能。


如何使篩選適合數據包流How Screens Fit into the Packet Flow
到目前為止，我們一般都在討論Screen的功能，但我們沒有解釋為什麼它們在保護防火牆本身的兩個端系統方面非常有效。篩選非常有效，因為它們重量輕，更重要的是，它們是盡可能早在流程鏈中進行處理(請參考圖2)。這意味著，在我們開始設置會話（session）或全面檢查協議狀態的數據包之前，我們就要套用篩選，以便盡可能在一開始的過程中就能丟棄問題數據包。請注意，無論會話是否建立，都始終應用基於數據包的篩選，而其他篩選僅在會話開始時應用。


圖1：篩選在SRX數據包流中發生的位置

從圖2中我們可以發現到， Juniper SRX的各種網路安全保護工具在數據包流中的處理順序：Firewall Filters (Stateless) → Screens (Stateless) → Policy (Stateful) → IPS and AppDOS (Stateful)
其中處理順序越優先的工具其設定越早被執行，我們同時也可以發現到，處理順序越優先的工具對系統資源的要求也越少，也就是說，如果一個安全防護設定在Firewall Filters與Firewall Policy皆能配置，那我們就要選擇將它配置在Firewall Filter之上，因為降低系統資源的消耗就等於是提高了系統的效能。


篩選處理只發生在入口介面(ingress interface)上
瞭解篩選只適用於當數據包到達SRX時，而不是在數據包流中的任何其他位置時才應用篩選是非常重要的。這是因為我們希望一旦抵達SRX就會拒絕進攻，而不是僅僅在稍後因為違規而丟棄數據包。重要的是要記住篩選只在入口處進行處理，因此當您考慮在哪裡啟用篩選時，它應該始終啟用在數據包將要到達的區域上。篩選並沒有從區域到區域的概念; 它們是在到達介面時按區域來進行處理的。
注意：
一般而言，SRX不支援將篩選應用於通道介面(tunnel interfaces)，而僅支援I​​FL介面（如ge-0/0 / 0.0）。但這可能會在將來發生變化，因此請檢查當前發行說明和當前狀態的文檔（the current release notes and documentation）。


硬體和軟件中的篩選
使篩選如此有效的另一個因素是，在高端SRX平臺(high-end SRX platforms)上，其中大部分都是在NPU(類似CPU的專門處理晶片)上以硬體完成的，因此平臺可以基本上以線速（line rate）處理篩選。所有基於數據包（packet-based）的篩選以及基於泛洪（flood-based）的篩選均在NPU中處理。 NPU中沒有完成的唯一篩選是那些需要在整個平臺上進行額外狀態追蹤的篩選。例如，IP會話限制，TCP/UDP掃描和埠掃描篩選必須在CP和SPU的組合中完成，因為並非所有數據包都流經單個NPU或SPU（除非該平臺是唯一的NPU或SPU）。 CP具有會話（session）的主列表，並且知道平臺上存在的會話，因此它可以有效地確定是否違反了限制。需要注意的是，即使在這種情況下，在執行初始數據包（initial packet）和基於泛洪的篩選以更好地保護平臺之後，這些篩選仍能正常運行。
在分支機構SRX(The branch SRX)設備上總是在中央處理器的軟件中處理篩選，但它們都是在數據平面（data plane）上完成的，而不是在控制平面（control plane）上完成的，所以在面對DoS攻擊時平臺應該仍然可用（特別是如果你正在使用fxp0進行帶外管理[out-of-band management]，而不是帶內收入介面[in-band revenue interface] ）。篩選對於分支機構SRX來說非常有效，但如果您真的關心大規模的DoS攻擊，那麼您應該真的考慮使用SRX高端平臺。
如前所述，所有篩選和其他數據處理都在數據平面上完成，而不是在控制平面上完成。這意味著，即使在平臺受到大規模攻擊時，該平臺仍會保持在可管理的狀態中。
注意：
最佳做法是不要在特定的故障排除情況下啟用流調試或數據包捕獲（flow debugs or packet captures），因為這些消息會發送到RE（routing-engine），因此如果您受到DoS攻擊，則可能會影響性能並導致可用性問題。


篩選配置檔 - Screen Profiles
在我們深入瞭解大量篩選和配置它們的各種選項之前，瞭解如何在SRX上應用和實施（apply and enforce）篩選非常重要。在SRX中，篩選基本上配置為在區域級（zone level）應用的配置檔;也就是說，篩選可以逐區域應用（apply），以使防火牆管理員能夠逐區域地定義不同的閾值(threshold)和限制。這是非常重要的，因為管理員通常希望在面向外部的區域（最可能出現DoS威脅的區域）上配置不同的限制，而不是可能對用戶進行更多的內部的控制。這並不是說您不應該在內部區域配置篩選，因為我們知道即使是組織的資源也會感染惡意軟件，這些惡意軟件可能會參與針對Internet的DoS攻擊或消耗不必要的資源。重點是您可以對不同區域應用不同的閾值，以補充連接到防火牆的每個區段的不同安全狀態。


數據包與閾值篩選
篩選可以分為兩種不同的類型：基於數據包(packet-based)的篩選和基於閾值(threshold-based)的篩選。基於數據包的篩選是以無狀態的形式(stateless fashion)逐個對數據包進行評估。例如，SYN-FIN篩選檢查每個數據包，看看TCP數據包是否同時設置了SYN和FIN位元，而這樣的數據包顯然是非法的。而這是在逐個檢查數據包的基礎上完成的，在不考慮其他因素的情況下。
另一方面，基於閾值的篩選以半狀態的形式（semistateful fashion）應用。 SRX必須在每個區域內（例如，每個源IP）在某個基礎上追蹤閾值(track the threshold)，並且一旦達到配置的閾值，就會採取行動。例如，SYN Flood篩選允許管理員定義可以從來源或目標發送多少個SYN數據包，凡是低於閾值的任何SYN數據包都將被傳遞，但一旦達到閾值，任何違反限制的數據包都將被丟棄。

將篩選配置檔應用於單個和多個區域
您可以將篩選配置檔(Screen Profiles)視為可應用於一個或多個區域的獨立配置檔。當一個區域由多個介面組成時，篩選將在區域級別進行追蹤，每個介面都會對可觸發的基於閾值的篩選(threshold-based Screens)做出貢獻。另一方面，當您有一個應用於多個區域的篩選配置檔時，每個區域將分別進行處理和追蹤，因此配置檔僅從配置角度方面來看是相同的。
注意：
請記住，當SRX配置應用於區域時，它們會共同影響成員介面，但它們與其他區域是分開個別追蹤的，就像任何其他基於區域(zone-based)的設置一樣。

配置篩選配置檔 - Configuring a Screen Profile
這個例子配置一個名為untrust-screen的篩選，並將其應用到Internet區域：
root@SRX100# set security screen ids-option SRX untrust-screen description "Screen Applied to the Internet Zone"
root@SRX100# set security zones security-zone Internet screen untrust-screen
[edit]
root@SRX100# show security screen
ids-option untrust-screen {
    description "Screen Applied to the Internet Zone";
}
[edit]
root@SRX100# show security zones
security-zone Internet {
    screen untrust-screen;

}

篩選配置檔只有一個選項（除了說明），這是一個警報但無需丟棄(alarm-without-drop)的選項。此設置意味著將為該事件觸發日誌或警報，但不會採取任何動作(Action)。 這是一個簡單的開關，可以根據每個篩選配置檔來強制打開和關閉篩選。在進行初始部署時用來確保您不會對網路造成任何負面影響的時候它會非常有用。
注意：
有時，在開始執行篩選之前，我們可以通過啟用篩選來進行簡短的試用，以確保不會網路有任何不利的影響。



在SRX系列設備上，篩選分為兩類：    
基於統計的篩選 (Statistics-based screens)
基於簽名的篩選 (Signature-based screens)

上面的敘述是Juniper原廠對篩選的分類，但是本篇在介紹順序方面，則是根據協議分類來分別介紹的，並且其中內容若有相關性的，則會將它擺在一起介紹，這點尚請大家見諒。

相關的內容請大家自行參考原廠網路連結：
Screens Options for Attack Detection and Prevention



使用IP協議的DoS攻擊 - DoS Attacks with IP Protocols
在本節中，我們將研究SRX可以抵禦的大量IP協議攻擊。雖然這些攻擊很多都是數據包異常，可能無法真正使任何現代操作系統崩潰，但仍然應該懷疑它們在網路上的存在。此外，雖然著名的現代操作系統通常不易受到數據包異常問題的影響，但手機，平板電腦和具有網路功能的外圍設備(network-capable peripheral devices)的巨大擴展(the great expansion)很可能會使其變得脆弱。在手機和平板電腦世界的情況下，許多操作系統都沒有能經受住時間的考驗;網路外圍設備特別運行非常簡潔的操作系統(very stripped-down OSs)，這些操作系統不太可能通過安全分析工具所進行的模糊或筆(fuzzed or pen)攻擊測試。


錯誤的IP選項篩選 - Bad IP Option Screen
IP 標準RFC 791（互聯網協定）指定了一組八個選項，用於提供特殊的路由控制、診斷工具和安全性(請參考-表1: IP 選項和屬性)。儘管這些選項的原來預期用途發揮了作用，但某些人已想出了歪曲這些選項的方法，以達到不可告人的目的。
或是故意或是偶然，攻擊者有時會不正確地配置IP 選項，產生不完整或殘缺的欄位。不管精心設計該資料包的人的目的是什麼，不正確的格式都是反常的，並且對預定接收者有著潛在的危害。錯誤地格式化數據包或發送不完整的數據包可能會對網路基礎設施和終端主機產生意想不到的後果。目睹這些類型的數據包崩潰服務甚至服務器本身並非聞所未聞。
當今的操作系統往往會阻止這種情況的發生，但最好的做法是在數據包進入網路並到達終端主機之前阻止這些數據包。
如果啟用了壞IP 選項保護篩選選項，那麼，當IP 資料包包頭中的任何IP 選項被錯誤格式化時，Junos OS 將阻止數據包。此外，Junos OS 還會在事件日誌中記錄該事件。

配置錯誤的IP選項篩選
set security screen ids-option untrust-screen ip bad-option




未知IP協議篩選 - Unknown IP Protocol Screen
在大多數情況下，現代網路中所使用的IPv4協議很少。您最熟悉的像是TCP（協議6），UDP（協議17）和ICMP（協議1），以及其他的例如ESP，AH，GRE，IPIP和其他一些協議。總共有256種潛在的IP協議（IP協議欄位是8位元長），儘管其中大多數是未使用或過時的。根據RFC 1700，ID 編號為137 以後(137-255)的協定類型是保留協定類型，目前尚未定義。正因為這些協議未定義，因此沒有辦法事先知道某一特定的未知協議是善意的還是惡意的。在大多數情況下，如果您在此類未知IP協議上看到一些流量，則可能是惡意行為，應該被阻止。與格式錯誤的數據包一樣，這些數據包永遠不會被視為進入網路的合法流量，因此最好使用Unknown IP Protocol Screen來阻止IP數據包。除非您的網路使用ID 編號為137-255之間的非標準協議，否則從謹慎的立場來看還是要阻止這類未知的元素進入受保護網路。
強大的未知IP協議篩選簡單而又有效。如果您有一個非常嚴格的安全性原則(security policy)，您可能不需要它，因為防火牆規則庫(FW rulebase)可以過濾這些過濾器，但是如果您有安全性原則在application部分使用Any作為規則時，則它會特別有用。

配置未知IP協議篩選
set security screen ids-option untrust-screen ip unknown-protocol




IP欺騙篩選­ - IP Spoofing Screen
嘗試獲得網路中受限區域的存取權限的一個方法是在資料包包頭中插入假源位址，使資料包看似發自可信任來源。這種技術稱為IP 欺騙。檢測IP欺騙的機制依賴于路由表條目。
很長時間以來，IP欺騙攻擊在路由世界中廣為人知和理解。本質上，攻擊者在將數據包發送到目的地時冒充受害者源地址，以便目的地相信數據包來自受害者而不是攻擊者。在無狀態訪問列表(stateless access lists)（特別是那些沒有精心製作的訪問列表）被這種技術繞過的狀態防火牆的日子之前，這些類型的攻擊更加有效。雖然這些技術對於有狀態的防火牆來說要困難得多，尤其是對於具有最小權限的精心製定的規則庫，但是當來源數據包落入規則的來源位址範圍之內時（特別是使用“any”來當做來源位址時），這些技術仍然是可能的。
IP欺騙篩選試圖防止攻擊者偽造其源IP地址。 SRX檢查包頭中的來源IP地址，然後將其與其路由表進行比較。如果它知道網段或主機存在於別處，則它確定它正在評估的IP數據包是偽造的。這就是基於單播反向路徑轉發（uRPF - Unicast Reverse Path Forwarding）的寬鬆檢查。
換句話說，如果一個將本地內部網路IP當作來源IP位址的數據包到達SRX的外部Internet介面時 - 例如來源位址為10.1.0.201而目的地址為172.31.100.60，如果SRX確定10.1.0.201存在於內部網路中，那麼就會判定它必定是欺騙攻擊。
再舉個例子，如果源IP位址為10.1.1.6 的資料包到達ge-0/0/1，但Junos OS 有一個通過ge-0/0/0 到10.1.1.0/24 的路由，則IP 欺騙檢查會發現這個地址到達的是路由表中定義的無效介面。來自10.1.1.6 的有效資料包只能通過ge-0/0/0 而不是ge-0/0/1 到達。因此，Junos OS 斷定該資料包含了欺騙性源IP位址並將其丟棄。
注意: 通過IP欺騙，Junos OS 可以檢測並丟棄IPv6 虛假資料包。

配置IP欺騙篩選
set security screen untrust-screen ip security-option spoofing





阻擋分段篩選 - Block Frag Screen
IP分段是當客戶端和服務器之間的鏈路(資料包通過不同的網路)的MTU(最大傳輸單元 - Maximum Transmission Unit)無法支持路徑某處的資料包大小時(資料包長度比對方的大)，從原始資料包中將資料包分成更小的片段（分段）。
攻擊者可能會利用IP 堆疊實現方案的資料包重組代碼中的漏洞，通過IP 分段進行攻擊。當受害系統收到這些資料包時，造成的後果小到無法正確處理資料包，大到使整個系統崩潰。
乙太網的MTU是1,514（包括Level 2標頭），這意味著IP數據包可以是1,500字節長。有時，當您進一步將數據包封裝在IPsec，GRE，PPPoE等必須仍然以相同鏈路MTU 1,514傳輸的協議中時，數據包可能不得不拆分。還有其他一些情況下可以使用完全合法的分段。
然而，在某些情況下，數據包分段可以用作攻擊技術，這是從DoS角度來看，也可以用於逃避(evading)第7層設備，這可能無法正確解析分段數據包，尤其是當它們出現亂序或重疊(out of order or overlap)時。數據包分段可能是完全可以接受的，但如果沒有理由說明數據包應該被分段，那麼可以使用此篩選在到達防火牆時完全阻止它們。
還要記住，分段(fragmentation)在IPv4路由器上受到支持;但是，IPv6路由器本身並不會執行任何分段。它會丟棄任何要傳送往上游/下游媒體(upstream/downstream media) 長度超過太大的數據包。相反，IPv6依靠路徑MTU ICMPv6消息來確保在數據路徑的其他地方不需要發生分段(fragmentation)。原因是因為路由器可能會對資料包進行分段（fragment）處理，在理想情況下這不應該是路由器的責任。但這並不意味著您需要在IPv6中啟用Block Frag Option，更重要的是要記住，防火牆將丟棄需要分段的IPv6數據包，而不管Block Frag Screen是否啟用。

分段通常用於通過將攻擊有效載荷分散到多個分段數據包中來規避攻擊預防和檢測 - 並且發送大量分段數據包可能會損害任何會話感知設備或終端節點(session-aware device or end node)，因為這些設備或終端節點必須重新組裝(reassemble)這些數據包來評估他們。 SRX能夠完全阻止分段化的IP數據包，以防止這些類型的攻擊。
您可以使用 set security screen ids-option untrusted-screen ip block-frag 命令來阻止所有分段的IP數據包。
但是由於我們的網路中會有IP分段存在，因此我們將禁用此篩選。
這是配置篩選時需要考慮到的事情的一個很好的例子，因為不是每個網路都應該使用它們。

配置阻擋分段篩選
配置阻擋分段篩選非常容易，因為它不需要額外的選項，只需啟用篩選配置檔即可。
set security screen ids-option untrust-screen ip block-frag

下面為配置阻擋分段篩選後會受到影響的篩選選項(後面會談論到):
配置SYN-Frag篩選 - SYN-Frag Screen
如果您已經使用Block IP Fragment篩選阻止IP片段，則其將取代此篩選。
set security screen ids-option untrust-screen tcp syn-frag
配置ICMP分段篩選 - ICMP Fragment Screen
注意：ICMP片段將被Block IP Fragment篩選取代(be superseded)。
set security screen ids-option untrust-screen icmp fragment
配置ICMP Ping到掛篩選 - ICMP Ping of Death Screen
如果啟用了Block IP Fragment Screen，它將取代此篩選。
set security screen ids-option untrust-screen icmp ping-death
配置IP撕裂攻擊篩選 - IP Tear Drop Screen
注意：如果啟用Block Frag Screen，則不需要此篩選，因為所有分段都將被阻止。
set security screen ids-option untrust-screen ip tear-drop


SYN-Frag篩選 - SYN-Frag Screen
使用TCP的另一種異常行為是將數據包分段得如此之小以至於無法完全查看TCP標頭。 特別是，這種技術可以用於SYN數據包，因為它會導致系統持有等待其他片段的資源，並可能準備建立新的連接。這可以用來攻擊防火牆的資源以及終端系統的資源。這種行為是高度可疑的，不應該在網路中被合法地看到，所以應該被阻止(blocked)。
配置SYN-Frag篩選
要配置SYN-Frag篩選，只需在篩選配置檔中啟用它。請記住，如果您已經使用Block IP Fragment篩選阻止IP片段，則其將取代此篩選。
set security screen ids-option untrust-screen tcp syn-frag


ICMP分段篩選 - ICMP Fragment Screen
互聯網控制訊息協定(ICMP - Internet Control Message Protocol) 提供了錯誤報告和網路偵查的功能。由於ICMP 資料包包含的資訊很短，因此沒有合法理由將ICMP 資料包分成片段。如果ICMP 資料包太大，必須分成片段，則可能有問題。除非確實需要支援大型ICMP數據包，否則此篩選適用於大多數情況。
如果啟用ICMP 分段保護篩選選項，Junos OS 將阻止設置了“More Fragments”（更多分段）標誌的任何ICMP 資料包，或者含有偏移欄位中指示的偏移值的任何ICMP 資料包。
注意：ICMP分段將被Block IP Fragment篩選取代(be superseded)，儘管啟用該功能並不會造成傷害。
配置ICMP分段篩選
ICMP 分段篩選非常易於配置，因為它可以針對每個配置檔(profile)啟用或禁用，並且不需要其他參數。
set security screen ids-option untrust-screen icmp fragment


ICMP Ping到掛篩選 - ICMP Ping of Death Screen
從20世紀90年代中期開始，ICMP Ping of Death攻擊是一種歷史悠久但非常強大的攻擊，它利用了分段和最大數據包大小65,536字節，這是IP所允許的。 通過發送這種數據包，它觸發了知名操作系統中的各種漏洞。這個bug早已在現代操作系統中得到修復，但這種行為非常可疑，應該被現代網路阻止。 請注意，如果啟用了Block IP Fragment Screen，它將取代此篩選。
配置ICMP Ping到掛篩選
set security screen ids-option untrust-screen icmp ping-death


IP撕裂攻擊篩選 - IP Tear Drop Screen
IP Tear Drop攻擊是一種非常令人討厭的技術，可以使遠程系統（包括路由器，防火牆等終端系統以及運輸系統）崩潰。本質上，這種攻擊趁IP分段時，在封包試圖重組裝時利用重疊分段（overlapping fragments）攻擊來造成混淆。大多數現代操作系統可以抵禦這種類型的攻擊，但是對於傳統系統或一些較新的外圍設備來說，它仍然可能存在問題。由於這是一種常見的逃避技術(common evasion technique)（以及DoS攻擊），因此沒有理由在網路中出現這種情況。它表明惡意活動在最壞的情況下，以及編碼非常差的IP堆棧(IP stack)，所以它應該始終被阻止。
注意：如果您啟用Block Frag Screen，則並不需要此篩選，因為所有的分段都將被阻止。SRX利用SPU中的片段處理引擎，確保片段在傳遞到終端系統之前完成並排序。當啟用IPS等級7服務時，或者啟用Force IP Reassemble flow選項時，SRX也將重新組裝(reassembly)。
配置IP撕裂攻擊篩選
set security screen ids-option untrust-screen ip tear-drop






下表中列出了IP 選項的用途及其伴隨的屬性。
表1: IP 選項和屬性
類型
類
編號
長度
預期用途
非法用途
選項結尾
0*
0
0
指示一個或多個IP 選項的結尾。
無
無選項
0
1
0
指示包頭中沒有IP 選項。
無
安全
IP Security
0
2
11位元
為主機提供一種手段，可發送相容“國防部”(DoD) 要求的安全性、TCC（非公開用戶組）參數以及“處理限制代碼”。
（此選項在RFC 791， 互聯網協定和RFC 1038， 修訂的IP 安全性選項中已被指定為廢棄選項。）
當前，此篩選選項僅適用於IPv4。
未知。但是，由於此選項已廢棄，當其在IP 包頭出現時則是可疑的。
鬆散源路由
Loose Source Route
0
3
變化
指定一個部分路由清單，供資料包在從源到目標的行程中選擇。資料包必須按照所指定的位址順序前進，但允許其通過所指定的位址之間的其他設備。
逃避。攻擊者可以使用所指定的路由來隱藏資料包的真實來源，或者獲得對受保護網路的存取權限。
記錄路由
Record route
0
7
變化
記錄沿IP 資料包前進路徑的網路設備IP 地址。然後目的機器可以提取和處理路由資訊。（由於選項和存儲空間的40 位元組大小限制，因此最多只能記錄9個IP 位址。）
當前，此篩選選項僅適用於IPv4。
偵查。如果目標主機是在攻擊者控制下的受害機器，攻擊者就能收集關於資料包所通過的網路拓撲和編址方案的資訊。
流ID
IP Stream
0
8
4位元
（已廢棄）此選項提供了一種方法，用於在不支援流概念的網路中輸送16 位元SATNET 流識別字。
當前，此篩選選項僅適用於IPv4。
未知。但是，由於此選項已廢棄，當其在IP 包頭出現時則是可疑的。
嚴格源路由
Strict Source Route
0
9
變化
指定完整路由清單，供資料包在從源到目標的行程中選擇。此列表中的最後一個位址將取代目標欄位中的位址。
當前，此篩選選項僅適用於IPv4。
逃避。攻擊者可以使用所指定的路由來隱藏資料包的真實來源，或者獲得對受保護網路的存取權限。
時戳
Timestamp
2**
4

在資料包從起始點到目的地的前進過程中，記錄每個網路設備接收到該資料包的時間（採用協調世界時[UTC]***）。
網路設備用IP 位址加以標識。
此選項建立沿資料包前進路徑的設備IP位址清單，並列出每個設備之間的傳輸持續時間。
當前，此篩選選項僅適用於IPv4。
偵查。如果目標主機是在攻擊者控制下的受害機器，攻擊者就能收集關於資料包所通過的網路拓撲和編址方案的資訊。
* 標識為0 的選項類的設計目的是提供額外的資料包或網路控制。
** 標識為2 的選項類的設計目的是用於診斷、調試和度量。
*** 時戳使用UTC 午夜過後的毫秒數。UTC 也稱為格林威治時間(GMT)，這是國際時間標準的基準。

用於檢測偵查所用IP 選項的篩選選項
下列篩選選項檢測攻擊者用於偵查或某些未知而可疑目的的IP 選項：
記錄路由—Junos OS 檢測IP 選項為7（記錄路由）的資料包，並在入口介面的篩選計數器列表中記錄事件。當前，此篩選選項僅適用於IPv4。
時戳—Junos OS 檢測IP 選項清單包含選項4（互聯網時戳）的資料包，並在入口介面的篩選計數器清單中記錄事件。當前，此篩選選項僅適用於IPv4。
安全—Junos OS 檢測IP 選項為2（安全）的資料包，並在入口介面的篩選計數器清單中記錄事件。當前，此篩選選項僅適用於IPv4。
流ID—Junos OS 檢測IP 選項為8（流ID）的資料包，並在入口介面的篩選計數器清單中記錄事件。當前，此篩選選項僅適用於IPv4。

如果收到了具有以前任何一個IP 選項的資料包，Junos OS 會將其標記為網路偵查攻擊，並記錄入口介面的事件。


IP安全選項篩選 - IP Security Option Screen
IP安全選項在很大程度上被棄用，並且可能永遠不會在任何現代網路上用於合法使用。 最初，它是由美國國防部開發的RFC（791,1038）。 它從來沒有真正實施，並被認為是過時的。最好阻止任何啟用此選項的數據包。
配置IP選項篩選
set security screen ids-option untrust-screen ip security-option


IP流選項篩選 - IP Stream Option Screen
IP流選項是用於將IPv4數據包鏈接到流（也稱為flow或session）的過時選項。 這個選項不常用，因此在現代網路中沒有太大的理由來使用它。包含它的數據包因此可能被丟棄，因為它們可能是惡意的。
配置IP流選項篩選
set security screen ids-option untrust-screen ip stream-option


IP時間戳選項篩選 - IP Timestamp Option Screen
IP時間戳選項是一個篩選，可用於識別在始發主機中發送數據包的時間。這不是固有的惡意行為，但是如果目標主機上存在與此選項相關的漏洞，則可能會造成DoS攻擊或更糟。 因此，如果不需要此選項，則最好遵循最小權限策略(strategy of least privilege)並將其禁用。
配置IP時間戳選項篩選
set security screen ids-option untrust-screen ip timestamp-option



IP路由選項篩選 - Route Option Screens
另一組IP選項篩選是IP路由選項系列的篩選。有四個路由選項篩選，您可以個別配置來阻擋：
IP記錄路徑選項- Record Route Option
此選項用於觸發路由器將其IP地址插入到IP選項欄位中，以通知沿此路徑的路由器的端點。這可以被攻擊者用於偵察目的。
set security screen ids-option untrust-screen ip record-route-option
IP鬆散源路由選項- Loose Source Route Option
源路由允許源定義數據包應該採取的路徑。鬆散的源路由意味著必須採取某些路由，但不一定是整個路徑。攻擊者可以使用它來定義數據包應該穿越網路的方式，可能會繞過段和傳輸設備。通常，攻擊者不應該控制路徑。源路由對於現代網路並不典型。
set security screen ids-option untrust-screen ip loose-source-route-option
IP嚴格的來源路線選擇- Strict Source Route Option
此路由選項定義數據包應通過網路到達端點的顯式路徑(explicit path)。像鬆散源路由選項一樣，在現代網路中並不常啟用這個選項。
set security screen ids-option untrust-screen ip strict-source-route-option
IP來源路由選項- Source Route Option
這取代了本質上為來源路由的任何路由選項，包括鬆散和嚴格的選項。
set security screen ids-option untrust-screen ip source-route-option


瞭解IP來源路由選項
源路由的設計目的是允許位元於IP 資料包傳輸來源的使用者指定沿著某一路徑的設備IP 位址（也稱為“跳躍”），使用者希望IP 資料包沿該路徑到達其目標位址。IP 源路由選項的初衷是提供路由控制工具，以協助進行診斷分析。例如，如果向特定目的地的資料包傳輸獲得不合常規的成功，您可以首先使用記錄路由或時戳IP 選項，來發現沿著該資料包所採取路徑的設備位址。然後，可以使用鬆散或嚴格源路由選項，按照從記錄路由或時戳選項產生的結果中所瞭解的位址，沿特定的路徑引導資訊流。通過更改設備位址以改變路徑，並沿不同的路徑發送幾個資料包，可以注意到成功率提高或降低的變化。通過分析和排除過程，也許能推斷出問題所在的位置。



儘管使用IP 源路由選項的最初意圖是良好的，但攻擊者已學會將其用於更多不正當的用途。他
們可以使用IP 源路由選項來隱藏真真實位址，並通過指定不同路徑來訪問網路的受限制區域。



Junos OS 僅允許來自2.2.2.0/24 並通過ethernet1（綁定到zone_external 的介面）的資訊流。設備3 和4 實施存取控制，但設備1 和2 不實施。而且，設備2 不檢查IP 欺騙。
攻擊者偽造源位址，並通過使用鬆散源路由選項將資料包通過設備2 導向2.2.2.0/24 網路，然後從該網路到設備1。設備1 將其轉發到設備3，後者又將其轉發到Juniper Networks 設備。
由於該資料包來自2.2.2.0/24 子網，並且含有來自該子網的源位址，因此該資料包看似有效。
但是，仍存在早先欺騙的一個痕跡：鬆散源路由選項。在此示例中，將為zone_external 啟用拒絕IP 源路由篩選選項。當資料包到達ethernet3 時，設備將丟棄資料包。
可以使設備阻止設置了鬆散或嚴格源路由選項的任何資料包，或者檢測這些資料包，然後在入口介面的計數器清單中記錄事件。篩選選項如下：
拒絕IP 源路由選項(ip source-route-option)—啟用此選項可封鎖使用鬆散或嚴格源路由選項的所有IP 資訊流。源路由選項可以允許攻擊者用假的IP 位址進入網路。
檢測IP 鬆散源路由選項—設備檢測IP 選項為3（鬆散源路由）的資料包，並在入口介面的篩選計數器清單中記錄事件。此選項指定一個部分路由清單，供資料包在從源到目標的行程中選擇。資料包必須按照所指定的位址順序前進，但允許其通過所指定的位址之間的其他設備。
檢測IP 嚴格源路由選項—設備檢測IP 選項為9（嚴格源路由）的資料包，並在入口介面的篩選計數器清單中記錄事件。此選項指定完整路由清單，供資料包在從源到目標的行程中選擇。此清單中的最後一個位址將取代目標欄位中的位址。當前，此篩選選項僅適用於IPv4。

通過源路由，位於IP 資料包傳輸來源的使用者可以指定沿著某一路徑的設備IP 位址（也稱為“跳躍”），使用者希望IP 資料包沿該路徑到達其目標位址。IP 源路由選項的初衷是提供路由控制工具，以協助進行診斷分析。
可以使設備阻止設置了鬆散或嚴格源路由選項的任何資料包，或者檢測這些資料包，然後在入口介面的計數器清單中記錄事件。


配置firewall filter的 ip-options 功能
我們也可以透過配置firewall filter的匹配選項的 ip-options 功能來達到跟篩選保護相同的效果。我們可以輸入下列的命令來查看ip-options支援了哪些功能?
root@srx210# set firewall filter block-recordroute term 1 from ip-options ?
Possible completions:
  <range>              Range of values
  [                    Open a set of values
  any                  Any IP option
  loose-source-route   Loose source route
  route-record         Route record
  router-alert         Router alert
  security             Security
  stream-id            Stream ID
  strict-source-route  Strict source route
  timestamp            Timestamp
[edit]

root@srx210#

set firewall filter block-recordroute term 1 from ip-options route-record
set firewall filter block-recordroute term 1 from ip-options loose-source-route
set firewall filter block-recordroute term 1 from ip-options strict-source-route
set firewall filter block-recordroute term 1 from ip-options security
set firewall filter block-recordroute term 1 from ip-options timestamp

您必須小心的使用非對稱路由(asymmetric routing)，因為它可能會導致欺騙篩選丟棄合法流量。您可以通過防火牆過濾器配置來自特定IP數據包的附加細粒保護(additional granular protections)。 一個簡單而快速的例子是配置阻止記錄路由IP選項(block the record route IP options)：
set firewall filter block-recordroute term 1 from ip-options record-route
set firewall filter block-recordroute term 1 then count
set firewall filter block-recordroute term 1 then discard
set firewall filter block-recordroute term 2 then accept
請記住，在將防火牆過濾器應用於介面之前，term 2 的 accept 是至關重要的。
set interface ge-0/0/0 unit 0 family inet filter input block-recordroute

另外firewall filter的匹配條件中也有阻擋分段（fragments）的指令is-fragment (Match if packet is a fragment)。關於阻擋分段的部分請先參考篩選相關設定的內容，以避免丟棄一些無害的封包。
set firewall family inet filter protect-re term block-frags from is-fragment
set firewall family inet filter protect-re term block-frags from protocol icmp
set firewall family inet filter protect-re term block-frags from protocol udp
set firewall family inet filter protect-re term block-frags from protocol tcp
set firewall family inet filter protect-re term block-frags then syslog
set firewall family inet filter protect-re term block-frags then discard
set firewall family inet filter protect-re term accept-all then accept






使用ICMP 進行DoS攻擊 - DoS Attacks with ICMP
ICMP是互聯網功能的基礎協議。它不僅具有檢查活躍性，通知主機網路參數和路徑的實用功能，而且還可用作攻擊者強大的偵察工具。在典型的網路中（特別是在互聯網邊緣(edge)），應該只有少數類型的ICMP消息(messages)可以合法接收。另外，這些消息的數量不應該過多。
ICMP消息也被用於隧道數據(tunnel data)，延續DoS攻擊，並為攻擊者收集有價值的診斷資訊，因此它們看起來並不像表面上那樣無害。網路肯定比ICMP有更嚴重的威脅，但ICMP異常行為肯定需要進一步調查，因為它可能是更嚴重的攻擊的一部分。

ICMP泛洪篩選 - ICMP Flood Screen
ICMP洪水攻擊可能是一種特別惡毒的攻擊，不僅會影響終端系統，還會影響路徑上的傳輸設備。由於需要發生一些複雜的邏輯，ICMP可能會或可能不會在ASICs中處理。此功能最初是在ScreenOS中引入的，因為必須在基於ASIC的ScreenOS平臺的CPU中處理ICMP消息。 Junos只需要處理發往ASIC中的包含防火牆本身IP位址的數據包（並且只有當防火牆正在偵聽該埠上的ICMP並且沒有配置為阻止它的訪問列表時）。儘管如此，ICMP功能強大，因為它通常被允許遍歷網路(traverse the network)，並且很容易被欺騙(spoofed)。
ICMP Flood Screen工作在一個非常簡單的前提下，即配置應該應用於ICMP篩選的閾值(threshold)，即在達到閾值之前，每秒接收到的目標服務器的每秒ICMP消息數量。請注意，雖然您不需要明確配置使用的IP位元址或服務器，但是可以針對該區域逐個服務器地追蹤這一點。
配置ICMP泛洪篩選
如前所述，對於ICMP泛洪篩選，您只需定義每秒鐘應該接收的每個目標服務器的ICMP數據包的最大數量（不論類型）。通常這個數字不應該太高，特別是如果它不是外部資源通常監控的服務器。在確定閾值時，應確定可用於正常日常操作的ICMP消息的基準數量，並將其設置為閾值。超過該限制的任何消息都將採取篩選配置檔的操作（僅限drop / log或log）。在這個例子中，我們使用每個主機每秒100個ICMP數據包的閾值(threshold)。
set security screen ids-option untrust-screen icmp flood threshold 100


ICMP IP掃描篩選 - ICMP IP Sweep Screen
雖然ICMP Flood Screen可以保護您免受針對使用ICMP的終端主機的基於卷的攻擊(volume-based attack)，但攻擊者仍然可以使用ICMP來映射網路(map a network)。在具有許多節能功能的設備的現代網路中，IP掃描可能具有破壞性，因為它們可以不必要地喚醒設備。 ICMP掃描篩選允許您設置在給定來源IP位址範圍內可以接收多少ICMP消息的閾值。由於此篩選必須跟蹤跨越會話和主機邊界的ICMP數據包，因此SPU / NPU不能全面查看每個平臺的所有主機，因此我們必須結合CP和SPU處理此數據包。
配置ICMP IP掃描篩選
ICMP IP掃描篩選只有一個參數，用於定義在每微秒（μs）閾值中定義的每個源位址可以接收多少個ICMP數據包。舉例來說，在這個例子中，我們將定義您不應該在篩選保護的任何主機上收到每3000微秒或3毫秒超過10個ICMP數據包。
set security screen ids-option untrust-screen icmp ip-sweep threshold 3000


ICMP大數據包篩選 - ICMP Large Packet Screen
互聯網控制訊息協定(ICMP - Internet Control Message Protocol) 提供了錯誤報告和網路偵查的功能。由於ICMP 資料包包含的資訊很短，因此沒有合法理由將ICMP 資料包分成片段。如果ICMP 資料包太大，必須分成片段，則可能有問題。
在正常情況下，ICMP數據包通常應該非常小，除了試圖解決某些鏈路大小相關的問題或使用ICMP確定MTU。 大型ICMP數據包的問題在於它們可用於DoS目的，但它們也可用於應用程式隧道(application tunneling)。除非特別需要允許大型ICMP數據包，否則它們可能會被拒絕。
例如，SRX 210 使用ICMP 作為傳送隱秘消息的通道。存在ICMP 大資料包可能會暴露用作SRX210 代理的受攻擊機器。它還可能指示某些其他類型的可疑活動。
如果啟用ICMP 大資料包保護篩選選項，Junos OS 將丟棄大於1024 位元組的ICMP 資料包。
此數值目前不可配置，因此如果您希望在此處獲得更多細微性(granularity)，則還可以使用無狀態防火牆過濾器(stateless firewall filters)。

配置ICMP大數據包篩選
set security screen ids-option untrust-screen icmp large


ICMP分段篩選 - ICMP Fragment Screen(前面已敘述)

ICMP Ping到掛篩選 - ICMP Ping of Death Screen (前面已敘述)




使用UDP進行DoS攻擊 - DoS Attacks with UDP
UDP是一種無連接傳輸協議(connectionless transport protocol)，用於輕量級網路功能，如DNS，NTP和多播，以及VoIP和視頻等即時(real-time)流量。雖然UDP的攻擊面比IP，ICMP和TCP小得多，但該協議仍可能發生DoS攻擊，您可以將其用於埠掃描。

UDP泛洪篩選 - UDP Flood Screen
與ICMP Flood篩選非常相似，UDP Flood篩選用於檢測何時將太多UDP數據包發送到配置區域中的目標。大量的UDP數據包可能會輕易壓倒目的地，並且因為UDP數據包不像TCP那樣面向連接，所以它們可能被欺騙並被淹沒而無需完全建立會話。
配置UDP Flood篩選
UDP Flood篩選只有一個參數，用於定義數據包應該丟棄的閾值(threshold)。請注意，這是目標閾值，因為源代碼可能被微不足道地欺騙。此限制是針對應用篩選的每個區域逐個主機進行追蹤的。在本例中，我們將閾值設置為每秒1000個UDP數據包到目的地。
set security screen ids-option untrust-screen udp flood threshold 1000


UDP掃描篩選 - UDP Sweep Screen
與IP掃描保護類似，UDP掃描篩選對於識別利用UDP的掃描嘗試來識別主機中的終端系統是否已啟動以及它們可能正在監聽哪些UDP服務很有用。
配置UDP掃描篩選
要配置UDP掃描篩選，您只需要定義每10個UDP數據包的時間（以微秒為單位）。在這個例子中，我們指定了1000微秒的閾值（例如，每10個數據包1毫秒）
set security screen ids-option untrust-screen udp udp-sweep threshold 1000




使用TCP進行DoS攻擊 - DoS Attacks with TCP
IP，ICMP和UDP都是潛在的DoS向量(vectors)，但TCP是當今大多數應用程式運行的Level 4協議，因此很可能是大多數攻擊者試圖利用的。面向連接(Being connection oriented)，支持各種選項(supporting various options)，以及嵌入在RFC中的奇怪行為，難怪TCP是流行的攻擊媒介。即使是現在，關於攻擊（主要是學術性質）的​​新研究仍然存在。我們將介紹SRX支援的各種篩選，以防止基於TCP的威脅。

FIN-No-ACK篩選 - FIN-No-ACK Screen
瞭解設置了FIN 標誌但未設置ACK 標誌的TCP 包頭
設定了FIN 控制標誌（以發送會話結束信號並中止連接）的TCP 片段。
通常，設置了FIN 標誌的TCP 片段也會設置ACK 標誌（以確認接收到前一個資料包）。由於設置了FIN 標誌但未設置ACK 標誌的TCP 包頭是異常的TCP 行為，因而對此沒有統一的回應。
有些作業系統可能會通過發送設置了RST 標誌的TCP 片段來做出回應。其他作業系統可能會完全忽略它。受害者的回應可能會向攻擊者提供有關其作業系統的線索。（發送設置了FIN 標誌的TCP 片段的其他目的包括：在執行位址和埠掃描時躲避檢測，以及通過執行FIN 氾濫攻擊來躲避對SYN 氾濫攻擊的防禦。）
注意: 供應商在設計其TCP/IP 實施時，對RFC 793， 傳輸控制協議做出了各種解讀。當設置了FIN 標誌而未設置ACK 標誌的TCP 片段到達時，有些實施方案會發送RST 片段，而其他方案則會丟棄資料包，不發送RST。

設置了FIN 標誌的TCP 片段也會設置ACK 標誌（以確認接收到前一個資料包）。由於設置了FIN 標誌但未設置ACK 標誌的TCP 包頭是異常的TCP 行為，因而對此沒有統一的回應。如果啟用fin-no-ack 篩選選項，Junos OS 將檢查TCP 包頭中是否設置了FIN 標誌而未設置ACK標誌。如果設備發現含這種包頭的資料包，就會丟棄該資料包。

配置FIN-No-ACK篩選
set security screen ids-option untrust-screen tcp fin-no-ack


LAND攻擊篩選 - LAND Attack Screen
20世紀90年代LAND攻擊是一個眾所周知的攻擊，影響了幾個舊的操作系統。它通過設置與源和目標相同的IP位址並使用帶有SYN的TCP數據包完成。這會導致溢出(overflow)，從而導致系統崩潰。當然，一個數據包不應該從一個網段的同一個IP位址發送或發送到同一個IP位址，所以這些類型的數據包本質上應該被認為是惡意的(malicious)。
配置LAND攻擊篩選
set security screen ids-option untrust-screen tcp land


TCP埠掃描篩選 - TCP Port Scan Screen
TCP埠掃描篩選用於檢測特定主機上的埠掃描。它與TCP掃描篩選不同，後者識別跨主機（水準掃描horizontal scan）發送的數據包與單個主機上的埠之間發送的數據包，以確定哪些服務可用（垂直掃描vertical scan）。 通常情況下，他們都應該共同利用來防止重新發起攻擊(recon attacks)。
配置TCP埠掃描篩選
TCP埠掃描篩選只有一個要配置的參數，這是在您考慮數據包違規之前，10個掃描數據包的計數之間的閾值（Threshold，以微秒為單位）。例如，在這個例子中，我們配置了一個5000微秒（5毫秒）的閾值，其中10個SYN掃描數據包可以發送到主機，然後才會考慮到那些會額外違反此篩選的SYN數據包。
set security screen ids-option untrust-screen tcp port-scan threshold 5000


SYN-ACK-ACK代理服務器篩選 - SYN-ACK-ACK Proxy Screen
SRX可充當認證會話(authentication sessions)的代理，例如用於使用Telnet/FTP/HTTP/HTTPS以及將來可能使用其他認證的用戶進行透明認證(transparent authentication)的代理。由於我們代表服務器對用戶進行了身份驗證（充當TCP代理），如果攻擊者在會話未完成的情況下大量打開開放的會話(open sessions)，則可能存在一個漏洞(vulnerability) 。 記住我們的三次握手，一旦洪氾設備(flooding bot)發送了SYN / ACK，攻擊就會繼續一遍又一遍地發送確認數據包，以試圖淹沒主機或連接表。 SYN-ACK-ACK代理篩選用於通過限制可以打開和未完成的未認證連接的數量來保護SRX免受此類攻擊。
配置SYN-ACK-ACK代理服務器篩選
要配置SYN-ACK-ACK代理服務器篩選，您只需定義源主機一次可以打開多少個半開放會話(half-open sessions)的閾值(threshold)。在此示例中，我們將配置五個限制，以限制源主機一次只能有五個半開放會話。
set security screen ids-option untrust-screen tcp syn-ack-ack-proxy threshold 5


SYN-FIN篩選 - SYN-FIN Screen
瞭解作業系統探查
在發起攻擊之前，攻擊者可能會嘗試探查目標主機，以瞭解其作業系統(OS)。利用該資訊，攻擊者能更好地決定發起哪種攻擊和利用哪些漏洞。
瞭解設置了SYN 和FIN 標誌的TCP 包頭
通常不會在同一TCP 片段包頭中同時設置SYN 和FIN 控制標誌。SYN 標誌同步化序號以發起TCP 連接。FIN 標誌表示完成TCP 連接的資料傳輸的結束。兩種標誌的用途是互相排斥的。
設置了SYN 和FIN 標誌的TCP 包頭會導致目標設備發出不同回應（具體取決於其運行的作業系統）。
攻擊者可以通過發送同時設置了兩個標誌的片段，來查看將返回何種系統應答，從而確定出接收端上的系統的種類。接著，攻擊者可以利用已知的系統漏洞來實施進一步的攻擊。
如果啟用此篩選選項，Junos OS 將檢查TCP 包頭中是否設置了SYN 和FIN 標誌。如果設備發現這樣的包頭，就會丟棄資料包。

配置SYN-FIN篩選
set security screen ids-option untrust-screen tcp syn-fin


SYN洪水/欺騙攻擊 - SYN flood/spoofing attacks
SYN洪水攻擊保護也許是SRX武庫中最先進的篩選保護。像juno.c（與Junos無關）這樣的SYN攻擊工具有很多例子，而且這種攻擊現在仍然存在，因為它非常有效，特別是在沒有基於硬體保護或未正確配置的平臺上。 SYN攻擊非常簡單，但防禦更複雜。作為該篩選的一部分，我們檢查了幾個不同的組件：
·         SYN洪水速率限制 - The SYN flood rate limiting
· 警報閾值 - Alarm thresholds
· 攻擊閾值 - Attack thresholds
· 欺騙保護 - Spoof protection (SYN Cookie / SYN Proxy)

簡單的SYN速率限制可以通過在SYN Flood篩選中配置源和目標SYN氾濫限制來完成。這就像UDP / ICMP Flood Screens一樣工作，通過速率限制源IP和目標IP基礎上的每秒SYN數據包數量。這有助於通過在數據路徑中儘早丟棄SYN來保護平臺免受大規模SYN氾濫。那麼為什麼我們還需要其他的東西？我們面臨的挑戰是，如果我們僅僅只是用篩選來限制，那我們也會將合法的流量丟棄。不過，我們應該為我們想要處理的源或目標設置SYN數據包的最大數量限制，以幫助保護平臺。

配置SYN洪氾速率限制
在這個例子中，我們設置一個主機可以發送的每秒100個源SYN的速率限制和一個目標可以接收的速率限制。請記住，SYN的源IP位址可能被欺騙，但TCP有一個機制來幫助保護我們免受此影響，我們將在下面探討。
set security screen ids-option untrust-screen tcp syn-flood source-threshold 100 destination-threshold 1000


SYN欺騙保護模式 - SYN Spoofing Protection Modes
正如我們所表明的那樣，SRX有兩個SYN欺騙功能，可以讓我們驗證SYN數據包沒有被欺騙。這與UDP/IP /ICMP不同，這就是為什麼我們不提供源閾值，因為這可能是微不足道的欺騙。通過TCP，我們可以選擇使用SYN Cookie和SYN Proxy來保護終端系統和SRX本身免受欺騙攻擊。
SYN Cookie通過代表服務器以SYN / ACK響應客戶端的初始SYN進行工作。 SRX將根據連接資訊元組的散列值以及僅為SRX平臺所知的偽隨機“魔術”數字來編碼序列號，而不僅僅是設置標準序列號。此時，如果SYN被欺騙，SRX將不會記錄任何連接狀態。相反，它會將SYN / ACK發送回客戶端。如果它被欺騙了，客戶端將丟棄SYN或發送重置，但不會處理數據包。如果客戶端是真實的，它將使用服務器提供的序列號來響應它的ACK。如果序號與預期不符，則SRX將不處理連接。從本質上講，這確保了客戶端是真實的並且沒有被欺騙（假設攻擊者不在相同的路徑中），因此主機不能進行大規模的欺騙性SYN氾濫，同時我們可以驗證客戶端是真實的。客戶端完成三次握手後，SRX將打開與目標服務器的連接。當然，由於SRX使用自定義序列號，因此需要雙向重寫序列號，以便此操作對客戶端和服務器都是透明的。
至於SYN Proxy，此功能還會以SYN / ACK響應客戶端的SYN，並在與服務器建立TCP連接之前等待客戶端完成握手。在握手完成之前它不會啟動連接。
這兩種技術的主要區別在於，SYN Cookie在其SYN / ACK中利用計算出的序列號，並且在三次握手完成之前不記錄任何狀態，而SYN Proxy不會使用特殊的TCP序列號和將保持初始TCP超時的狀態。除非您有特殊原因不使用SYN Cookie，否則建議您使用它來代替SYN Proxy，因為它在攻擊時體重更輕。
Junos OS支援IPv4和IPv6流量的SYN Flood保護。

SYN Cookie / SYN Proxy有三個組成部分，您應該注意：警報閾值(alarm threshold)，攻擊閾值(attack threshold)和超時(timeout)。它的功能如下：
1.    篩選傳入SYN數據包的速率低於警報閾值時，不會採取任何措施。一旦超過警報閾值，將生成一個日誌，指示已達到閾值，但不會採取任何措施。
2.    當SYN超過攻擊閾值時，SRX將從正常的TCP處理轉為基於您的配置實現SYN Cookie或SYN Proxy。
3.    SYN Cookie / SYN Proxy應用程式將繼續執行，直到SYN速率低於攻擊閾值加上您定義的超時時間。
4.    如果SYN數據包在任何時候超過SYN源或目標氾濫閾值（每個主機都追蹤），系統將丟棄這些數據包。這種方式獨立運作。
5.    或者，在Junos 12.1中，有一個用於SYN Flood篩選的白名單對象，如果您對個別服務器有特定需求，則可以免除主機進行SYN氾濫處理。

SYN flood防護篩選具有以下配置選項：
Attack Threshold（攻擊閾值）
這是每個預定義位址和埠號(port number)每秒的SYN數據包數量。一旦達到此數量，SRX將開始代理(proxying)到該目的地或埠的TCP連接嘗試。這個閾值(threshold)是在每個目的地(per-destination)和服務的基礎(perservice basis)上。
此選項允許您將啟動SYN代理機制所需的SYN數據包數(the number of SYN segments)（即設置了SYN標記的TCP數據包）設置為每秒相同的目標位址。儘管您可以將閾值設置為任意數字，但您需要知道站點的正常流量模式，以便為其設置適當的閾值。例如，如果它是一個電子商務網站，通常每秒可以獲得20,000個SYN數據包，則可能需要將閾值設置為每秒30,000次。如果一個較小的站點通常每秒獲得20個SYN數據包，則可以考慮將閾值設置為40。
set security screen ids-option untrust-screen tcp syn-flood attack-threshold 1500

Alarm threshold(警報閾值)
這是每秒發送一個警報到事件日誌的SYN數據包的數量。除了測試攻擊閾值之外，這對通知(notifications)和警報(alarms)很有用。
此選項允許您設置每秒的代理半完成TCP連接請求數，此後Junos OS會在事件日誌中輸入警報。當為每秒相同目標位址的代理，半完成連接請求數超過該值時，為警報閾值設置的值會觸發警報。例如，如果將SYN攻擊閾值設置為每秒1500個SYN數據包，並將警報設置為1000，則需要每秒向同一目標位址創建3000個SYN數據包才能觸發日誌中的警報條目。
對於每個SYN數據包到相同的目標位址超過告警閾值，攻擊檢測模塊會生成一條消息。在第二秒結束時，日誌記錄模塊將所有類似的消息壓縮到單個日誌條目中，該日誌條目指示在超過警報閾值之後到達相同目的地位址和埠號的SYN數據包的數目。如果攻擊持續超過第一秒，則事件日誌每秒鐘發出一次警報，直到攻擊停止。
set security screen ids-option untrust-screen tcp syn-flood alarm-threshold 1000

Source threshold(源閾值)
這是每個IP位址的SYN數據包數量，可以是任何目標IP位址或埠號(port number)。源閾值會阻止任何高於閾值的SYN數據包，而不像攻擊閾值一樣只是代理服務而已。
通過此選項，您可以指定從單個源IP位址每秒接收到的SYN數據包數(無論目標IP地址為何)，在Junos OS開始刪除來自該源的連接請求之前。
通過源位址追蹤SYN泛洪使用不同的檢測參數來追蹤目的地址的SYN泛洪。
設置SYN攻擊閾值和源閾值時，將基本SYN Flood防護機制和基於源的SYN Flood攻擊機制都設置為有效。
設置來源閾值時，無論目標地址如何，設備都會追蹤SYN數據包的來源IP地址。（請注意，此基於來源的追蹤與基於目標位址的SYN數據包的追蹤不同，它構成了基本的SYN氾濫保護機制。）
當您將來源閾值設置為25，攻擊閾值設置為625，並進行監控觀察，在監控活動的一周內，您觀察到，在一秒鐘間隔內，不超過1/25的來自任何一個源的所有服務器的新連接請求。
因此，超過此閾值的連接請求是不尋常的，並為設備執行其代理機制提供了充分的原因。（請注意，25 pps是攻擊閾值的1/25，即625 pps。）
如果設備追蹤來自同一源IP位址的25個SYN數據包，則從第26個數據包開始，它將在該秒的剩餘時間內和下一秒中拒絕來自該數據源的所有進一步的SYN數據包。

set security screen ids-option untrust-screen tcp syn-flood source-threshold 100

Destination threshold(目的地閾值)
    這是每個目標IP位址的SYN數據包數量，它可以來自任何源IP位址或埠號。目標閾值與源閾值一樣運行;它會阻止任何高於閾值的SYN數據包，而不像攻擊閾值一樣只是代理服務而已。
    此選項允許您指定在Junos OS開始將連接請求丟棄到該目標之前，單個目標IP位址每秒接收到的SYN數據包的數量。如果受保護的主機運行多個服務，則可能只需根據目標IP位址設置閾值 - 不管目標埠號如何。
    設置SYN攻擊閾值和目標閾值時，將基本SYN Flood防護機制和基於目標的SYN Flood防護機制都設置為有效。
設置目標閾值時，無論目標埠號如何，設備都會單獨追蹤目標IP地址。
    考慮Junos OS具有允許FTP請求和HTTP請求到相同IP位址的策略的情況。如果SYN泛洪攻擊閾值為每秒1000個數據包（pps），並且攻擊者發送999個FTP數據包和999個HTTP pps，則Junos OS會將具有相同目標位址的FTP和HTTP數據包視為單個成員，並拒絕第1001個數據包-FTP或HTTP-到目的地。
set security screen ids-option untrust-screen tcp syn-flood destination-threshold 1000

Timeout(超時)
此選項允許您設置從隊列中刪除半完成連接之前的最長時間。默認值是20秒，您可以設置1-50秒的超時時間。您可以嘗試將超時值減小到更短的長度，直到您在正常流量狀況期間看到任何丟失的連接。對於三次握手ACK響應，二十秒是非常保守的超時。
超時值是初始會話（未創建三方握手的會話）在會話表中的時間量。如果存在會話表有填滿的風險，可以更積極地設置此值(降低秒數)。
set security screen ids-option untrust-screen tcp syn-flood timeout 20


SYN Cookies
SRX可以提供的下一層安全性稱為SYN cookie保護。 SYN cookie保護是一種無狀態的SYN代理，您可以用來防禦來自欺騙源IP位址的SYN洪水。如果源IP地址是合法的並且回復SYN/ACK數據包，則SYN cookie不會增加太多價值。
由於它是無狀態的，因此SYN cookie非常高效。 收到SYN數據包後不執行路由查找或策略查找。
當啟用SYN cookie時，SRX代理目標的所有TCP協商。
SRX通過加密的MD5 hash（Message-Digest algorithm 5 hash）回覆所有傳入的SYN數據包，其中包含特殊標記的SYN/ACK數據包，其中包含原始源位址和目的地址以及埠號。
要配置SYN Cookie保護，請將以下配置添加到SRX中：
set security flow syn-flood-protection-mode syn-cookie



配置SYN Cookie/Proxy保護
除了在前面的示例中為SYN Floods配置的保護之外，還可以向您的篩選添加SYN Cookie保護，並且報警閾值為每秒1,000 SYNs，攻擊閾值為1,500 SYNs /秒，攻擊後30秒超時 已經平息。
由於基於網頁的前端服務器(the web-based frontend servers)和網路上出現的大流量負載，因此這些值被設置得非常高。如前所述，您需要仔細設計這些配置以滿足您自己的特定網路和要求(particular network and requirements)。
set security screen ids-option untrust-screen tcp syn-flood alarm-threshold 1000
set security screen ids-option untrust-screen tcp syn-flood attack-threshold 1500
set security screen ids-option untrust-screen tcp syn-flood source-threshold 100
set security screen ids-option untrust-screen tcp syn-flood destination-threshold 1000
set security screen ids-option untrust-screen tcp syn-flood timeout 30
set security flow syn-flood-protection-mode syn-cookie

root@SRX100# show security screen
ids-option untrust-screen {
    tcp {
        syn-flood {
            alarm-threshold 1000;
            attack-threshold 1500;
            source-threshold 100;
            destination-threshold 1000;
            timeout 30;
        }
    }
}

root@SRX100# show security flow

syn-flood-protection-mode syn-cookie;




SYN-Frag篩選 - SYN-Frag Screen(前面已敘述)



TCP No Flags篩選 - TCP No Flags Screen
瞭解未設置任何標誌的TCP 包頭
正常的TCP 片段包頭至少會設置一個控制標誌。未設置任何控制標誌的TCP 片段是一個異常事件。由於不同的作業系統對這種異常情況的回應方式不同，目標設備的回應（或不回應）會提供有關其正在運行的作業系統類型的線索。
正常的TCP 片段包頭至少會設置一個控制標誌。未設置任何控制標誌的TCP 片段是一個異常事件。由於不同的作業系統對這種異常情況的回應方式不同，目標設備的回應（或不回應）會提供有關其正在運行的作業系統類型的線索。
如果使設備能夠檢測未設置任何標誌的TCP 片段，則設備將丟棄缺少標誌欄位或標誌欄位殘缺的所有TCP 資料包。

配置TCP No Flags篩選
set security screen ids-option untrust-screen tcp tcp-no-flag


TCP掃描篩選 - TCP Sweep Screen
與UDP和ICMP掃描篩選(Sweep Screens)類似，TCP掃描篩選用於檢測網路中不同主機上的掃描，這稱為水準掃描horizontal scan（而不是埠掃描port scan，這是一種垂直掃描vertical scan）。此行為通常表示網路偵察掃描被用來映射你的網路，所以通常這個行為應該被篩選阻止，以防止攻擊者識別你網路的重要特徵。
配置TCP掃描篩選
對於TCP掃描篩選，您只需配置在觸發篩選前必須接收多少個掃描數據包的閾值。閾值是在看到10個掃描數據包之間等待多少微秒。閾值越低，這個速度就越快。在這個例子中，我們使用2000微秒作為我們的閾值，或2毫秒。
set security screen ids-option untrust-screen tcp tcp-sweep threshold 2000


WinNuke Screen
WinNuke是20世紀90年代的傳統Windows攻擊。 使用單個數據包時，這導致Windows機器出現藍屏。 TCP數據包被發送到NetBIOS埠139並設置了緊急標誌，導致系統不穩定。雖然這種攻擊不太可能影響現代操作系統，但它仍然值得啟用，因為它可能意味著惡意行為。
配置WinNuke篩選
WinNuke篩選配置簡單，因為它可以打開或關閉。您不能配置此篩選的埠或旗標(ports or flags)，也不能配置它們的閾值。
set security screen ids-option untrust-screen tcp winnuke




會話限制篩選 - Session Limit Screens
在編寫本書時，有兩個會話限制篩選：Source-IP會話限制和Destination-IP會話限制。會話限制篩選對於部署而言非常重要;沒有它們，攻擊可能會通過消耗大量會話來創建DoS攻擊，以便FW或最終主機上的會話表被消耗，即使它們沒有發送大量流量。 Slowloris和TCP SockStress已經看到了這種攻擊。儘管它們本質上略有不同，但它們都試圖通過保持開放連接來消費系統上的會話。
注意
在其他情況下，錯誤配置或受損設備也可能導致大量會話消耗。所有這些向量可以通過會話限制篩選來緩解。儘管它們可能不是最終解決方案，但它們在使用其他篩選和設置來限制此類會話攻擊的影響方面非常有效。


Source-IP會話限制 - Source IP Session Limit Screen
限制單個來源IP位址可以建立的會話數量是限制不同DoS攻擊的關鍵控制，特別是那些不是單個欺騙數據包（我們可以使用其他組件如IPS來處理）的攻擊。為了有效地配置此篩選，理想的方式是確定單個IP位址合法擁有的會話數量。因為我們可以逐個區域地配置具有不同配置檔的篩選，所以根據流量來源識別這些限制是理想的選擇。例如，訪問DMZ網路服務器的外部資源的會話數可能與內部用戶訪問互聯網的會話數不同。
沒有任何完美的方式可以定義單個來源應該擁有多少個會話，但是一個簡單的方法是在沒有篩選報警的情況下啟用此篩選，然後從較低的數字開始，直到達到您認為的級別合法的，並且不會在正常活動中開火 - 或者您可以從高處開始降低。您還可以對流表中的會話進行計數，以瞭解每個主機有多少個會話。例如，您可以使用show security flow session source-prefix 192.168.2.50/32 summary來獲取每個主機或每個子網的計數。當然，並不是所有的主機都是平​​等的，但它給你一個開始的地方。
在互聯網上處理篩選時，您還應該考慮一些主機可能位於NAT設備後面的事實(可能設備後面會有1000台電腦)，因此請務必為此篩選留出一些額外空間。
配置源IP會話限制篩選
一旦確定了要配置的閾值，“源IP會話限制”篩選就很容易實現：您只需定義值。在這個例子中，我們為每個源IP地址設置了50個會話的限制。
set security screen ids-option untrust-screen limit-session source-ip-based 50


Destination-IP會話限制 - Destination IP Session Limit Screen
源IP會話限制篩選的對面是目標IP會話限制篩選。儘管不像限制DoS攻擊的源IP會話限制篩選那麼強大，但此篩選仍然有效，特別是在保護DMZ資源方面。例如，您可以在面向Internet的區域使用此篩選來限制有多少會話可以轉到您的DMZ服務器，以防止它們被會話氾濫所淹沒。當然，這個篩選理想情況下應該與源IP會話限制篩選一起使用，因為如果一個或一組來源可能達到目標限制，它可能導致合法用戶的DoS。此外，這可以用來限制內部用戶可以訪問的個人外部資源的會話數量。這可以很好地嘗試檢測某些異常活動。同樣，此篩選最好與源IP限制篩選一起使用。
配置目標IP會話限制篩選
目標IP會話限制篩選的配置與源IP位元址的配置相同。可以使用相同的方法為您的環境中的篩選閾值建立基線。在這個例子中，我們假設我們正在保護DMZ服務器群的入站會話，每個主機最多可以處理10,000個會話。
set security screen ids-option untrust-screen limit-session destination-ip-based 10000




SRX流量選項 - SRX Flow Options
設置SRX時，管理員經常會忽略SRX上的流量選項。 雖然它們是一個稍微高級的主題，但瞭解它們非常重要，特別是因為它們的配置會影響防火牆的功能。 Juniper嘗試將默認值設置為盡可能安全，但它可能會在某些環境中導致問題，因此最好審查這些不同的選項以確保它們滿足網路的需求。
在本節中，我們並未涵蓋所有流量選項，而是涵蓋了與篩選最相關的選項，其中包括老化和TCP會話選項。 本章範圍之外還有一些輔助流選項，包括TCP MSS，IP重組和其他一些輔助流選項，但老化和TCP會話篩選可能會影響DoS攻擊，這是本章的重點。
注意
除非另有說明，否則流量選項將全域應用於平臺上。


積極的會話老化 - Aggressive session aging
一個非常普遍被忽視的功能是防止有意的DoS攻擊和其他一些會話表消耗造成的中斷，這是會話老化的嚴重性。實質上，此功能允許您在平臺會話表消耗較高和開始積極老化舊空閒會話之前設置低和高閾值（水位watermark）。在許多部署中，由於復雜的應用程式需求，管理員將系統定義的默認值（TCP 30分鐘，UDP和ICMP 60秒，IP協議不同）更改為更高的默認超時值。對於TCP，如果會話正常關閉，我們將立即結束。對於UDP，IP和ICMP等其他協議，我們只能使用ALG關閉它們（例如，用於DNS）。否則它們將保持打開狀態，直到會話在規定的超時時間內空閒為止。在正常情況下，您可能永遠不會接近您的給定平臺的會話表限制 - 但情況並非總是如此，特別是在DoS攻擊或其他錯誤配置中。

當會話表的百分比消耗高於高水位時觸發積極的會話老化。然後，平臺不使用默認的閒置超時(default idle timeout)，而是使用為流量設置的新的早期年紀退出超時(new early-ageout timeout)。當然，這只適用於閒置的會話，不適用於正在傳輸的會話。當滿足高水位條件時，您可以將其視為默認閒置超時的覆蓋。一旦會話數量低於您設置的低水位，積極的會話老化過程就會完成。例如，假設您的平臺支持100萬次防火牆會話，並將高水位設置為80％，將低水位設置為60％，並將早期年紀退出(early ageout)設置為3秒鐘。當會話次數超過80萬次時，早期年紀退出會將任何閒置超過3秒以上的任何會話剔除。這將持續到會話表暫時低於600,000個會話時，正常的會話空閒超時將恢復（直到您再次回到80％以上）。
此時，您還應該認識到利用我們在上一節討論的IP會話限制篩選的重要性，因為它們可以很好地補充此功能，以防止個人消耗太多會話。
注意
自Junos 9.5推出以來，會話老化問題一直存在於分支平臺(branch platforms)中，但最近才在Junos 11.4及更高版本中添加到高端SRX (high-end SRX)。

配置積極會話超時流量選項- Configuring the aggressive session ageout flow option
要配置積極的會話老化，您只需確定由百分比定​​義的低水位和高水位，以及您希望在積極會話老化過程中應用於會話的早期年紀退出數值。由於這些值是以百分比形式應用的，因此您無需關心自己是否知道平臺的確切會話容量，儘管您始終可以在數據表中確定它。同樣重要的是要注意，通過新的代碼優化以及向64位或額外內存的轉變，這些限制可能會進一步增加，因此不要在此處發布，您應該查看最新的數據表以確保您有準確的理解。如果您擁有SRX，您還可以使用show security monitoring fpc <x> 命令確定您的平臺的最大會話數和消耗。這裡我們顯示SRX550和SRX3600的這個值。

root@SRX550-Node0> show security monitoring fpc 0
node0:
--------------------------------------------------------------------------
FPC 0
  PIC 0
    CPU utilization      :    7 %
    Memory utilization   :   67 %
    Current flow session :    23785 ←Current Session Consumption
    Max flow session     : 409600   ←Maximum Sessions (with IPv6 enabled)
Session Creation Per Second (for last 96 seconds on average):    0

root@srx3600n0> show security monitoring fpc 3
FPC 3
  PIC 0
    CPU utilization      :    5 %
    Memory utilization   :   70 %
    Current flow session : 127322    ←Current Utilizaiton for this SPU
    Max flow session     : 131072
    Current CP session   : 1477271 ←Currrent Utilization for this platform
    Max CP session       : 2359296 <-Max # of sessions per platform

Session Creation Per Second (for last 96 seconds on average): 6025

對於這個例子，我們配置積極的會話老化篩選啟動在80％，並設置早期年紀退出為三秒鐘。當會話利用率低於60％時，會話老化將終止。
set security flow aging high-watermark 80 low-watermark 60 early-ageout 3


TCP序列檢查 - TCP sequence checks
默認情況下，SRX執行檢查以確保到達SRX的會話數據包落在會話的TCP窗口內。這可以防止外部攻擊者對現有會話的劫持攻擊。 SRX在通信過程中監視TCP窗口，並確保到達防火牆的TCP數據包落在窗口內;否則會被丟棄。
注意
為了安全起見，TCP序列檢查通常應該開啟。有時，如果流量不對稱（意味著SRX只能看到流量的一端），則必須禁用TCP序列檢查。

配置TCP序列檢查
TCP序列檢查默認情況下在全域平臺級別啟用，也可以在FW規則的基礎上啟用。如果它們是按規則進行配置的，則必須全域禁用TCP序列檢查，然後按照FW規則啟用它。因為它們是默認啟用的，所以唯一的全域配置選項是禁用它們。
例11-1。全域禁用TCP序列檢查
set security flow tcp-session no-sequence-check

set security policies from-zone trust to-zone untrust policy 1 match source-address any destination-address any application any

set security policies from-zone trust to-zone untrust policy 1 then permit tcp-options sequence-check-required

set security policies from-zone trust to-zone untrust policy 1 then log session-close

root@SRX550-Node0# show security policies
from-zone trust to-zone untrust {
    policy 1 {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit {
                tcp-options {
                    sequence-check-required;   /* 我們可以在安全性原則中啟用流量選項之TCP序列檢查 */
                }
            }
            log {
                session-close;
            }
        }
    }

}

在本例中，我們全域禁用了TCP序列檢查，並啟用了按照個別防火牆規則（per FW rule basis）的TCP序列檢查。
這樣的好處是，我們可以精確的控制哪些流量要啟用TCP序列檢查，而非對稱流量（Asymmetric traffic）則因全域禁用的關係而不受影響。
但是缺點則是若您有30條不同的流量需要啟用TCP序列檢查的話，那麼就要設定30條策略? 不，其實我們可以透過設定位址集區(Address Pool)，然後將需要啟用TCP序列檢查的流量加入位址集區內，再將位址集區套用到安全性原則的來源地址上即可

為RST數據包配置TCP序列檢查
為了防止攻擊者發送TCP重置洪氾並希望關閉會話，還可以強制檢查TCP重置數據包以確保它們也是順序的。
set security flow tcp-session rst-sequence-check



TCP SYN檢查 - TCP SYN checks
瞭解TCP SYN 檢查
缺省情況下，Junos OS 在會話的第一個資料包中檢查SYN 標誌，並丟棄試圖發起會話但設置了非SYN 標誌的所有TCP 片段，以確保它與客戶端能通過SYN進行有狀態建立（statefully established）。 可以讓此資料包流保持原樣，也可以更改此資料包流，從而使Junos OS 在創建會話之前不執行SYN 標誌檢查。
如果啟用了SYN 標誌檢查的Junos OS 收到了不屬於現有會話的非SYN TCP 片段，它將丟棄資料包。 缺省情況下，Junos OS 不會在收到非SYN 片段時向源主機發送TCP RST。 通過使用set security zones security-zone trust tcp-rst 命令，可以配置設備向源主機發送TCP RST。 如果初始非SYN TCP 資料包的代碼位元為RST，則設備不發送TCP-RST。

在某些情況下因為流量不對稱的情況，您可能需要禁用SYN檢查。 通過防火牆的非對稱流量（Asymmetric traffic）會大大降低了SYN檢查的有效性（特別是第7層安全性）。

不在第一個資料包檢查SYN 標誌具有以下優點：
使用非對稱路由的NSRP—在動態路由環境下的主動/主動NSRP 配置中，主機可能會向一個設備（設備A）發送設置了SYN 標誌的初始TCP 片段，但可能會將SYN/ACK 路由到集群中的其他設備（設備B）。 如果這種非對稱路由發生在設備A 與設備B 同步了其會話之後，將不會有任何問題。另一方面，如果SYN/ACK 響應在設備A 同步會話之前到達設備B，並且啟用了SYN 檢查，則設備B 會拒絕SYN/ACK，從而不能建立會話。如果禁用SYN 檢查，設備B 將接受SYN/ACK 回應（即使該回應不屬於任何現有會話）並為其創建一個新會話表條目。

不間斷的會話—如果重置設備，或者即便是更改策略核心部分的一個元件，並啟用SYN 檢查，就會中斷所有現有會話或應用策略變更的那些會話，並且必須重新啟動這些會話。禁用SYN檢查可以避免這類網路資訊流的中斷。
注意: 對於這種情況，可以在安裝設備時先禁用SYN 檢查。然後，在幾小時後（建立的會話通過設備運行時）啟用SYN 檢查。策略核心部分包含以下主要元件：源區段和目標區段、源位址和目標位址、一項或多項服務以及一項操作。

但是上述優勢將犧牲以下安全性：
偵查漏洞—當一個設置了非SYN 標誌（如ACK、URG、RST、FIN）的初始TCP 片段到達一個關閉的埠時，許多作業系統（如Windows）會用設置了RST 標記的TCP 片段做出回應。如果埠是打開的，那麼接收方不會生成任何回應。
通過分析這些回應或無回應，聰明的資訊收集者能夠偵查受保護的網路以及Junos OS 策略集。
如果發送了設置了非SYN 標誌的TCP 片段，並且策略允許該片段通過，則接收這類片段的目標主機可能會丟棄片段，並用設置了RST 標誌的TCP 片段做出回應。這樣的響應將告知犯罪者在特定位址存在活動主機並且目標埠號被關閉。聰明的資訊收集者還將知道防火牆策略允許訪問相應主機的該埠號。
通過啟用SYN 標誌檢查，Junos OS 將丟棄不屬於現有會話且未設置SYN 標誌的TCP 片段，並且不返回TCP RST 片段。結果，無論策略集是否存在或目標主機上的埠是開放的還是關閉的，掃描者將得不到任何回復。

會話表氾濫—如果禁用SYN 檢查，攻擊者可以通過發送大量設置了非SYN 標誌的TCP 片段來氾濫受保護的網路，以此繞過Junos OS SYN 氾濫防護功能。儘管目標主機會丟棄資料包（並可能發送TCP RST 片段做出應答），此類氾濫會填滿設備的會話表。會話表填滿後，設備將無法處理合法資訊流的新會話。
通過啟用SYN 檢查和SYN 氾濫防護，可以阻止這類攻擊。 檢查在會話的初始資料包上是否設置了SYN 標誌將會強制所有新會話的建立必須從設置了SYN 標誌的TCP 片段開始。 SYN 氾濫防護即可限制每秒的TCP SYN 片段數，從而使會話表不致被氾濫。

設置TCP SYN 檢查
如果不需要禁用SYN 檢查，Juniper Networks 強烈推薦啟用SYN 檢查（Junos OS 初始安裝的缺省狀態）。可以使用set flow tcp-syn-check 命令啟用SYN 檢查。
啟用SYN 檢查後，除非設置了非SYN 標誌的TCP 片段屬於某個已建立的會話，否則設備將會丟棄這類片段。啟用SYN 檢查可幫助防止攻擊者偵查和會話表氾濫。缺省情況下已啟用TCP SYN檢查。

要禁用SYN 檢查，請執行以下操作：
user@host# set security flow tcp-session no-syn-check

如果您必須禁用SYN檢查，則可以全域完成或按照個別防火牆規則（per FW rule basis）來啟用，如此處所示。
set security flow tcp-session no-syn-check

set security policies from-zone trust to-zone untrust policy 1 match source-address any destination-address any application any

set security policies from-zone trust to-zone untrust policy 1 then permit tcp-options syn-check-required

set security policies from-zone trust to-zone untrust policy 1 then log session-close

[edit]
root@SRX100# show security policies
from-zone trust to-zone untrust {
    policy 1 {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit {
                tcp-options {
                    syn-check-required;
                }
            }
            log {
                session-close;
            }
        }
    }
}

在本例中，我們全域禁用了TCP SYN檢查，並啟用了按照個別防火牆規則（per FW rule basis）的TCP SYN檢查。


嚴格的SYN檢查 - Strict SYN checks
默認情況下，SYN檢查僅確保從客戶端發送到服務器的第一個數據包是一個SYN數據包。但是，您可以確保握手與客戶端發送SYN進行真正的三方握手，服務器使用SYN / ACK進行響應，然後客戶端使用嚴格的SYN檢查以ACK進行響應。這可以用來確保不發生其他異常協商，包括TCP分裂握手（TCP split handshake），客戶端發送SYN，然後服務器向客戶端發送SYN，客戶端發送SYN / ACK以及服務器發送SYN。這是大多數人不知道的TCP RFC 791的一部分。儘管對於SRX防火牆來說這不是問題（我們不會錯誤地指出流動的方向和誰是客戶端和服務器），但它可以適用於其他防火牆，特別是可能會使此混淆的第7層設備（UTM，IPS，負載平衡器等）。同樣，這對Juniper設備來說並不是問題，但啟用它通常會是一個好主意。

設置嚴格SYN 檢查
啟用了嚴格SYN 檢查時，設備將為TCP 會話啟用嚴格的三方握手檢查。這種檢查通過在進行三方握手之前丟棄資料包來增強安全性。缺省情況下會禁用TCP 嚴格SYN 檢查。
注意: 如果啟用了no-syn-check 或no-syn-check-in-tunnel，則將無法啟用strict-syn-check 選項。
要啟用嚴格SYN 檢查，請執行以下操作：
user@host# set security flow tcp-session strict-syn-check


隧道中的SYN檢查 - SYN checks in tunnels
SRX支持對全域明文值（global clear-text values）以外的隧道流量禁用TCP SYN檢查。 當您使用IPsec隧道進行非對稱路由（asymmetric routing）或IPsec會話故障切換時，此功能非常有用。 儘管禁用隧道流量的SYN檢查並不理想，但來自隧道的流量並不像一般來自互聯網的流量那樣不受歡迎（unsolicited），所以在流量到達時我們會更有信心。
配置隧道中的SYN檢查
set security flow tcp-session no-syn-check-in-tunnel




TCP狀態超時 - TCP state timeouts
除了可以逐個應用程式(application-by-application basis)配置的標準應用程式超時(standard application timeouts)之外，還可以在初始狀態和時間等待狀態(initial state and time wait states)中為TCP會話來應用的特殊超時（special timeout）。TCP初始超時(TCP initial timeout)是在完成SYN之後但在會話完成之前發生的。這是為了防止在沒有客戶端/服務器(client/server)完全建立會話(fully establishing the session)的情況下在防火牆上建立默認為30分鐘的完整TCP會話。編寫本篇時默認的值為20秒。
注意：
如果SYN檢查被禁用，這將會不適用，在這種情況下，會話將立即建立。
TCP等待狀態超時(TCP wait state timeout)用於在FIN/RESET終止之後將會話保持在“CLOSED”狀態。這樣做的目的是確保在會話關閉後可能收到的舊延遲數據包可以正確處理，並且不會作為新TCP會話的一部分結束。您有兩種選擇：您可以使用默認的兩秒超時，也可以指示防火牆使用該應用程式的默認超時時間。我們建議您只使用默認選項，除非您明確需要更改它。
配置TCP初始會話超時（TCP initial session timeout）和TCP時間等待超時（TCP time wait timeout）
在本例中，我們將TCP初始會話超時配置為25秒的值，並且TCP時間等待超時將為3秒。
set security flow tcp-session time-wait-state session-timeout 3
set security flow tcp-session tcp-initial-timeout 25
[edit security flow]
root@SRX100# show
tcp-session {
    tcp-initial-timeout 25;
    time-wait-state {
        session-timeout 3;
    }

}





故障排除和操作
牢記一些資源可以大大簡化操作篩選。在下面我們將檢查幾個篩選和流程選項，以幫助操作這些功能。

查看篩選配置檔設置Viewing Screen Profile Settings
您可以使用show security screen ids-option <Screen>命令從配置模式輕鬆查看篩選配置檔的配置。
root@SRX100> show security screen ids-option Screen

查看篩選攻擊統計Viewing the Screen Attack Statistics
在操作過程中，您可能想要瞭解篩選在平臺上發射的頻率。您可以通過查看show security screen statistics interface | interface <interface | zone> 命令的輸出來完成此操作，該命令可以根據介面或每個區域進行。
root@SRX100> show security screen statistics zone untrust

查看流量異常-Viewing Flow Exceptions
除了您可能有興趣查看的各種篩選統計資訊之外，每個介面還有許多可能感興趣的選項。接下來可以看到，介面統計資訊的輸出不僅包含有關字節和數據包傳輸的資訊以及QoS資訊，還包含大量非常有價值的流程異常資訊。這些計數器也可以指示網路上的可疑活動。
root@SRX100> show interfaces reth0 extensive





示例部署
對於此示例部署，我們配置了兩個篩選配置檔（Screen profiles），這些配置檔將應用於我們的SRX設備 Internet邊緣防火牆。第一個篩選配置檔將被稱為untrust-screen（外部Internet篩選），並將應用於Internet區域，第二個篩選配置檔將被稱為Internal-Screen（內部篩選），並將應用於LAN（部門A，部門B和內部服務器）和DMZ區域。我們的目標是確保我們擁有堅實的Screen profiles，以保護內部資源免受入站Internet攻擊，同時還標記（但不會中斷）任何可疑內部活動以供進一步調查。配置檔將設置如下：
untrust-screen外部篩選
·         強制執行所有丟棄數據包的操作。
·         拒絕TCP，UDP，IP和ICMP的所有基於數據包的異常，但允許IP分段（fragments）。
·         將Internet上的個別的來源IP限制為每台主機只有100個會話，並且只允許每個DMZ服務器接受25,000個會話。沒有策略允許直接從Internet訪問內部網路的入站流量，因此這個篩選的設定並不會影響到內部區域。
·         要防止埠掃描，請確保在IP，TCP，UDP和TCP各埠掃描之間設置了最小值。
·         為防止泛洪，只允許每個主機每秒發送100個SYN，並且每秒接收不超過1,000個SYN，1,000 UDP和300個ICMP數據包。
·         設置SYN攻擊的超時時間為30秒，每秒警報閾值（threshold）為750個SYN，並且每秒SYN數據包達到2,000時啟動（initiate）SYN Cookie。
Internal-Screens內部篩選(部門A，部門B，內部服務器區域)
·         記錄所有的違規但並不丟棄封包。
·         查找除IP碎片以外的所有基於數據（packet-based）包的異常。
·         應該標記（flagged）超過300個會話的內部來源（Internal sources）。
·         通過為TCP，UDP和IP / ICMP設置每5000微秒超過10個數據包的違例情況來查找可疑埠掃描活動。
·         應標記每秒發送超過200個SYN，2,000個UDP數據包或100個ICMP數據包的主機。
Flow Options流量選項
·         確保嚴格的SYN檢查（strict SYN checks）已啟用。
·         如果會話表（session table）的利用率高於80％，請啟動早期年紀退出（initiate an early ageout）兩秒鐘，直到平臺利用率低於65％。

配置篩選和流量選項的示例部署
root@SRX100> show configuration security screen
ids-option untrust-screen {
    icmp {
        ip-sweep threshold 1000;
        fragment;
        large;
        flood threshold 300;
        ping-death;
    }
    ip {
        bad-option;
        record-route-option;
        timestamp-option;
        security-option;
        stream-option;
        spoofing;
        source-route-option;
        loose-source-route-option;
        strict-source-route-option;
        unknown-protocol;
        tear-drop;
    }
    tcp {
        syn-fin;
        fin-no-ack;
        tcp-no-flag;
        syn-frag;
        port-scan threshold 1000;
        syn-flood {
            alarm-threshold 750;
            attack-threshold 2000;
            source-threshold 50;
            destination-threshold 1000;
            timeout 30;
        }
        land;
        winnuke;
        tcp-sweep threshold 1000;
    }
    udp {
        flood threshold 1000;
        udp-sweep threshold 1000;
    }
    limit-session {
        source-ip-based 100;
        destination-ip-based 25000;
    }
}

ids-option Internal-Screen {
    alarm-without-drop;
    icmp {
        ip-sweep threshold 5000;
        fragment;
        large;
        flood threshold 100;
        ping-death;
    }
    ip {
        bad-option;
        record-route-option;
        timestamp-option;
        security-option;
        stream-option;
        spoofing;
        source-route-option;
        loose-source-route-option;
        strict-source-route-option;
        unknown-protocol;
        tear-drop;
    }
    tcp {
        syn-fin;
        fin-no-ack;
        tcp-no-flag;
        syn-frag;
        port-scan threshold 5000;
        syn-flood {
            source-threshold 200;
        }
        land;
        winnuke;
        tcp-sweep threshold 5000;
    }
    udp {
        flood threshold 2000;
        udp-sweep threshold 5000;
    }
    limit-session {
        source-ip-based 300;
    }
}

root@SRX100> show configuration security flow
syn-flood-protection-mode syn-cookie;
aging {
    early-ageout 2;
    low-watermark 66;
    high-watermark 80;
}
tcp-session {
    strict-syn-check;
}

root@SRX100> show configuration security zones
security-zone Internet {
    screen untrust-screen;
    interfaces {
        reth0.0;
    }
}
security-zone Dept-A {
    screen Internal-Screen;
    interfaces {
        reth1.0;
    }
}
security-zone Dept-B {
    screen Internal-Screen;
    interfaces {
        reth1.1;
    }
}
security-zone Internal-Servers {
    screen Internal-Screen;
    interfaces {
        reth1.2;
    }
}

security-zone DMZ {
    screen Internal-Screen;
    interfaces {
        reth2.0;
    }

}




本篇文章部分內容取材自下列書籍：
Juniper SRX Series - A Comprehensive Guide to Security Services on the SRX Series
Junos Security - A Guide to Junos for the SRX Services Gateways and Security Certification
Junos OS安全配置指南-11.4

我們也可以參考下列Juniper原廠的網路連結：
Attack Detection and Prevention Feature Guide for Security Devices



這個網誌中的熱門文章

如何測試網路連線--網路斷線了怎麼辦?

-
圖片
如何測試網路連線--網路斷線了怎麼辦? 如何測試網路連線 -- 網路不通了 DIY 自行檢測網路連線 當我們打開電腦，卻發現無法上網了，這時候我們該怎麼辦呢 ? 如果在公司的話，我們可以請電腦人員來處理，而若是在家裡，我們就必須 DIY 先自行檢查一遍，如果檢查後仍然不能上網的話，我們也只能請朋友或是廠商來維修了。 而我們又要如何 DIY 先自行檢查呢 ? 請您依照下列步驟來進行： 第一步：進入 DOS 命令列模式。 按 " 視窗鍵 +R 鍵 " ，開啟執行視窗並輸入 " cmd " 後按 enter 鍵來進入 DOS 命令列模式。 第二步：檢查 ip 是否正常。 請輸入 " ipconfig " 來 檢查有無取得正常 IP 或是 IP 設定是否正確。 若電腦要上網，則每台電腦 一 定都要配有一個 IP 位址才行，本例的 IP 位址為 192.168.1.11 。 而 IP 位址分成 公共 IP 與 私有 IP 兩種， 只有公共 IP 才能上網 ( 網際網路 ) ，私有 IP 是無法直接上網的，私有 IP 只能在區域網路中使用 。而因為公共 IP 太少，所以要搭配私有 IP 來上網才行，這樣就可以達到以 100 台電腦，或是以 10000 台電腦，使用私有 IP 經過網路設備的轉換而達成只需使用 1 個公共 IP 就能讓大家一起上網的目的了。 私有 IP 無法直接連接網際網路，需要使用 網絡地址轉換（ Network Address Translator ， NAT ） 或者 代理伺服器   （ proxy server ） 來實現。與公網 IP 相比，私有 IP 是免費的，同時節省了 IP 位址資源，適合在區域網使用。私有 IP 常被用於家庭，學校和企業的區域網。 私有 IP 的範圍： 192.168.XX. XX 172.16. XX.XX – - 172.31. XX.XX 10. XX.XX.XX 我們只要看到 IP 位址開頭為上述範圍的 IP ，就表示您的 IP 為私有 IP 。 還有一種 ip 位址為 169.254. X.X ， 這種...
閱讀完整內容

筆記電腦刷BIOS失敗無法開機—用CH341A編程器重刷BIOS教學！

-
圖片
ASUS 筆記電腦更新 BIOS 失敗無法開機 —用 CH341A 編程 器重刷 BIOS 教學！ 前一陣子買了一台新的筆記電腦 (∩_∩) ，因此讓跟了我多年的 ASUS A42JA 筆電因此就被束之高閣沒有再被使用了 ヽ (´ ー ` )┌ ，後來想說反正放著不用也是浪費，乾脆就整理一下拿到拍賣網站給便宜賣掉算了 (¬ ‿ ¬) ，於是便動手開始移除個人的資料， 把 WINDOWS 7 系統還原到出廠狀態，順便一起更新 BIOS 的版本 ，而更新的過程很順利，在寫入 100% 後便自行重開機，重開機後小弟發現電源燈與硬碟燈皆恆亮，且螢幕沒有畫面，但小弟當然得等著它繼續開機更新 BIOS ，可是 2 分鐘 .. ， 5 分鐘過了 .. ，情況還是一樣，此時心中不禁起了疑惑   (• ิ _• ิ )? ，不會吧 ！ 會不會更新失敗了 ？ 難道這麼倒楣的事都讓小弟我給碰上了 ？ 一直等到十分鐘過後，小弟我終於失去耐性了，便下定決心長按電源鍵來讓筆記電腦強行關機   ( ╯‵ □′) ╯ ︵ ╧═╧ ，然後再開機，結果依然還是沒有畫面，電源燈與硬碟燈都恆亮的情況，小弟仍不死心的又重試了幾次，問題最後終於明朗化了，他媽的 BIOS 真的更新失敗了，對小弟來說一直是傳說中的問題竟被我給遇上了 ！！！   。゜゜ (´ Ｏ `) ゜゜。 因為這台 ASUS A42JA 筆電已購置多年，早就過保固了，因此小弟先上網 GOOGLE 下，發現這類問題 ASUS 原廠通常是換主機板（這是在論壇上討論的內容），且一片要價 $5000 元   ( ⊙ _ ⊙ ) ，所以送回原廠維修的方案小弟就不考慮了（超出了筆電的價值沒有維修的必要），小弟接著再努力的 GOOGLE 幾下，終於發現 BIOS 更新失敗後似乎可以自行使用燒錄器來重刷 BIOS  (¬_¬;) ，於是這便成為小弟唯一可行的解決方案了。 從網路上找到的刷 BIOS 案例中，發現大多是使用 ”CH341A 編程器 （ 燒錄器 ） ” 來進行燒錄作業，其基本作法是用烙鐵將主機板上的 BIOS 晶片（ 芯片 ） 拆下，再用 CH341A 燒錄器將原廠下載的 BIOS 檔案燒入芯片中，最後再將 BIOS 芯片焊接回筆電主機板上。而因為小弟也是...
閱讀完整內容

查理王的電腦部落格-首頁

-
查理王的電腦部落格 之所以成立這個部落格，最主要是要和大家分享自己學習電腦的一些經驗，在學習上往往因為一個指令或是一個觀念，常常我們要上網查幾天的資料才有答案，因此也就有了將自己的電腦學習經驗分享出來的想法，但是個人的經驗往往不足，觀念也不見得完全正確，加上粗心大意，校稿不認真等等因素，文中若有謬誤不對之處尚請大家見諒，還望各位大大能不吝賜教，將錯誤指明並 email 給我 ( taiwankid168@gmail.com ) ，小弟在此萬分感謝您 !! 因為沒有太多時間管理部落格，所以並沒有開放留言區提供給大家留言，尚請大家見諒 !! 小弟一向喜愛美食，所以未來會陸續在本版中加入美食文章，主要原因也是小弟文章的產量一向不高，所以就不另外開美食部落格了。另外，小弟也會在本版中陸續加入宗教相關文章，介紹小弟常拜拜的廟宇，歡迎大家來點閱。   美食文章    宗教相關文章    Juniper 防火牆相關文章   近期發表文章： 屏東 東港東隆宮介紹 （ 溫府千歲 、 王爺公 ） 屏東慈鳳宮 介紹 （ 屏東媽、阿猴媽 ） 花蓮聖地慈惠堂總堂介紹 （ 金母娘娘 ） 台中清水壽天宮介紹 （ 西勢媽 ） 高雄三鳳宮 介紹 （ 太子爺 ） 三峽清水祖師廟介紹 （ 清水祖師 ） 苗栗玉清宮介紹 （ 關聖帝君 ） 後龍山邊媽祖宮 介紹 （ 山邊媽 ） 竹南後厝龍鳳宮介紹 （ 媽祖 ） 新竹普天宮 介紹 （ 關聖帝君 ） 清水慈雲 宮介紹 （ 觀音佛祖 ） 新竹東寧宮介紹 （ 地藏王菩薩 ） 台南南鯤鯓代天府 介紹 （ 五府王爺 ） 台南南鯤鯓萬善堂 介紹 （ 囝仔公小王爺 ） 台南南 鯤鯓代天府 - 凌霄寶殿介紹（玉皇上帝 ） 難得的平民美味 - 甕仔海鮮麵 - 新竹北門雞絲飯 彰化 北斗美食 - 阿美姊高麗菜飯（北斗奠安宮前） 艋舺龍山寺介紹 （ 觀世音菩薩 ） 三峽行修 宮（ 行天宮三峽分宮 ）介紹 （ 關聖帝君 ） 北投行 天宮（ 忠義 廟 ）介紹 （ 關聖帝君 ） 行天宮（ 恩主公廟 ）介紹 （ 關聖帝君 ） 竹北天后宮介紹（竹北媽） 鹿港天后宮（舊祖宮）介紹 （鹿港媽） 苗栗通霄白沙屯拱天宮介紹 （ 白沙屯媽 ） 埔里寶湖宮天地堂地母廟介紹 （ 全台地母至尊總廟 ） 新竹竹蓮寺 介紹（觀世音菩薩） 彰化北斗奠安...
閱讀完整內容