帶你讀《Linux系統安全：縱深防禦、安全掃描與入侵檢測》之二：Linux網絡防火牆

點選檢視第一章 點選檢視第三章

第2章 Linux網絡防火牆

網絡防火牆（Network Firewall）是一種網絡安全系統，它監控并依據預定義的規則控制進入和外發的網絡流量。

對于伺服器系統來說，按照縱深防禦的原則，使用網絡防火牆進行防護是除了保障實體安全之外必須實施的控制措施。

在諸多相關資訊安全規範和指南中也特别強調網絡控制的實踐。例如，在《ISO/IEC 27001:2005 資訊安全管理體系規範與使用指南》的“A.10.6.1網絡控制的控制措施”中指出，應確定網絡充分的管理和控制，以防範威脅、保護使用網絡的系統和應用維護安全，包括傳輸的資訊。

本章将介紹網絡防火牆的基本原理，并講解利用iptables、Cisco防火牆、TCP Wrappers和DenyHosts構築網絡防護措施的技術。接下來介紹在公有雲上實施網絡安全控制的措施以及使用堡壘機進一步加強網絡安全的實踐。随後介紹分布式拒絕服務攻擊（Distributed Denial of Service，DDoS）的防護措施。在本章的最後部分将介紹區域網路中ARP欺騙攻擊的模型和防禦方案。

2.1　網絡防火牆概述

在國際标準化組織（International Organization for Standardization，ISO）的開放系統互聯參考模型（Open System Interconnection Reference Model）中，網絡互聯模型分為7層，如表2-1所示。

一般來說，網絡防火牆工作在表2-1所示的第3層和第4層，它根據預定義規則中的上層協定或來源位址、目的位址、來源端口、目的端口來進行放行或者禁止的動作。

按照許可協定類型，網絡防火牆可分為商業防火牆和開源防火牆兩大類。

• 大多數商業防火牆以硬體的形式提供給客戶，其通過運作在專有硬體上的專有作業系統來實作網絡控制。典型的商業防火牆産品有：
  • Cisco自适應安全裝置（Adaptive Security Appliance，ASA）
  • Juniper安全業務網關（Secure Services Gateway，SSG）
  • 華為統一安全網關（Unified Security Gateway，USG）
• 開源防火牆一般以開源軟體的形式提供授權。典型的開源防火牆包括Linux iptables、FreeBSD IPFW和PF防火牆等。

值得一提的是，網絡防火牆隻是整個安全防護體系中的一部分，雖然其具有重要的、無可替代的作用，但是也有一定的局限性。

• 不能防止自然或者人為的故意破壞。網絡防火牆無法阻止對基礎設施的實體損壞，不管這種損壞是由自然現象引起的還是人為原因所導緻的。
• 不能防止受病毒感染的檔案的傳輸。受病毒感染的檔案經常通過電子郵件、社交工具（例如，即時通信工具）、網站通路的形式傳播，而這些途徑都是基于正常的網絡協定，是以網絡防火牆是無能為力的。
• 不能解決來自内部網絡的攻擊和安全問題。内部發起的網絡攻擊并未到達網絡邊界，是以網絡防火牆也無法産生作用。
• 不能防止政策配置不當或者配置錯誤引起的安全威脅。
• 不能防止網絡防火牆本身安全漏洞所帶來的威脅。例如，在2017年下半年，某知名安全廠商的多個防火牆産品被曝存在未授權遠端代碼執行漏洞（CVE-2017-15944），該漏洞基于其他３個單獨漏洞的綜合利用，可以通過Web管理端對防火牆實作root身份的未授權遠端代碼執行攻擊。

基于以上對網絡防火牆的局限性分析，我們可以知道，在依賴網絡防火牆提供的安全保障服務的基礎上，也應該建構多層次、全面保障的縱深防禦體系。

2.2　利用iptables建構網絡防火牆

Linux系統提供了iptables用于建構網絡防火牆，其能夠實作包過濾、網絡位址轉換（Network Address Translation，NAT）等功能。為iptables提供這些功能的底層子產品是netfilter架構（Netfilter項目的官方網站是

https://www.netfilter.org

）。Linux中的netfilter是核心中的一系列鈎子（Hook），它為核心子產品在網絡棧中的不同位置注冊回調函數（Callback Function）提供了支援。資料包在協定棧中依次經過這些在不同位置的回調函數的處理。

2.2.1　了解iptables表和鍊

netfilter鈎子與iptables表和鍊的處理順序如圖2-1所示。

netfilter有5個鈎子可以提供程式去注冊。在資料包經過網絡棧的時候，這些鈎子上注冊的核心子產品依次被觸發。這5個鈎子的處理時間如下。

• NF_IP_PRE_ROUTING：在資料流量進入網絡棧後立即被觸發，這個鈎子上注冊的子產品在路由決策前即被執行，如圖2-1中①所示的階段。
• NF_IP_LOCAL_IN：這個鈎子在路由判斷确定包是發送到本機時執行，如圖2-1中②所示的階段。
• NF_IP_FORWARD：這個鈎子在路由判斷是需要轉發給其他主機時執行，如圖2-1中的③所示的階段。
• NF_IP_LOCAL_OUT：這個鈎子在本機程序産生的網絡被送到網絡棧上時執行，如圖2-1中④所示的階段。
• NF_IP_POST_ROUTING：這個鈎子在資料包經過路由判斷即将發送到網絡前執行，如圖2-1中⑤所示的階段。

