Время на прочтение5 мин
Количество просмотров78K
Пользовательская рабочая станция — самое уязвимое место инфраструктуры по части информационной безопасности. Пользователям может прийти на рабочую почту письмо вроде бы из безопасного источника, но со ссылкой на заражённый сайт. Возможно, кто-то скачает полезную для работы утилиту из неизвестно какого места. Да можно придумать не один десяток кейсов, как через пользователей вредоносное ПО может внедриться на внутрикорпоративные ресурсы. Поэтому рабочие станции требуют повышенного внимания, и в статье мы расскажем, откуда и какие события брать для отслеживания атак.
Для выявления атаки на самой ранней стадии в ОС Windows есть три полезных событийных источника: журнал событий безопасности, журнал системного мониторинга и журналы Power Shell.
Журнал событий безопасности (Security Log)
Это главное место хранения системных логов безопасности. Сюда складываются события входа/выхода пользователей, доступа к объектам, изменения политик и других активностей, связанных с безопасностью. Разумеется, если настроена соответствующая политика.
Перебор пользователей и групп (события 4798 и 4799). Вредоносное ПО в самом начале атаки часто перебирает локальные учетные записи пользователей и локальные группы на рабочей станции, чтобы найти учетные данные для своих тёмных делишек. Эти события помогут обнаружить вредоносный код раньше, чем он двинется дальше и, используя собранные данные, распространится на другие системы.
Создание локальной учётной записи и изменения в локальных группах (события 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 и 5377). Атака может также начинаться, например, с добавления нового пользователя в группу локальных администраторов.
Попытки входа с локальной учётной записью (событие 4624). Добропорядочные пользователи заходят с доменной учётной записью и выявление входа под локальной учётной записью может означать начало атаки. Событие 4624 включает также входы под доменной учетной записью, поэтому при обработке событий нужно зафильтровать события, в которых домен отличается от имени рабочей станции.
Попытка входа с заданной учётной записью (событие 4648). Такое бывает, когда процесс выполняется в режиме “Запуск от имени” (run as). В нормальном режиме работы систем такого не должно быть, поэтому такие события должны находиться под контролем.
Блокировка/разблокировка рабочей станции (события 4800-4803). К категории подозрительных событий можно отнести любые действия, которые происходили на заблокированной рабочей станции.
Изменения конфигурации файрволла (события 4944-4958). Очевидно, что при установке нового ПО настройки конфигурации файрволла могут меняться, что вызовет ложные срабатывания. Контролировать такие изменения в большинстве случаев нет необходимости, но знать о них точно лишним не будет.
Подключение устройств Plug’n’play (событие 6416 и только для WIndows 10). За этим важно следить, если пользователи обычно не подключают новые устройства к рабочей станции, а тут вдруг раз — и подключили.
Windows включает в себя 9 категорий аудита и 50 субкатегорий для тонкой настройки. Минимальный набор субкатегорий, который стоит включить в настройках:
Logon/Logoff
- Logon;
- Logoff;
- Account Lockout;
- Other Logon/Logoff Events.
Account Management
- User Account Management;
- Security Group Management.
Policy Change
- Audit Policy Change;
- Authentication Policy Change;
- Authorization Policy Change.
Системный монитор (Sysmon)
Sysmon — встроенная в Windows утилита, которая умеет записывать события в системный журнал. Обычно требуется его устанавливать отдельно.
Эти же события можно в принципе найти в журнале безопасности (включив нужную политику аудита), но Sysmon даёт больше подробностей. Какие события можно забирать из Sysmon?
Создание процесса (ID события 1). Системный журнал событий безопасности тоже может сказать, когда запустился какой-нибудь *.exe и даже покажет его имя и путь запуска. Но в отличие от Sysmon не сможет показать хэш приложения. Злонамеренное ПО может называться даже безобидным notepad.exe, но именно хэш выведет его на чистую воду.
Сетевые подключения (ID события 3). Очевидно, что сетевых подключений много, и за всеми не уследить. Но важно учитывать, что Sysmon в отличие от того же Security Log умеет привязать сетевое подключение к полям ProcessID и ProcessGUID, показывает порт и IP-адреса источника и приёмника.
Изменения в системном реестре (ID события 12-14). Самый простой способ добавить себя в автозапуск — прописаться в реестре. Security Log это умеет, но Sysmon показывает, кто внёс изменения, когда, откуда, process ID и предыдущее значение ключа.
Создание файла (ID события 11). Sysmon, в отличие от Security Log, покажет не только расположение файла, но и его имя. Понятно, что за всем не уследишь, но можно же проводить аудит определённых директорий.
А теперь то, чего в политиках Security Log нет, но есть в Sysmon:
Изменение времени создания файла (ID события 2). Некоторое вредоносное ПО может подменять дату создания файла для его скрытия из отчётов с недавно созданными файлами.
Загрузка драйверов и динамических библиотек (ID событий 6-7). Отслеживание загрузки в память DLL и драйверов устройств, проверка цифровой подписи и её валидности.
Создание потока в выполняющемся процессе (ID события 8). Один из видов атаки, за которым тоже нужно следить.
События RawAccessRead (ID события 9). Операции чтения с диска при помощи “\\.\”. В абсолютном большинстве случаев такая активность должна считаться ненормальной.
Создание именованного файлового потока (ID события 15). Событие регистрируется, когда создается именованный файловый поток, который генерирует события с хэшем содержимого файла.
Создание named pipe и подключения (ID события 17-18). Отслеживание вредоносного кода, который коммуницирует с другими компонентами через named pipe.
Активность по WMI (ID события 19). Регистрация событий, которые генерируются при обращении к системе по протоколу WMI.
Для защиты самого Sysmon нужно отслеживать события с ID 4 (остановка и запуск Sysmon) и ID 16 (изменение конфигурации Sysmon).
Журналы Power Shell
Power Shell — мощный инструмент управления Windows-инфраструктурой, поэтому велики шансы, что атакующий выберет именно его. Для получения данных о событиях Power Shell можно использовать два источника: Windows PowerShell log и Microsoft-WindowsPowerShell / Operational log.
Windows PowerShell log
Загружен поставщик данных (ID события 600). Поставщики PowerShell — это программы, которые служат источником данных для PowerShell для просмотра и управления ими. Например, встроенными поставщиками могут быть переменные среды Windows или системный реестр. За появлением новых поставщиков нужно следить, чтобы вовремя выявить злонамеренную активность. Например, если видите, что среди поставщиков появился WSMan, значит был начат удаленный сеанс PowerShell.
Microsoft-WindowsPowerShell / Operational log (или MicrosoftWindows-PowerShellCore / Operational в PowerShell 6)
Журналирование модулей (ID события 4103). В событиях хранится информация о каждой выполненной команде и параметрах, с которыми она вызывалась.
Журналирование блокировки скриптов (ID события 4104). Журналирование блокировки скриптов показывает каждый выполненный блок кода PowerShell. Даже если злоумышленник попытается скрыть команду, этот тип события покажет фактически выполненную команду PowerShell. Ещё в этом типе события могут фиксироваться некоторые выполняемые низкоуровневые вызовы API, эти события обычно записывается как Verbose, но если подозрительная команда или сценарий используются в блоке кода, он будет зарегистрирован как c критичностью Warning.
Обратите внимание, что после настройки инструмента сбора и анализа этих событий потребуется дополнительное время на отладку для снижения количества ложных срабатываний.
Расскажите в комментариях, какие собираете логи для аудита информационной безопасности и какие инструменты для этого используете. Одно из наших направлений — решения для аудита событий информационной безопасности. Для решения задачи сбора и анализа логов можем предложить присмотреться к Quest InTrust, который умеет сжимать хранящиеся данные с коэффициентом 20:1, а один его установленный экземпляр способен обрабатывать до 60000 событий в секунду из 10000 источников.
When a network disconnect occurs, it can affect the functionality of various applications and services that rely on a stable network connection. By being aware of these disconnects, We can precisely identify where and when the issues are happening, which helps in narrowing down potential causes. This targeted approach allows for quicker and more effective resolution of problems, ensuring that the overall performance and reliability of network-dependent applications and services are maintained.
Whenever you see logs on your trading platform indicating a network disconnect, you should check if the network adapter of your server has been disconnected from the internet. This disconnection can cause your trading platform to lose communication with your broker’s server, leading your algorithm to fail in closing or opening trades.
If your server did not reboot (all applications are running), yet your trading platform logs show a network disconnect, you need to determine the cause of the disconnect. To do this, check the Event Viewer on your server. This will help you identify whether the disconnection was due to the server’s network losing internet connection or if it was an issue between your trading platform and your broker’s server.
To check for network disconnect, follow the steps below:
1
Open the Event Viewer by typing Event Viewer in the Windows search bar.
2
In the right pane, click on Create Custom View
3
In the Create Custom View dialog box, click to check the Warning and Information boxes.
4
Ensure that the By log is selected and then click the Event Logs drop down box and click to check the Windows Log and Applications and Services Logs boxes.
5
In the Event ID text box, enter 27 and 10000 separated by a comma then click the Ok button to save the custom view.
Event ID 27 in Windows Server 2022 typically pertains to a network-related issue, specifically to the network adapter. This event is logged when the network link is disconnected, meaning the network adapter has lost its connection to the network. This can occur for various reasons, including hardware issues, driver problems, or network configuration changes.
Event ID 10000 in Windows Server 2022 is typically associated with the DistributedCOM (DCOM) component. DCOM is a Microsoft technology that enables software components to communicate over a network. This event ID usually indicates a problem related to DCOM, such as permission issues, network connectivity problems, or other errors involving COM components.
6
You will get a prompt regarding memory and processor time, simply click the Yes button to proceed.
7
Enter a name for your custom view.
8
If there were no network disconnects or errors, logs won’t show any warnings.
On the other hand, if there were network disconnect, it will show warning.
9
Compare the dates between the event viewer and your trading platform.
If the dates between the warning shown in the Event Viewer matches the date shown in your trading platform’s Logs, that would mean that your platform’s disconnect was caused by network failure, while if the dates between Event Viewer and trading platform logs are not matching, the disconnect happened between your trading platform and your broker.
How to check network disconnection events in the Windows system event log
Если вы подозреваете, что встроенный Windows Defender Firewall блокирует некоторые сетевые подключений (от определенной программы или сервиса), плохим решением будет его полное отключение. Вместо этого вы можете включить логирование сетевого трафика, проходящего через брандмауэр, определить заблокированные используемые порты и/или IP адреса источника/назначения и создать корректное разрешающее правило.
В этой статье мы покажем, как включить логирование сетевых подключений в Windows Firewall и выполнить поиск по логам.
Настройка логирования Windows Firewall в текстовый файл
Содержание:
- Запись логов Windows Firewall в журнал событий Windows
Windows Defender Firewall позволяет записывать в лог файл как успешные так и заблокированные сетевые подключения. Логирование можно включить отдельно для каждого сетевого профиля (частная, общедоступная или доменная сеть). По умолчанию логирование трафика в брандмауэре отключено. Чтобы включить ведение логов в Windows Firewall:
- Откройте MMC оснастку Windows Firewall with Advanced Security (
wf.msc
). - Щелкните правой кнопкой по корню консоли и выберите Properties;
- Затем выберите вкладку сетевого профиля Windows, для которого вы хотите включить логирование (Domain, Private или Public Profile).
- На вкладке профиля в секции Logging нажмите кнопку Customize.
- Здесь можно изменить следующие настройки:
Файл лога: по умолчанию
%systemroot%\system32\LogFiles\Firewall\pfirewall.logМаксимальный размер лога: увеличьте с 4 Мб до 20 Мб (
20480
Кб)Log dropped packets: нужно ли записывать в лог отфильтрованные сетевые пакеты
Log successful connections: нужно ли логировать успешные сетевые подключения (может получиться очень большой лог)
Чтобы понять, какой сетевой профиль заблокировал или пропустил определенное сетевое подключение, можно писать лог файервола в отдельный файл для каждого профиля. Например:
-
%windir%\system32\logfiles\firewall\pfirewall_domain.log -
%windir%\system32\logfiles\firewall\pfirewall_private.log -
%windir%\system32\logfiles\firewall\pfirewall_public.log
Также можно включить эти же параметры логирования Windows Firewall с помощью PowerShell:
Set-NetFireWallProfile -Profile Public -LogBlocked True -LogMaxSize 20480 -LogFileName "%systemroot%\system32\LogFiles\Firewall\pfirewall.log" -Verbose
Вывести текущие настройки логирования брандмауэра для всех профилей:
Get-NetFirewallProfile| select Name, Enabled, Log*|ft
Теперь Windows Firewall будет записывать в лог файлы все сетевые подключения. Вы можете открыть файл лога вручную или выполнить поиск по нему с помощью PowerShell. Командлет Select-String совмещает в себе аналог grep и tail для Windows.
Например, следующая команда будет выводить в реальном времени на экран все отфильтрованные (DROP) сетевые подключения на порт TCP порт 445 (SMB):
Get-Content C:\Windows\System32\LogFiles\Firewall\pfirewall.log -wait | Select-String -pattern "DROP.*TCP.*445"
Используется такой формат лог файла:
date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path pid
Для анализа лог файлов файервола можно воспользоваться такой PowerShell функцией, которая представит лог в виде удобной графической таблицы Out-GridView:
function Get-WindowsFirewallLog {
param(
[parameter(Position=0,Mandatory=$false)]
[ValidateScript({Test-Path $_})]
[string]$LogFilePath = "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log"
)
$headerFields = @("date","time", "action","protocol","src-ip","dst-ip","src-port","dst-port","size", "tcpflags","tcpsyn", "tcpack","tcpwin","icmptype","icmpcode", "info","path")
$firewallLogs = Get-Content $LogFilePath | ConvertFrom-Csv -Header $headerFields -Delimiter ' '
$firewallLogs | Out-GridView
}
Get-WindowsFirewallLog
Запись логов Windows Firewall в журнал событий Windows
По сравнению с текстовыми файлам иногда более удобно записывать логи сетевых подключений Windows Firewall в журнал событий (Event Viewer). Для этого нужно включить политики аудита в локальной GPO:
- Откройте редактор локальной GPO (
gpedit.msc
) - Перейдите в раздел Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies — Local Group Policy Object -> Object Access
- Параметр Audit Filtering Platform Packet drop позволяет включить аудит заблокированных подключений Windows Firewall. Откройте настройки политики и активируйте опцию Failure.
- Audit Filtering Platform Connection позволяет логировать успешные подключения. Используется эта политика аудита довольно редко, т.к. в лог будет писаться очень много событий (потребуется увеличение размеров журнала Event Viewer)
- Обновите настройки локальной GPO командой
gpupdate /force
Такую политику аудита можно включить командой:
Auditpol /set /category:"System" /SubCategory:"Filtering Platform Packet Drop" /failure:enable
Вывести текущие настройки политика аудита Windows Firewall:
auditpol /get /subcategory:"Filtering Platform Packet Drop","Filtering Platform Connection"
Чтобы посмотреть события Windows Firewall, откройте Event Viewer (
eventvwr.msc
). Разверните Windows Logs -> Security. Включите фильтр событий по категории Filtering Platform Packet Drop.
В списке событий появится все сетевые подключения, заблокированные Windows Firewall. Такие события будут иметь Event ID 5152 (
The Windows Filtering Platform has blocked a packet
). В описании события можно получить сетевую информацию: номер протокола (TCP-6, UDP-17, ICMP-1), IP адрес и порт источника/приемника, направление (Inbound, Outbound), процесс (для исходящих подключений).
Для поиска и фильтрации событий Windows Firewall в Event Viewer можно использовать PowerShell командлет Get-WinEvent. Следующий PowerShell скрипт выполнит поиск всех заблокированных брандмауэром событий (попыток) подключений на порт 3388 и выведет таблицу с временем подключения и источником:
$destinationPort = "3388"
$filterXml = @"
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[System[(EventID=5152)]]
and
*[EventData[Data[@Name='DestPort'] and (Data='$destinationPort')]]
</Select>
</Query>
</QueryList>
"@
$FirewallLogs = @()
$events=Get-WinEvent -FilterXml $filterXml
foreach ($event in $events) {
$eventXml = [xml]$event.ToXml()
$SourceAddress = $eventXml.Event.EventData.Data | Where-Object { $_.Name -eq 'SourceAddress' } | Select-Object -ExpandProperty '#text'
$DestPort = $eventXml.Event.EventData.Data | Where-Object { $_.Name -eq 'DestPort' } | Select-Object -ExpandProperty '#text'
$FirewallLog = New-Object PSObject -Property @{
SourceAddress= $SourceAddress
Time=$event.TimeCreated
DestPort=$DestPort
}
$FirewallLogs += $FirewallLog
}
$FirewallLogs
Таким образом, включив логи брандмауэра вы можете детально инспектировать все отброшенные и разрешенные взодящие/исходящие сетевые соединения, найти ошибки в своих правилах Windows Firewall и создать корректные.
Распознавание голоса и речи на C#
UnmanagedCoder 05.05.2025
Интеграция голосового управления в приложения на C# стала намного доступнее благодаря развитию специализированных библиотек и API. При этом многие разработчики до сих пор считают голосовое управление. . .
Реализация своих итераторов в C++
NullReferenced 05.05.2025
Итераторы в C++ — это абстракция, которая связывает весь экосистему Стандартной Библиотеки Шаблонов (STL) в единое целое, позволяя алгоритмам работать с разнородными структурами данных без знания их. . .
Разработка собственного фреймворка для тестирования в C#
UnmanagedCoder 04.05.2025
C# довольно богат готовыми решениями – NUnit, xUnit, MSTest уже давно стали своеобразными динозаврами индустрии. Однако, как и любой динозавр, они не всегда могут протиснуться в узкие коридоры. . .
Распределенная трассировка в Java с помощью OpenTelemetry
Javaican 04.05.2025
Микросервисная архитектура стала краеугольным камнем современной разработки, но вместе с ней пришла и головная боль, знакомая многим — отслеживание прохождения запросов через лабиринт взаимосвязанных. . .
Шаблоны обнаружения сервисов в Kubernetes
Mr. Docker 04.05.2025
Современные Kubernetes-инфраструктуры сталкиваются с серьёзными вызовами. Развертывание в нескольких регионах и облаках одновременно, необходимость обеспечения низкой задержки для глобально. . .
Создаем SPA на C# и Blazor
stackOverflow 04.05.2025
Мир веб-разработки за последние десять лет претерпел коллосальные изменения. Переход от традиционных многостраничных сайтов к одностраничным приложениям (Single Page Applications, SPA) — это. . .
Реализация шаблонов проектирования GoF на C++
NullReferenced 04.05.2025
«Банда четырёх» (Gang of Four или GoF) — Эрих Гамма, Ричард Хелм, Ральф Джонсон и Джон Влиссидес — в 1994 году сформировали канон шаблонов, который выдержал проверку временем. И хотя C++ претерпел. . .
C# и сети: Сокеты, gRPC и SignalR
UnmanagedCoder 04.05.2025
Сетевые технологии не стоят на месте, а вместе с ними эволюционируют и инструменты разработки. В . NET появилось множество решений — от низкоуровневых сокетов, позволяющих управлять каждым байтом. . .
Создание микросервисов с Domain-Driven Design
ArchitectMsa 04.05.2025
Архитектура микросервисов за последние годы превратилась в мощный архитектурный подход, который позволяет разрабатывать гибкие, масштабируемые и устойчивые системы. А если добавить сюда ещё и. . .
Многопоточность в C++: Современные техники C++26
bytestream 04.05.2025
C++ долго жил по принципу «один поток — одна задача» — как старательный солдатик, выполняющий команды одну за другой. В то время, когда процессоры уже обзавелись несколькими ядрами, этот подход стал. . .
Загрузить PDF
Загрузить PDF
Возможно, вам нужно посмотреть активные сетевые соединения на компьютере под управлением Windows. Это можно сделать несколькими способами. Вы можете открыть Центр управления сетями и общим доступом или работать с утилитой командной строки «netstat» (network statistics – сетевая статистика), которая позволяет обнаруживать сетевые проблемы и сетевой трафик; пользоваться этой утилитой довольно легко.
-
-
-
-
В Центре управления сетями и общим доступом вы можете получить информацию о состоянии сети, типе сетевого соединения, активных соединениях и возможности подключиться к другим компьютерам.[1]
-
Значок зависит от типа вашего соединения. Например, если вы подключены к Ethernet-сети, то значок имеет вид Ethernet-кабеля со штекером, а если вы подключены к беспроводной сети, то значок выглядит как пять вертикальных столбцов.[2]
-
Откроется окно, в котором будет отображена подробная информация о вашем сетевом соединении.
Реклама
-
-
-
Откроется окно «Сетевые подключения», в котором отобразятся активные сетевые соединения.
-
Щелкните правой кнопкой мыши по интересующему вас сетевому подключению.
-
-
В этом окне вы можете просмотреть информацию о сетевом соединении. Для получения дополнительной информации нажмите «Сведения».[3]
Реклама
-
-
В результатах поиска щелкните по «cmd», чтобы открыть окно командной строки (в Windows Vista и поздних версиях).[4]
-
В этом окне вы будете вводить команду netstat. Команда вводится с различными опциями, самые популярные из которых приведены ниже.
-
Эта команда приведет к отображению списка активных TCP-соединений (TCP, transmission control protocol — протокол управления передачей), в котором имени физического компьютера соответствуют локальные адреса, а имени хоста – удаленные адреса. Также будет отображено состояние порта (в режиме ожидания, подключение установлено и так далее).[5]
-
Введите netstat -b, чтобы отобразить программы, использующие сетевые соединения. Эта команда приведет к отображению списка, который аналогичен выводимому командой netstast -a, но здесь также отобразятся программы, использующие соединения и порты.[6]
-
Эта команда приведет к отображению списка TCP-соединений, но вместо имен компьютеров или поставщиков услуг отобразятся реальные IP-адреса.[7]
-
, чтобы отобразить командные опции. Эта команда приведет к отображению списка всех опций команды netstat.[8]
-
Введя команду netstat, откроется список TCP/UCP-соединений с IP-адресами.
Реклама
-
-
Откроется окно с текстовой строкой.
-
-
В этом окне вы будете вводить команду netstat. Команда вводится с различными опциями, самые популярные из которых приведены ниже.
-
Эта команда приведет к отображению списка активных TCP-соединений (TCP, transmission control protocol — протокол управления передачей ), в котором имени физического компьютера соответствуют локальные адреса, а имени хоста – удаленные адреса. Также будет отображено состояние порта (в режиме ожидания, подключение установлено и так далее).[9]
-
Введите netstat -b, чтобы отобразить программы, использующие сетевые соединения. Эта команда приведет к отображению списка, который аналогичен выводимому командой netstast -a, но здесь также отобразятся программы, использующие соединения и порты.[10]
-
Эта команда приведет к отображению списка TCP-соединений, но вместо имен компьютеров или поставщиков услуг отобразятся реальные IP-адреса.[11]
-
, чтобы отобразить командные опции. Эта команда приведет к отображению списка всех опций команды netstat.[12]
-
Введя команду netstat, откроется список TCP/UCP-соединений с IP-адресами.
Реклама
Советы
- В качестве альтернативы на сайте SysInternals скачайте программу TCPView.
- Поэкспериментируйте с командами UNIX (упомянутая выше команда netstat также является командой UNIX). Эти команды можно найти в интернете при помощи поисковика.
- Имейте в виду, что в Linux команда netstat больше не поддерживается, поэтому вместо нее используйте команды ip –s или ss, или ip route.
Реклама
Об этой статье
Эту страницу просматривали 179 038 раз.