概況：
（圖片可點選放大檢視）
企業網路大多數堡壘機部署時，為了不改變現有的網路拓撲結構，採用旁路部署的方案，透過在防火牆或者交換機上配置ACL策略限制使用者區PC直接訪問伺服器區主機IP或者埠（SSH，RDP等等），實現強制員工只能透過堡壘機訪問伺服器
談到堡壘機就避不開堡壘機被繞過問題，我這邊列舉如下幾種堡壘機被繞過的場景
例如：如下拓撲圖，4臺伺服器已經託管到堡壘機，可以直接透過堡壘機呼叫本地工具進行運維
（圖片可點選放大檢視）
（圖片可點選放大檢視）
（圖片可點選放大檢視）
場景1、繞過ACL策略
伺服器區防火牆或者交換機上沒有做ACL，以及當ACL策略做的細粒度不夠，導致使用者區PC可以直接繞過堡壘機，直接遠端伺服器
（圖片可點選放大檢視）
如圖如示，黑色虛線為本來的訪問路徑，需要透過堡壘機才能訪問Server_A
紅色虛線代表現在繞過堡壘機直接訪問Server_A
場景2、透過堡壘機跳轉繞過
另外一種場景就是，先透過堡壘機訪問A伺服器，然後再在A伺服器上去訪問B伺服器，這樣就繞過了堡壘機間接訪問了B伺服器
如下拓撲圖所示
（圖片可點選放大檢視）
先透過堡壘機訪問Server_A 192。168。31。18，由於root密碼都是堡壘機進行託管，不知道Server_B 192。168。31。232的root密碼 員工可以透過建立免密登入，
ssh-keygen -b 2048
（圖片可點選放大檢視）
再透過堡壘機訪問一次Server_B 192。168。31。232 將上一步生成公鑰內容匯入到192。168。31。232的 /root/。ssh/authorized_keys
（圖片可點選放大檢視）
這樣以後就訪問ServerB就只用透過堡壘機訪問Server_A，再在Server_A上直接SSH到Server_B
（圖片可點選放大檢視）
雖然Server_A的上的操作都可以被堡壘機審計（堡壘機錄影回放）， 但是假設剛好Server_A沒有被堡壘機託管，只把Server_B用堡壘機託管了，那這種繞過堡壘機的方式就會導致Server_B上的所有運維操作沒有被審計到
Server_A是開發環境，Server_B是生產環境，萬一對生產環境Server_B造成了破壞時，日誌也被刪除，這時就很難回溯了
再往深想一下：如果Server_A————->Server_B————>Server_E————>Server_F————>……。這樣多跳幾次呢？如何防範？
當然Windows伺服器RDP也會出現這種場景 先透過堡壘機訪問Server_C 192。168。31。82 再mstsc遠端到Server_D 192。168。31。116
（圖片可點選放大檢視）
解決方案細述
針對第1種和第2種場景如何進行徹底避免呢？
我這邊的一種解決辦法就是在針對Linux伺服器上做對SSH訪問控制，只允許堡壘機訪問伺服器的SSH，其他IP訪問SSH全部阻斷
cat >> /etc/hosts。deny << \EOFsshd： ALL ：spawn echo `date` login attempt from %c to %s ，the host is %h 。PID is %p >> /var/log/tcpwrapper。logEOFecho “#只允許堡壘機登入主機SSH” >> /etc/hosts。allowecho “sshd： 192。168。31。5” >> /etc/hosts。allow
（圖片可點選放大檢視）
（圖片可點選放大檢視）
針對所有堡壘機託管的Linux伺服器均做主機層面SSH訪問控制 透過堡壘機訪問Server_A 192。168。31。18，再在Server_A 192。168。31。18上SSH到Server_B 192。168。31。232就會被阻斷
（圖片可點選放大檢視）
可以tail -f /var/log/tcpwrapper。log 檢視阻斷日誌
tail -f /var/log/tcpwrapper。log Sat Nov 20 22：07：09 CST 2021 login attempt from 192。168。31。18 to sshd@192。168。31。232 ，the host is 192。168。31。18 。PID is 39888
當然如何堡壘機萬一發生故障時，就會出現單點故障，如何預防：
1、如果有備用堡壘機，需要將備用堡壘機的IP加到SSH訪問白名單中
2、將應急運維PC的IP加到SSH訪問白名單中，可以堡壘機出現故障時，應急運維PC登入到伺服器上進行SSH訪問控制配置修改
那RDP如何進行控制呢？可以在Windows防火牆的作用域中指定遠端IP地址及IP地址段，不過前提是開啟了Windows防火牆
（圖片可點選放大檢視）
可以看到當設定了只能堡壘機RDP遠端到Server_D 192。168。31。116 在Server_C 192。168。31。82上就無法mstsc遠端到Server_D 192。168。31。116
telnet 192。168。31。116 3389埠不通
（圖片可點選放大檢視）
場景3、其它繞過場景
1、目標伺服器遠端埠受到ACL限制，但其他埠沒有限制，那麼最簡單的解決方式就可以透過埠轉發來繞過
2、甚至如果伺服器可以訪問外網，可以直接透過向日葵，todesk，Teamviewer進行遠端，這樣就完全繞開了堡壘機審計
需要對伺服器網段封禁向日葵 Teamviewer等遠端工具， 這種方式就詳細展開描述了