iptables中有以下5個鍊（Chain）。

• PREROUTING：NF_IP_PRE_ROUTING鈎子觸發。
• INPUT：NF_IP_LOCAL_IN鈎子觸發。
• FORWARD：NF_IP_FORWARD鈎子觸發。
• OUTPUT：NF_IP_LOCAL_OUT鈎子觸發。
• POSTROUTING：NF_IP_POST_ROUTING鈎子觸發。

iptables中有5種表（Table）：

• filter表。iptables中使用最廣泛的表，作用是進行過濾，也就是由filter表來決定一個資料包是否繼續發往它的目的位址或者被拒絕丢棄。
• nat表。顧名思義，nat表用于網絡位址轉換，可以改變資料包的源位址或者目的位址。
• mangle表。用于修改IP的頭部資訊，如修改TTL（Time to Live）。
• raw表。為iptables提供了一種不經過狀态追蹤的機制，在大流量對外業務的伺服器上使用這個表可以避免狀态追蹤帶來的性能問題。
• security表。提供在資料包中加入SELinux特性的功能。在實際應用中，security一般不常用，是以在下面的章節中不再包含這一部分内容。

通過以上分析，我們知道netfilter僅僅有5個鈎子，而iptables有5個鍊和5種表，由此可見在一個鈎子上可能有多個表的不同鍊需要處理，如圖2-1中的raw表、mangle表、filter表都有POSTROUTING鍊，這些不同表中的鍊根據自己向核心注冊時的優先級（priority）依次處理。

2.2.2　實際生産中的iptables腳本編寫

圖2-1展示了netfilter鈎子與iptables表和鍊的處理順序，顯示了其強大的處理功能。在實際生産中，使用比較多的是filter表，這個表用于對進入主機或者從主機發出的資料進行通路控制。在實踐中，筆者建議使用iptables腳本來管理通路控制規則，而不是通過編輯和修改系統自帶的/etc/sysconfig/iptables檔案，這樣做的好處是可以更加清晰地了解規則。

下面以代碼清單2-1作為一個實際生産中的iptables腳本，講解iptables的文法與使用的最佳實踐。

2.2.3　使用iptables進行網絡位址轉換

在實踐中，iptables還經常用于網絡位址轉換（NAT）的環境中。通過網絡位址轉換技術，可以有效減少直接部署公網IP位址的伺服器數量，增強網絡環境的安全性。

網絡位址轉換分為源位址轉換和目的位址轉換。

1. 源位址轉換

源位址轉換，主要用于無外網IP的伺服器（Server B）需要主動向外發起連接配接通路網際網路的場景下，如圖2-2所示。

在圖2-2中，Server B沒有外網IP，如其需要通路網際網路，則需要進行如下的設定：

1）在伺服器Server B上，指定其網絡的預設網關是10.128.70.112（即Server A的内網位址）。

2）在伺服器Server A上，啟用路由功能。啟用的方法是執行以下指令。

sysctl -w net.ipv4.ip_forward=1           

3）在Server A上，設定iptables規則如下。

iptables -t filter -A FORWARD -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to x.y.z.173 #eth0是Server A的外網網卡，x.y.z.173是Server A的外網IP           

經過以上3步驟設定後，Server B将會通過Server A通路網際網路。此時，在網際網路上看到的源位址是Server A的外網IP。

以Server B通路8.8.8.8的DNS服務為例，資料流程如下。

1）在Server B上，網絡層資料包格式為：目的位址IP 8.8.8.8，源位址IP10.128.70.111。

2）在Server A上經過源位址轉換後的網絡層資料包格式為：目的位址IP 8.8.8.8，源位址IP x.y.z.173。該轉換條目被記錄在/proc/net/nf_conntrack中。

3）8.8.8.8的響應（源位址IP 8.8.8.8，目的位址IP x.y.z.173）到達Server A後，Server A改寫網絡層資料包為源位址IP 8.8.8.8，目的位址IP 10.128.70.111。

這就是源位址轉換的工作過程。

2. 目的位址轉換

目的位址轉換用于外部使用者直接通路無外網IP的伺服器（Server B）提供的服務時，如圖2-2所示。例如，外部使用者希望通過網際網路通路到Server B上的Oracle資料庫（監聽端口是TCP 1521）時，可以使用如下的指令在Server A上進行目的位址轉換設定：

iptables -t nat -A PREROUTING -d x.y.z.173 -p tcp -m tcp --dport 1521 -j DNAT --to-destination 10.128.70.111:1521 #改寫目的位址為10.128.70.111，目的端口為1521
iptables -t nat -A POSTROUTING -d 10.128.70.111 -p tcp -m tcp --dport 1521 -j SNAT --to-source 10.128.70.112 #改寫源位址IP為Server A的内網IP，此時在Server B上相當于是與Server A在進行通信           

網絡位址轉換是運維人員在工作中經常用到的技術，是以我們需要非常熟悉源位址轉換和目的位址轉換這兩種方案。

