Переадресация системы Windows Журналы событий на сервер Syslog Linux без агента
У нас есть сервер SCOM 2012.
У нас есть SNARE-агенты для соответствия PCI, но теперь мы хотим сэкономить, собирая все события для всех серверов Windows с использованием его собственных функций.
У нас также есть централизованный сервер Linux с запущенным SYSLOG, который объединяет журналы с нашим устройством хранения журналов (это все для целей PCI)
Итак, мой вопрос:
Может ли сервер Windows (SCOM 2012) пересылать журналы событий на сервер системного журнала Linux? Я предполагаю, что это произойдет, следуя стандартному плоскому формату файла или что-то подобное.
Спасибо
2 ответа
Вам необходимо использовать агент системного журнала, поскольку Windows не предоставляет его.
... ОС Windows не содержит агента системного журнала, который способен отправлять данные системного журнала на сервер системного журнала. Без агента системного журнала не только ОС Windows не может отправлять сообщения системного журнала на сервер системного журнала, но также не может отправлять сообщения системного журнала из любых приложений, работающих в ОС Windows (например, веб-сервер или база данных).
И эта исходная страница, и Googling для "агента системного журнала Windows" предоставляют множество различных агентов системного журнала, которые вы можете попробовать.
Вы можете попробовать NXLog на сервере Linux, чтобы получать собственные события WEF из Windows и пересылать их на сервер системного журнала, поскольку NXLog имеет версию сообщества. На данный момент у меня нет ресурсов, чтобы попробовать это. Если NXLog достаточно умен, чтобы преобразовать WEF в текст перед отправкой в системный журнал, тогда это может сработать, в противном случае он может распылять двоичный шум в системный журнал. Пожалуйста, сообщите, если это работает:
1. Настройте ВЭФ
[ https://adamtheautomator.com/windows-event-collector/ ]
- Создайте объект групповой политики через консоль управления групповой политикой. Внутри объекта групповой политики перейдите в раздел «Конфигурация компьютера» → «Политики» → «Административные шаблоны» → «Компоненты Windows» → «Пересылка событий» → «Настроить целевой менеджер подписок».
- Задайте для целевого диспетчера подписок значение конечной точки WinRM на сборщике. Вы установите Сервер в формате:
- Сервер =http://имя хоста:5985/wsman/SubscriptionManager/WEC,Refresh=60
2. Настройте NXLog:
(Конфигурация WEF для отправки в NXLog была скопирована отсюда , но см. мою конфигурацию внизу этого ответа SE, чтобы выполнить фактическую пересылку)
Создание и сопоставление пользователя домена Active Directory
Чтобы сервер WEC на компьютере Linux мог использовать проверку подлинности Kerberos, необходимо создать соответствующего пользователя в Active Directory и сопоставить его с основным именем Kerberos.
On the domain controller, create a new user with its logon name matching the hostname of the WEC server.
Go to Administrative Tools > Active Directory Users and Computers > example.com > Users.
Right click and choose New > User.
First name: linux-wec
Full name: linux-wec
User logon name: linux-wec
Set a password for the user.
Uncheck User must change password at next logon.
Check Password never expires.
Right click on the new user, click Properties, and open the Account tab.
Check This account supports Kerberos AES 128 bit encryption.
Check This account supports Kerberos AES 256 bit encryption.
On the DNS server, create an A record for linux-wec.example.com.
Go to Administrative Tools > DNS > Forward Lookup Zones > example.com.
Right click and choose New Host (A or AAAA)….
Add a record with name linux-wec and IP address 192.168.0.3.
Check the Create associated pointer (PTR) record option.
Back on the domain controller, open a command prompt and execute these commands. Use the same <password> that was specified when the above user was created. These commands map the domain account to the Kerberos principal names and generate two keytab files containing the shared secret.
> ktpass /princ hosts/linux-wec.example.com@EXAMPLE.COM /pass <password> /mapuser EXAMPLE\linux-wec -pType KRB5_NT_PRINCIPAL /out hosts-nxlog.keytab /crypto AES256-SHA1
> ktpass /princ http/linux-wec.example.com@EXAMPLE.COM /pass <password> /mapuser EXAMPLE\linux-wec -pType KRB5_NT_PRINCIPAL /out http-nxlog.keytab /crypto AES256-SHA1
Copy the resulting hosts-nxlog.keytab and http-nxlog.keytab files to the WEC server.
Настройка Kerberos на сервере WEC
Теперь, когда пользователь Active Directory создан и сопоставлен с именем участника, сервер WEC можно настроить для аутентификации Kerberos.
Confirm that the Kerberos krb5 client and utility software are installed on the WEC server. The required package can be installed with yum install krb5-workstation or apt install krb5-user.
Edit the default Kerberos configuration file, usually located at /etc/krb5.conf.
In section [domain_realm] add:
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
In section [realms] add:
EXAMPLE.COM = {
kdc = example.com
admin_server = example.com
}
Use ktutil to merge the two keytab files generated above.
# ktutil
ktutil: rkt /root/hosts-nxlog.keytab
ktutil: rkt /root/http-nxlog.keytab
ktutil: wkt /root/nxlog-result.keytab
ktutil: q
Validate the merged keytab.
# klist -e -k -t /root/nxlog-result.keytab
Keytab name: FILE:/root/nxlog-result.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
5 17.01.2021 04:20:08 hosts/linux-wec.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
4 17.01.2021 04:20:08 http/linux-wec.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
Either copy the keytab into place, or merge it if there are already keys in /etc/krb5.keytab.
To copy the keytab:
# cp /root/nxlog-result.keytab /etc/krb5.keytab
To merge the keytab and validate the result:
# ktutil
ktutil: rkt /etc/krb5.keytab
ktutil: rkt /root/nxlog-result.keytab
ktutil: wkt /etc/krb5.keytab
ktutil: q
# klist -e -k -t /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
<other entries>
5 17.01.2021 04:20:08 hosts/linux-wec.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
4 17.01.2021 04:20:08 http/linux-wec.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
Verify that the user account used by the NXLog service has sufficient privileges to open and read the /etc/krb5.keytab file. If not, Kerberos authentication will fail.
Test that the authentication with Active Directory is working successfully when using the keytab. Run the following command on the Linux WEC server. If the configuration is correct a ticket-granting ticket (TGT) will be created and cached. This command should be invoked with the same user that the NXLog service runs as. By default, it uses the nxlog user account.
# kinit -kt /etc/krb5.keytab http/linux-wec.example.com@EXAMPLE.COM
Verify the ticket was obtained by running klist as the same user from the previous step:
# klist
Ticket cache: KCM:0
Default principal: http/linux-wec.example.com@EXAMPLE.COM
Valid starting Expires Service principal
28/01/21 11:41:44 28/01/21 21:41:44 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 04/02/21 11:41:44
#3 Используйте эту конфигурацию NXLog для проксирования Windows в системный журнал:
# Recieve from native WEF:
<Input windows_events>
Module im_wseventing
Address https://linux-wec.example.com:5985/wsman
ListenAddr 0.0.0.0
Port 5985
HTTPSCertFile /path/to/server-cert.pem
HTTPSCertKeyFile /path/to/server-key.pem
HTTPSCAFile /path/to/ca-cert.pem
<QueryXML>
<QueryList>
<Query Id="0">
<Select Path="Application">*</Select>
<Select Path="Security">*</Select>
<Select Path="System">*</Select>
</Query>
</QueryList>
</QueryXML>
# Log connections for testing and troubleshooting
LogConnections TRUE
</Input>
# Send it to a syslog server:
<Output udp>
Module om_udp
Host 192.168.1.1:514
</Output>
# (or using the syntax prior to NXLog EE 5,
# where the port is defined in a separate directive.)
#<Output udp>
# Module om_udp
# Host 192.168.1.1
# Port 514
#</Output>
# Route WEF to UDP
<Route uds_to_udp>
Path im_wseventing => udp
</Route>