配置 RSyslog 伺服器以接收 CEF 格式日誌

分享

本篇文章會使用 Ubuntu 18.04 架設 RSyslog 伺服器,並且加入 Let's Encrypt 啟用 Syslog over TLS。

準備環境

1. 使用 Linode 架設 Ubuntu 18.04

2. 準備一個網域名稱

在 Ubuntu 上安裝 RSyslog 必要服務

首先透過 SSH 連線到 Linode 上面的 Ubuntu 服務,你可以在 Linode 的面板上面,看到 SSH Access 的相關資訊。連線後執行以下指令:

  1. add-apt-repository ppa:adiscon/v8-stable
  2. apt-get update -y
  3. apt-get install rsyslog
  4. apt-get install rsyslog-gnutls
  5. apt-get install rsyslog-openssl

上面的指令全部安裝完後,可以使用 rsyslogd -N1 檢查所安裝的 Rsyslog 版本。本篇文章撰寫時,安裝的是 version 8.2110.0。也可以另外透過 apt-get list --installed,確認機器上所安裝套件都已經包含 rsyslog、rsyslog-gnutls、rsyslog-openssl。

註冊網域服務並指令 A Record

請到你的 DNS 服務商註冊一個 A Record,例如所要使用的網域名稱為 test.gleetsai.dreamhosters.com,便在 A Record 上的 Host 填入 test,IP address 就參考 Linode 上所建立出來的 IP 位置填入,TTL 設定 30 秒即可。

在進入下一步前,使用 dig test.gleetsai.dreamhosters.com 確認設定已經生效。若在畫面上以下這句話,就代表已完成,可進行下一步。

 ;test.gleetsai.dreamhosters.com. IN A

在 Ubuntu 上安裝 Let's Encrypt 與 Certbot 服務

參考 https://certbot.eff.org/instructions?ws=other&os=ubuntu-18 安裝 Let's Encrypt 憑證服務,並利用 Certbot 申請憑證並在未來自動展延。

  1. snap install core; sudo snap refresh core
  2. snap install --classic certbot
  3. ln -s /snap/bin/certbot /usr/bin/certbot
  4. certbot certonly --standalone

在最後一個步驟,會要求填入資料以產生 TLS 憑證。完成後會看到憑證已放置在以下位置:

Certificate is saved at: /etc/letsencrypt/live/test.gleetsai.dreamhosters.com/fullchain.pem
Key is saved at: /etc/letsencrypt/live/test.gleetsai.dreamhosters.com/privkey.pem

上傳 CA 至 Ubuntu 伺服器

利用以下指令檢查拿到的 Let's Encrypt 憑證的 CA 單位。

openssl x509 -in /etc/letsencrypt/live/test.gleetsai.dreamhosters.com/fullchain.pem -text -noout

你會看到 O 資訊與 CN 資訊,例如以下的模樣:

 Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number:
 ...
 Signature Algorithm: sha256WithRSAEncryption
 Issuer: C = US, O = Let's Encrypt, CN = R3

以上面的示例,我所拿到憑證的 CA 單位就來自於 O = Let's Encrypt, CN = R3。跟著這個資訊,前往 https://letsencrypt.org/certificates/ 下載對應的 PEM 憑證,並把他放入到 /etc/letsencrypt/CA/ 位置底下。例如把 PEM 憑證下載後,使用 scp 指令從本地傳到 Ubuntu 伺服器上。

scp /Users/glee/Downloads/lets-encrypt-r3.pem root@test.gleetsai.dreamhosters.com:/etc/letsencrypt/CA/lets-encrypt-r3.pem

配置 RSyslog.conf 以啟用 TLS 服務

使用 vi /etc/rsyslog.conf 指令開始編輯相關參數。

改變 Log 傳輸上限

module(load="imuxsock"
 SysSock.RateLimit.Interval="60"
 SysSock.RateLimit.Burst="3000")

使用 OpenSSL 模組進行 TLS 連線,並設定驗證模式為匿名模式

module(load="imtcp"
 StreamDriver.Name="ossl"
 StreamDriver.Mode="1" # run driver in TLS-only mode
 StreamDriver.Authmode="anon"
)

指定憑證位置

把剛才上傳 CA 的路徑填入到 DefaultNetstreamDriverCAFile 欄位裡,並且填入已申請到的憑證 fullchain 完整路徑與 Privkey 路徑。

global(DefaultNetstreamDriver="ossl"
 DefaultNetstreamDriverCAFile="/etc/letsencrypt/CA/lets-encrypt-r3.pem"
 DefaultNetstreamDriverCertFile="/etc/letsencrypt/live/test.gleetsai.dreamhosters.com/fullchain.pem"
 DefaultNetstreamDriverKeyFile="/etc/letsencrypt/live/test.gleetsai.dreamhosters.com/privkey.pem"
 )

設定 TCP 通訊埠

input(type="imtcp"
 port="6514"
 )

設定收到的 Log 儲存位置

將收到的 Log 按照來源(Hostname)分門別類的整理,並依照 Log 所收到的日期開設資料夾。

$template RemoteHost,"/var/log/hosts/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%/syslog.log"
 *.* ?RemoteHost

設定發送對象安全名單

設定來自「所有位置」的人都可以對這個伺服器發送 Log 資訊。或是依照需求填入對方的 IP 以設定為安全名單。

$AllowedSender TCP, *

最終 RSyslog 配置參考

#  /etc/rsyslog.conf	Configuration file for rsyslog.
#
#			For more information see
#			/usr/share/doc/rsyslog-doc/html/rsyslog_conf.html
#
#  Default logging rules can be found in /etc/rsyslog.d/50-default.conf


#################
#### MODULES ####
#################