2.2.4　禁用iptables的連接配接追蹤

1. 分析連接配接追蹤的原理

概要來說，連接配接追蹤系統在一個記憶體資料結構中記錄了連接配接的狀态，這些資訊包括源IP、目的IP、雙方端口号（對TCP和UDP）、協定類型、狀态和逾時資訊等。有了這些資訊，我們可以設定更靈活的過濾政策。

我們看一個實際的例子（通過cat /proc/net/nf_conntrack指令可以檢視目前連接配接追蹤的表）：

ipv4     2 tcp      6 62 SYN_SENT src=xxx.yyy.19.201 dst=87.240.131.117 sport=24943 dport=443 [UNREPLIED] src=87.240.131.117 dst=xxx.yyy.19.201 sport=443 dport=24943 mark=0 secmark=0 use=2 #該條目的意思是：系統收到了來自xxx.yyy.19.201:24943發送到87.240.131.117:443的第一個TCP SYN包，但此時對方還沒有回複這個SYN包（UNREPLIED）
ipv4     2 tcp      6 30 SYN_RECV src=106.38.214.126 dst=xxx.yyy.19.202 sport=18102 dport=6400 src=xxx.yyy.19.202 dst=106.38.214.126 sport=6400 dport=18102 mark=0 secmark=0 use=2#該條目的意思是：系統收到了來自106.38.214.126:18102發送到xxx.yyy.19.202:6400的第一個TCP SYN包
ipv4     2 tcp      6 158007 ESTABLISHED src=xxx.yyy.19.201 dst=211.151.144.188 sport=48153 dport=80 src=211.151.144.188 dst=xxx.yyy.19.201 sport=80 dport=48153 [ASSURED] mark=0 secmark=0 use=2#該條目的意思是：xxx.yyy.19.201:48153<-->211.151.144.188:80之間的TCP連接配接是ESTABLISHED狀态，這個連接配接是被保證的（ASSURED，不會因為記憶體耗盡而丢棄）           

該表中的資料提供的狀态資訊可以使用iptables的state子產品進行狀态比對，進而執行一定的過濾規則。目前iptables支援基于以下4種狀态的過濾規則：INVALID、ESTABLISHED、NEW和RELATED。

啟用連接配接追蹤後，在某些情況下，在設定iptables時會變得比較簡單。我們的伺服器需要主動通路

https://www.amazon.com

提供的接口時，3次握手的示意圖如圖2-3所示。

在基于狀态進行iptables設定時，使用如下的規則即可：

iptables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT # rule1
iptables -A OUTPUT -p tcp -j ACCEPT # rule2           

工作流程如下：

1）第1個包①比對到規則rule2，允許。

2）第2個包②因為在nf_conntrack表中有如下的規則比對到rule1，允許。

ipv4     2 tcp      6 431995 ESTABLISHED src=172.30.16.1 dst=54.239.25.200 sport=50611 dport=443 src=54.239.25.200 dst=172.30.16.1 sport=443 dport=50611 [ASSURED] mark=0 secmark=0 use=2           

3）第3個包③比對到規則rule2，允許。

2. 禁用連接配接追蹤的方法

通過2.2.4節的學習，我們知道在進行大量網絡傳輸連接配接的時候，啟用連接配接追蹤可能導緻網絡丢包、無法建立連接配接、TCP重傳等問題。是以，我們需要禁用連接配接追蹤。

禁用連接配接追蹤的方法有如下3個。

1）核心中禁用Netfilter connection tracking support。

編譯核心時，依次進入Networking support→Networking options→Network packet filtering framework (Netfilter)→Core Netfilter Configuration，禁用的方法如圖2-4所示（取消選中Netfilter connection tracking support）。

這樣編譯出來的核心将不支援連接配接追蹤功能，也就是不會生成以下的ko檔案。

kernel/net/netfilter/nf_conntrack.ko
kernel/net/netfilter/nf_conntrack_proto_dccp.ko
kernel/net/netfilter/nf_conntrack_proto_gre.ko
kernel/net/netfilter/nf_conntrack_proto_sctp.ko
kernel/net/netfilter/nf_conntrack_proto_udplite.ko
kernel/net/netfilter/nf_conntrack_netlink.ko
kernel/net/netfilter/nf_conntrack_amanda.ko
kernel/net/netfilter/nf_conntrack_ftp.ko
kernel/net/netfilter/nf_conntrack_h323.ko
kernel/net/netfilter/nf_conntrack_irc.ko
kernel/net/netfilter/nf_conntrack_broadcast.ko
kernel/net/netfilter/nf_conntrack_netbios_ns.ko
kernel/net/netfilter/nf_conntrack_snmp.ko
kernel/net/netfilter/nf_conntrack_pptp.ko
kernel/net/netfilter/nf_conntrack_sane.ko
kernel/net/netfilter/nf_conntrack_sip.ko
kernel/net/netfilter/nf_conntrack_tftp.ko
kernel/net/netfilter/xt_conntrack.ko
kernel/net/ipv4/netfilter/nf_conntrack_ipv4.ko
kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko           

此時，在iptables中不能再使用網絡位址轉換功能，同時也不能再使用-m state子產品。否則會産生以下的報錯資訊：

[root@localhost ~]# iptables -t nat -A POSTROUTING -o eth0 -s 172.30.4.0/24 -j SNAT --to 172.30.4.11
iptables v1.4.7: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
 [root@localhost ~]# iptables -I INPUT -p tcp -m state --state NEW -j ACCEPT
iptables: No chain/target/match by that name.           

２）在iptables中，禁用-m state子產品，同時在filter表的INPUT鍊中顯式地指定ACCEPT。

以圖2-3為例，在滿足這樣的通路需求時，我們使用的iptables必須修改為以下内容：

iptables -A INPUT -p tcp -s 54.239.25.200 --sport 443 -j ACCEPT # rule1
iptables -A OUTPUT -p tcp -j ACCEPT # rule2           

同時，在/etc/init.d/iptables中修改如下的内容：

修改前：NF_MODULES_COMMON=(x_tables nf_nat nf_conntrack) # Used by netfilter v4 and v6
修改後：NF_MODULES_COMMON=(x_tables) # Used by netfilter v4 and v6           

3）在iptables中，使用raw表，指定NOTRACK。

iptables -t raw -A PREROUTING -p tcp -j NOTRACK
iptables -t raw -A OUTPUT -p tcp -j NOTRACK
iptables -A INPUT -p tcp -s 54.239.25.200 --sport 443 -j ACCEPT # rule1
iptables -A OUTPUT -p tcp -j ACCEPT # rule2           

在以上的3種方法中，根據自己的業務情況，可以參考實施其中一種。

在配置了網絡位址轉換的伺服器上，不能禁用連接配接追蹤，但是此時可以使用如下的方法來提高連接配接追蹤的條目上限。

在/etc/sysctl.conf中，新增如下的内容：

net.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_max = 524288           

新增配置檔案/etc/modprobe.d/netfilter.conf，内容如下：

options nf_conntrack hashsize=131072           

執行以下的指令使其生效：

/etc/init.d/iptables restart #重新加載連接配接追蹤子產品，同時更新nf_conntrack配置hashsize
sysctl -p #使得修改的sysctl.conf中nf_conntrack上限提高           

在未指定時，系統nf_conntrack_max的值根據以下公式計算得出：

nf_conntrack_max = nf_conntrack_buckets * 4           

在未指定時，系統nf_conntrack_buckets的值根據以下公式計算得出：

在系統記憶體大于等于4GB時，nf_conntrack_buckets = 65536
在系統記憶體小于4GB時，nf_conntrack_buckets = 記憶體大小 / 16384           

在本案例中，我們使用options nf_conntrack hashsize=131072自主指定了Buckets的大小。

Buckets和連接配接追蹤表的關系如圖2-5所示。

設定Buckets合理的值（一般為預計的連接配接追蹤表上限的1/4），可以使得連接配接追蹤表的定位效率最高。

3. 确認禁用連接配接追蹤的效果

我們在禁用了連接配接追蹤後，可以使用如下兩個方法來驗證效果：

1）檢查/var/log/messages内容不再出現table full的報錯資訊。

2）檢查lsmod |grep nf_conntrack的輸出，确認沒有任何輸出即可。

如果是在網絡位址轉換伺服器上，則需要執行以下的指令來檢查效果：

sysctl net.netfilter.nf_conntrack_max #确認該值是我們修改後的結果
sysctl net.netfilter.nf_conntrack_count #确認該值能夠突破出問題時的最大追蹤數           

2.3　利用Cisco防火牆設定通路控制

在網絡邊界（Network Perimeter）上，筆者建議使用專用的商業硬體防火牆裝置進行防護，這主要是基于其性能和可配置管理性的優勢。另外，使用異構的網絡防火牆裝置，還可以為網絡内系統和服務增加一層安全防護。本節以Cisco防火牆為例，介紹ACL（Access Control List，通路控制清單）的使用方法。

ACL使用包過濾技術，在路由器上讀取IP層及第4層標頭中的資訊，如源位址、目的位址、源端口、目的端口等，根據預先定義好的規則對包進行過濾，進而達到通路控制的目的。

Cisco IOS的通路控制清單ACL分為兩種，根據不同場合應用不同種類的ACL：

1）标準通路控制清單。它通過使用IP包中的源IP位址進行過濾，使用通路控制清單号1到99來建立相應的ACL。

2）擴充通路控制清單。它可以依據第4層的資訊進行過濾，相對于标準通路控制清單，可以進行更細粒度的控制。

我們使用擴充通路控制清單來保護Cisco路由器後面的主機。使用的指令如下：

Router# configure terminal
Router(config)#ip access-list extended SDACL #定義擴充ACL，名稱是SDACL
Router(config-ext-nacl)#permit icmp any any
Router(config-ext-nacl)#permit tcp any host x.y.16.134 eq 80
Router(config-ext-nacl)#permit udp host 202.96.209.5 eq 53 host x.y.16.134
Router(config-ext-nacl)#permit tcp host 202.96.209.5 eq 53 host x.y.16.134
Router(config-ext-nacl)#permit udp host 114.114.114.114 eq 53 host x.y.16.134
Router(config-ext-nacl)#permit tcp host 114.114.114.114 eq 53 host x.y.16.134
Router(config-ext-nacl)#permit tcp host 61.172.240.227 host x.y.16.134 eq 22
Router(config-ext-nacl)#permit tcp host 61.172.240.228 host x.y.16.134 eq 22
Router(config-ext-nacl)#permit tcp host 61.172.240.229 host x.y.16.134 eq 22
Router(config-ext-nacl)#deny ip any any #預設禁止所有
Router(config-ext-nacl)#exit
Router(config)#int g0/1
Router(config-if)#ip access-group SDACL out #把ACL綁定到g0/1的出方向
Router(config-if)#exit
Router(config)#exit           