module(load="imuxsock"
SysSock.RateLimit.Interval="60"
SysSock.RateLimit.Burst="3000")

module(load="imtcp"
StreamDriver.Name="ossl"
StreamDriver.Mode="1" # run driver in TLS-only mode
StreamDriver.Authmode="anon"
)

global(DefaultNetstreamDriver="ossl"
DefaultNetstreamDriverCAFile="/etc/letsencrypt/CA/lets-encrypt-r3.pem"
DefaultNetstreamDriverCertFile="/etc/letsencrypt/live/test.gleetsai.dreamhosters.com/fullchain.pem"
DefaultNetstreamDriverKeyFile="/etc/letsencrypt/live/test.gleetsai.dreamhosters.com/privkey.pem"
)

# provides TCP syslog reception
input(type="imtcp"
port="6514"
)

$template RemoteHost,"/var/log/hosts/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%/syslog.log"
*.* ?RemoteHost

$AllowedSender TCP, *

###########################
#### GLOBAL DIRECTIVES ####
###########################

#
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# Filter duplicated messages
$RepeatedMsgReduction on

#
# Set the default permissions for all log files.
#
$FileOwner syslog
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
$PrivDropToUser syslog
$PrivDropToGroup syslog

#
# Where to place spool files
#
$WorkDirectory /var/spool/rsyslog

#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf

儲存並離開

最後按一下 ESC 鍵,並輸入 :wq! 強制儲存並離開。

重啟 RSyslog 服務

使用指令:systemctl restart rsyslog 重啟 RSyslog 服務後,再使用 systemctl status rsyslog 檢查服務是否有正常啟動。

驗證 RSyslog 是否有使用 TLS 連線

回到自己的 Mac 電腦,輸入以下指令:

openssl s_client -connect test.gleetsai.dreamhosters.com:6514 -tls1_2

你應該會看到完整的 Certificate Chain 範例如下:

Certificate chain
 0 s:/CN=test.gleetsai.dreamhosters.com
 i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
 i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 i:/O=Digital Signature Trust Co./CN=DST Root CA X3

Read more

Managed Preferences 到底贏不贏得過本機設定?自己寫工具測給自己看

Managed Preferences 到底贏不贏得過本機設定?自己寫工具測給自己看

在管理一批用 MDM 集中控管的 Mac 時,常常會遇到一個問題:某個 preference key,使用者自己用 defaults write 改過一次,管理員可能又用 sudo defaults write 在系統層級動過一次,最後 MDM 又把同一個 key 標成 Managed(強制)。這時候系統實際生效的到底是哪一個值? Apple 官方文件對 CFPreferencesAppValueIsForced 這支 API 的說明相當簡略,只告訴你這個 API 可以拿來判斷某個 key 是不是被強制,卻沒有把整個 preference 搜尋順序裡各層級的先後關係講清楚。網路上能找到的資訊也大多是憑印象轉述,沒有人真的擺出證據。 與其對著文件猜,不如自己寫一支工具,實際測給自己看。以下這篇的測試環境是 macOS Tahoe 26.6.

By Glee Tsai
Apple 生態系的真實威脅—我們都可能是目標

Apple 生態系的真實威脅—我們都可能是目標

從一場分享開始的警醒 前陣子在 Jamf Nation Live Taipei 分享了 2024-2025 年 Apple 裝置威脅報告,深入探討了全球 Apple 生態系正面臨的資訊安全威脅。 許多人對 Apple 產品有一種根深蒂固的信心—拿著 Mac 或 iPhone,就像拿到了數位世界的「免死金牌」。說實話,Apple 在軟硬體整合上的安全設計確實領先業界,這不是誇大其詞。但也正因為這份信心,我開始想更深入地了解真實情況。 從 Jamf Security 360 報告開始,我觀察了全球情報機構(如 Citizen Lab、Google TAG、Kaspersky)揭露的真實案例。那時我才意識到一個有點殘酷的事實,也正好對應了同事最常對我說的那句話:Apple 設備並非堅不可摧,使用者自身往往才是最大的弱點。 為什麼 Apple

By Glee Tsai

從 Jamf Pro 自定義註冊畫面帶使用者資訊至 Jamf Connect 失敗的處理方式

Jamf Pro 在設定裡面的 Enrollment Customization,本來可以設定在使用者完成設備註冊的當下,同步把 SAML 裡的資訊帶給後面的 Jamf Connect Login,這樣就可以減少一步使用者還需要登入的步驟。但在撰文的當下,Jamf Pro 11.1 仍在這個功能上有問題,在跟 Jamf Support Team 了解後,大概能用一種 Workaround 來解決,只是要特別留意以下事情: 1. 在 Jamf Pro 裡的 Enrollment Customization 不要再打勾 Enable Jamf Pro to pass user information to Jamf Connect 了(因為勾了也沒有用) 2. 確保

By Glee Tsai

在 Apple 零接觸部署下僅允許某個群組啟動設備

在 Jamf Pro 有整合 Single Sign On 的情況下,可以前往 Settings > Enrollment Customization 設定僅允許一個群組中的成員啟用設備。如果這個成員沒有在這個群組裡面的話,就不能夠開箱設備。如果以 Entra ID 為例,需要把 Object ID 填在下方的欄位即可。 對照到我在 Entra ID 上的群組設置: 至於如果不是 Entra ID,而是其它的 SSO Provider 的話,最好可以用 SAML Tracer 這一套 Google Chrome 外掛去看一下自己的 SAML 文件是如何表達群組的,例如下圖能看到這個使用者屬於以下五個群組。 接著有另外一個很重要的事情要提醒,如果你要阻擋註冊的成員,可以登入到 Jamf Pro

By Glee Tsai