2.4　利用TCP Wrappers建構應用通路控制清單

TCP Wrappers也被稱為tcp_wrappers。它是一個基于主機的網絡通路控制清單系統，在Linux和BSD等系統上都有支援。最初的代碼是由Wietse Venema在1990年編寫的，在2001年，以類BSD的許可釋出。TCP Wrappers的核心是名為libwrap的庫，所有調用這個庫的程式都可以利用libwrap提供的網絡通路控制能力。

在Linux系統中，我們可以使用ldd指令來判斷一個程式是否調用了libwrap的庫，示例如代碼清單2-2所示。

在代碼清單2-2中，我們可以看到，OpenSSH的伺服器端程式/usr/bin/sshd調用了libwrap。那麼我們就可以使用TCP Wrappers來控制允許哪些主機或者禁止哪些主機通路sshd。

遠端IP請求連接配接的時候，TCP Wrappers檢查政策是先看/etc/hosts.allow中是否允許，如果允許就直接放行；如果沒有，則再看/etc/hosts.deny中是否禁止，如果禁止，那麼就禁止連接配接；否則允許連接配接。

我們可以使用如下的配置來僅僅允許指定的IP 104.224.147.43通路sshd。

配置/etc/hosts.allow來限制sshd的通路。

sshd:104.224.147.43:allow
sshd:ALL:deny #明确禁止不在白名單内的IP通路           

/etc/hosts.allow的配置文法如下：

服務名:來源IP/網段（多個IP/網段以英文逗号,分隔）:動作（允許 => allow，禁止 => deny）           

使用TCP Wrappers時，不需要重新啟動程式，修改/etc/hosts.allow和/etc/hosts.deny并儲存後，對于所有建立立的TCP連接配接立即生效；對于已建立的連接配接則沒有作用，此時需要手動把網絡連接配接斷掉，例如使用iptables或者使用kill指令終止對應的程序來強制遠端重建立立連接配接。

2.5　利用DenyHosts防止暴力破解

在2.2節和2.4節我們介紹了使用iptables和TCP Wrappers來進行通路控制的方案。以上的措施，全部基于白名單機制，對于沒有固定來源IP位址但又需要進行防護的場景來說，使用DenyHosts來防止暴力破解是一種非常有效的措施。

DenyHosts由Phil Schwartz編寫，其官方網站是

http://denyhosts.sourceforge.net

。

DenyHosts是使用Python開發的，它通過監控系統安全日志（例如，/var/log/secure）來分析是否存在對OpenSSH的暴力破解行為。如發現暴力破解，則其從該系統安全日志中分析出來源IP位址，然後通過在/etc/hosts.deny中加入相應的條目來使用TCP Wrappers禁止該IP位址的後續連接配接嘗試。

DenyHosts的安裝和啟動腳本如代碼清單2-3所示。

下面我們來看看DenyHosts的幾個核心配置片段（檔案/usr/share/denyhosts/denyhosts.cfg）。

• SECURE_LOG：指定系統安全日志的位置，在CentOS和Redhat系統中設為/var/log/secure。
• HOSTS_DENY：檢測到暴力破解後，指定在哪個檔案中添加相應的惡意IP并禁止，在CentOS和Redhat系統中設為/etc/hosts.deny。
• BLOCK_SERVICE：檢測到暴力破解後，指定封停來源IP通路哪些服務，可以指定sshd或者ALL（即封停來源IP通路任何使用了libwrap的服務程式）。
• DENY_THRESHOLD_INVALID：對于在/etc/passwd不存在的使用者名的暴力嘗試，指定發現多少次以後封停，這個值使用預設的5即可。
• DENY_THRESHOLD_VALID：對于在/etc/passwd存在的使用者名（除root外）的暴力嘗試，指定發現多少次以後封停。建議适當調大這個值（如設定為20），以避免合法使用者自己輸錯密碼導緻的無法繼續登入。
• DENY_THRESHOLD_ROOT：對于root賬戶的暴力嘗試，指定發現多少次以後封停。建議适當調大這個值（如設定為10），以避免合法root使用者自己輸錯密碼導緻的無法繼續登入。
• HOSTNAME_LOOKUP：指定是否啟用來源IP到完整域名（Fully Qualified Domain Name，FQDN）的解析，建議設定為NO，以節省伺服器嘗試反向解析的開銷。

在安裝和啟動了DenyHosts以後，我們可以通過/etc/hosts.deny來檢視效果。一般情況下，在較短的時間内就可以發現其已經封停了大量的暴力破解嘗試。由此，也可以看出，網際網路上時時刻刻存在着風險，總有一些不懷好意的人利用工具來發現可能的“獵物”。

以下是實際生産中抓到的一些惡意IP位址來源，我們可以看到，DenyHosts在記錄該IP位址的同時記錄了其添加到系統通路控制清單的時間：

# DenyHosts: Thu Dec  6 14:44:33 2018 | sshd: 177.114.90.32
sshd: 177.114.90.32
# DenyHosts: Thu Dec  6 14:44:33 2018 | sshd: 171.11.231.58
sshd: 171.11.231.58
# DenyHosts: Thu Dec  6 14:44:33 2018 | sshd: 193.112.128.197
sshd: 193.112.128.197           

2.6　在公有雲上實施網絡安全防護

随着雲計算的興起和公有雲資源成本效益的提高，大量的企業正在計劃或已經把業務從自有網際網路資料中心（Internet Data Center，IDC）遷移到公有雲上。

在國内，知名的公有雲廠商舉例如下：

• 阿裡雲（ https://www.aliyun.com ）
• 騰訊雲（ https://cloud.tencent.com
• 華為雲（ https://www.huaweicloud.com
• 金山雲（ http://www.ksyun.com

在國外，知名的公有雲廠商舉例如下：

• 亞馬遜AWS（ https://aws.amazon.com
• 微軟Azure（ https://azure.microsoft.com
• 谷歌雲（ https://cloud.google.com

在企業IT基礎設施遷移到公有雲的過程中，可以通過良好的架構設計和運維實踐來進行網絡安全防護。

2.6.1　減少公網暴露的雲伺服器數量

通過合理規劃架構來減少公網暴露的雲伺服器數量是減小攻擊面和提高系統安全級别的重要手段。筆者建議在規劃架構時可以考慮使用公有雲上提供的彈性負載均衡（Elastic Load Balance）和NAT網關（NAT Gateway）來實作這一目的。

• 彈性負載均衡将通路流量自動分發到多台雲伺服器，進而擴充應用系統對外的整體服務能力，實作更高水準的應用容錯。彈性負載均衡除了實作業務分流、負載均衡功能之外，也極大地減少了雲伺服器對公網IP的需求（減少成本支出），還減少了對外暴露的攻擊面（增加安全性）。
• NAT網關能夠為虛拟專有網絡（Virtual Private Cloud，VPC）内的彈性雲伺服器提供源網絡位址轉換（SNAT）功能。通過靈活簡易的配置，即可輕松建構虛拟專有網絡的公網出口。NAT網關為虛拟專有網絡内雲伺服器提供主動連接配接到網際網路的服務。

如圖2-6所示是某物流電子商務公司的混合雲網絡架構設計圖。

在圖2-6中，我們使用公有雲上的VPN Gateway來把本地機房和公有雲VPC以内網的形式連接配接起來，同時在公有雲上使用彈性負載均衡、NAT網關來減少雲伺服器的公網暴露。

2.6.2　使用網絡安全組防護

網絡安全組（Network Security Group）是一種虛拟防火牆，其具備包過濾功能，用于設定單台或多台雲伺服器的網絡通路控制。它是重要的網絡安全隔離手段，用于在公有雲上劃分安全邊界。當伺服器遷移到公有雲上以後，我們可以借助公有雲提供的網絡安全組進行防護。以阿裡雲為例，其配置網絡安全組規則的界面如圖2-7所示。

各大型公有雲廠商提供的網絡安全組配置界面大同小異，而且提供了詳細的配置說明文檔，是以這裡不再贅述。

需要說明的是，公有雲提供的網絡安全組應該僅作為一種附加的安全措施，而不應該作為替代iptables和TCP Wrappers的手段，僅僅依靠網絡安全組提供的防護是不夠的。

2.7　使用堡壘機增加系統通路的安全性

堡壘機（Bastion Host）也被稱為跳闆機，是網絡環境中一台特殊的伺服器，它提供其他所有伺服器的通路控制入口，也就是通過這台伺服器來通路和管理其他所有伺服器。

使用堡壘機的簡化版網絡架構圖如圖2-8所示。

與管理者直接從本機發起網絡連接配接來管理所有伺服器相比，使用一台或者多台分布式堡壘機可以提供更多的安全性。

• 統一登入來源。被管理伺服器上僅僅開放更有限的通路來源IP位址。在管理者直接從本機發起網絡連接配接來管理伺服器的情況下，往往因為管理者來源IP位址是動态IP位址或者需要從多個場所通路而導緻需要在所有被管理伺服器上添加較多的白名單來源IP位址。在這些IP位址失效或者被多人共用的情況下，将成為嚴重的攻擊面。在堡壘機模式下，所有被管理伺服器上僅僅需要開放信任這些有限個堡壘機的出口IP位址，進而有效地減少了攻擊面。
• 操作可審計。因為管理者從堡壘機上進行伺服器的管理，是以其所有操作都可以被記錄下來，而不用再依賴每台伺服器上記錄的記錄檔。在每台伺服器上非集中式管理記錄檔的問題是，在發生了入侵事件後，黑客可以比較容易地删除獨立伺服器上的記錄檔而導緻無法追溯。采用堡壘機後，記錄檔記錄在堡壘機上，黑客無法删除這些操作審計日志。
• 可設定靈活的通路控制。比如：
  • 在堡壘機上設定在某些時間段内不允許通路和管理被控制伺服器，也是增加安全性的一個重要手段。
  • 可以通過在堡壘機上設定可執行指令的範圍（黑名單和白名單）來進一步提高安全性。
• 便于使用者授權。通過在堡壘機上集中管理伺服器的實際登入賬号，可以避免把伺服器的賬号資訊分散地交接給不同的維護人員，進而可以在一定程度上避免伺服器登入資訊的洩露和被惡意利用。

2.7.1　開源堡壘機簡介

1. Jumpserver

Jumpserver是一款優秀的開源堡壘機軟體，其官方網站是

http://www.jumpserver.org

。Jumpserver 提供的功能如表2-2所示。

2. 麒麟堡壘機

麒麟堡壘機是一款易部署、易使用、功能全面的堡壘機産品，其官方網站是

http://www.tosec.com.cn

。麒麟堡壘機提供開源版本和收費版本，這兩個版本的特性對比如表2-3所示。

2.7.2　商業堡壘機簡介

1. 齊治堡壘機

齊治堡壘機的官方網站是

https://www.shterm.com

。作為一款成熟的商業堡壘機産品，其解決的問題如下。

• 自動化操作：這是有效提高運維效率的關鍵，可以讓堡壘機自動幫助運維人員執行大量、重複的正常操作，提高運維效率。
• 操作審計：解決操作事故責任認定的問題，確定事故發生後，能快速定位操作者和事故原因，還原事故現場和舉證。
• 通路控制：解決操作者合法通路操作資源的問題，通過對通路資源的嚴格控制，確定操作者在其賬号有效權限和期限内合法通路操作資源，降低操作風險。
• 身份管理：解決操作者身份唯一的問題，身份唯一性的确定是操作行為管理的基礎，将確定操作管理的各項内容有源可溯。
• 集中管理：解決操作分散、無序的問題，管理的模式決定了管理的有效性，對操作進行集中統一的管理，是解決運維操作管理諸多問題的前提與基礎。

2. 帕拉迪統一安全管理和綜合審計系統

帕拉迪統一安全管理和綜合審計系統通過統一運維入口、統一身份認證、統一資源管理、統一權限管理和統一過程審計等一系列手段，将制度落于實處；通過技術手段硬性規範了運維操作的流程，控制人為風險，提高IT系統整體可用性。帕拉迪統一安全管理和綜合審計系統的官方網站是

http://www.pldsec.com

3. 華為UMA運維審計系統

華為UMA（Unified Maintenance and Audit）運維審計系統是專為營運商、政府、金融、電力、大企業及上市公司而設計的，能夠為組織建構一個統一的IT核心資源運維管理與安全審計的平台。通過對核心業務系統、作業系統、資料庫、網絡裝置等各種IT資源的賬号、認證、授權和審計的集中管理和控制，實作運維集中接入、集中認證、集中授權、集中審計功能，滿足使用者IT運維管理和IT内控外審的需求。華為UMA運維審計系統産品介紹位址是

http://enterprise.huawei.com/cn/products/security/security-management/security-management-system/hw-143174.htm

2.8　分布式拒絕服務攻擊的防護措施

分布式拒絕服務（Distributed Denial of Service，DDoS）攻擊是指借助于用戶端/伺服器技術，将多個計算機（特别是僵屍網絡的“殭屍電腦”，指被黑客入侵後控制的網絡伺服器或者個人計算機）聯合起來作為攻擊平台，對一個或多個目标發動拒絕服務攻擊，進而成倍地提高拒絕服務攻擊的威力。

僅僅從我國國内來看，僵屍網絡的規模已十分驚人。中國國家計算機網絡應急技術處理協調中心在2018年4月釋出的《2017年我國網際網路網絡安全态勢綜述》中指出：“據CNCERT抽樣監測，2017年我國境内感染計算機惡意程式的主機數量約1256萬台。從所控制我國境内主機數量來看，位于美國、中國台灣和中國香港的控制伺服器控制規模分列前三位，分别控制了我國境内約323萬、42萬和30萬台主機。”如此數量龐大的僵屍網絡，為黑客實施分布式拒絕服務攻擊提供了充足的“武器彈藥”。

2.8.1　直接式分布式拒絕服務攻擊

直接式分布式拒絕服務攻擊是一種典型的分布式拒絕服務攻擊，其邏輯圖如圖2-9所示。

黑客通過控制機，向被其控制的“殭屍電腦”（被入侵後的伺服器、個人計算機等）發出指令，通過木馬程式發起流量，引導到被攻擊伺服器。被攻擊伺服器受限于帶寬和CPU處理能力，導緻業務中斷而無法向正常使用者提供服務，造成直接的經濟損失。在這種攻擊模式下，攻擊的能力取決于黑客可以控制的“殭屍電腦”的數量及“殭屍電腦”提供的網絡帶寬容量。

2.8.2　反射式分布式拒絕服務攻擊

反射式分布式拒絕服務攻擊是另外一種典型的分布式拒絕服務攻擊模式，如圖2-10所示。

在這種模式情況下，“殭屍電腦”伺服器通過構造虛假DNS請求（UDP資料以被攻擊伺服器作為來源IP位址）向全球數量巨大的開放DNS伺服器發起請求，開放DNS伺服器産生響應後發送到被攻擊伺服器。

在這種攻擊模式下，攻擊行為充分利用了DNS請求響應的非對稱特點，也就是，請求資料流量小，響應資料流量大。在一個典型的DNS放大攻擊（DNS Amplification Attack）或者NTP放大攻擊（NTP Amplification Attack）中，響應資料和請求資料的資料量對比可以達到20:1甚至200:1，放大效果非常明顯。同時UDP不需要實際建立連接配接，對源位址沒有任何形式的校驗，是以可以把“殭屍電腦”僞裝成被攻擊伺服器發起UDP請求。

在目前的情況下，我們發現分布式拒絕服務以UDP協定為多，同時利用類似DNS反射、NTP反射或者Memcached反射的漏洞進行攻擊。例如，據The Hack News網站報道，全球知名代碼托管商GitHub在2018年2月28日遭受的分布式拒絕服務攻擊規模達到驚人的1.3 Tbps，其中大部分流量正是來自于利用Memcached反射漏洞進行的攻擊。

2.8.3　防禦的思路

對于分布式拒絕服務攻擊，我們應如何防禦呢？

在遭受小流量分布式拒絕服務攻擊時，可以通過上層裝置過濾非法的UDP資料進行清洗。

在遭受大流量分布式拒絕服務攻擊時，目前比較好的方案是與電信營運商合作，在源頭上或者營運商互聯的接口上進行清洗。中國人民銀行2012年5月釋出的《網上銀行系統資訊安全通用規範》（标準編号：JR/T 0068-2012）中也指出：“應防範對網上銀行伺服器端的DoS/DDoS攻擊。可參考的加強措施包括但不限于：與電信營運商簽署DoS/DDoS防護協定。”有興趣的讀者可以參考雲堤的方案。雲堤是中國電信推出的營運商級DDoS防護方案，使用靈活、高效。雲堤官方網站是

http://www.damddos.com

2.9　區域網路中ARP欺騙的防禦

在區域網路中，ARP（Address Resolution Protocol，位址解析協定）欺騙是需要特别注意的一種攻擊模式，筆者在工作中曾多次遇到這種攻擊。ARP欺騙攻擊的模型如圖2-11所示。

在圖2-11中，被欺騙對象（IP位址為192.168.1.2，真實MAC位址為fa:38:4e:c0:fb:02）發送“①ARP請求（廣播）：IP位址為192.168.1.1的MAC位址是多少？”，該廣播包被發送給同區域網路内的所有伺服器。攻擊者（IP位址為192.168.1.3，真實MAC位址為fa:38:4e:c0:fb:03）搶先回複“②欺騙的ARP響應（單點傳播）：IP位址為192.168.1.1的MAC位址是fa:38:4e:c0:fb:03”。此時，被欺騙對象的ARP表中會增加一條IP和MAC位址的映射：192.168.1.1映射到fa:38:4e:c0:fb:03。被欺騙對象主動發到區域網路外的任何資料都會被攻擊者截獲嗅探甚至修改。

防禦ARP欺騙攻擊的方式一般分為以下兩種。

• 使用靜态MAC位址綁定。例如，在圖2-11中，在被欺騙對象上使用指令行執行以下語句即可：

arp -s 192.168.1.1 fa:38:4e:c0:fb:01           

• 使用Linux下的arptables。例如，在圖2-11中，在被欺騙對象上使用指令行執行以下語句即可：

arptables -A INPUT -i eth0 --src-ip 192.168.1.11 --src-mac ! fa:38:4e:c0:fb:01 -j DROP           

2.10　本章小結

網絡防火牆是建構伺服器系統安全縱深防禦體系中不可或缺的一個組成部分。本章詳細介紹了使用Linux iptables、Cisco防火牆、TCP Wrappers建構防火牆系統的方法，也介紹了使用DenyHosts阻止來自網際網路的暴力破解的實踐，然後介紹了在公有雲上使用網絡安全組保障安全的方案。作為規範化伺服器遠端網絡管理的關鍵工具，堡壘機發揮了重要作用。本章還簡要介紹了開源堡壘機和商業堡壘機的各自特點。随後講解了分布式拒絕服務攻擊的原理和防禦方法。作為結束部分，筆者介紹了一種專門針對區域網路主機的欺騙攻擊—ARP欺騙攻擊，并講解了對于這種攻擊模型和防禦方法。

推薦閱讀材料

• 《Linux Firewalls: Enhancing Security with nftables and Beyond (4th Edition)》，Steve Suehring著。該書是詳細講解Linux防火牆相關技術的經典著作。
• 《ChinaUnix講座：2小時玩轉iptables》，百度文庫 https://wenku.baidu.com/view/21730feecc17552706220872.html 。該文檔是學習iptables的入門指南。
• https://tools.ietf.org/html/rfc826 ，以太網位址解析協定RFC。
• https://linux.die.net/man/8/arptables ，詳細介紹了arptables指令的各種參數。

本章重點内容助記圖

本章涉及的内容較多，是以，筆者特編制了圖2-12以幫助讀者了解和記憶重點内容。