👋 Всем айтишный привет!
Недавно столкнулся с задачей: нужно было выключить группу компьютеров в конце дня, чтобы не гоняли лишнее электричество. Ручками заходить на каждый — удовольствие ниже среднего, поэтому сразу пошёл через PowerShell.
🔥 Вот скрипт, который пробегает по списку имен и выключает их удалённо:
✅ В файле
💡 Не забудь, чтобы всё сработало, на удалённых ПК должна быть включена служба WMI и разрешён доступ через брандмауэр. И конечно, запускай от имени администратора.
🧩 Можно дополнить проверкой доступности (ping) перед выключением — если нужно, покажу в следующем посте.
💬 А вы автоматизируете выключение машин в своей сети? Или всё вручную/через GPO? Поделитесь практикой — будет полезно!
👉 @win_sysadmin
Недавно столкнулся с задачей: нужно было выключить группу компьютеров в конце дня, чтобы не гоняли лишнее электричество. Ручками заходить на каждый — удовольствие ниже среднего, поэтому сразу пошёл через PowerShell.
🔥 Вот скрипт, который пробегает по списку имен и выключает их удалённо:
$computers = Get-Content "C:\Scripts\pc_list.txt"
foreach ($pc in $computers) {
try {
Write-Host "Выключаю $pc..." -ForegroundColor Yellow
Stop-Computer -ComputerName $pc -Force -ErrorAction Stop
Write-Host "$pc выключен." -ForegroundColor Green
} catch {
Write-Host "Не удалось выключить $pc: $_" -ForegroundColor Red
}
}
✅ В файле
pc_list.txt — просто список имен или IP адресов, по одному на строку. 💡 Не забудь, чтобы всё сработало, на удалённых ПК должна быть включена служба WMI и разрешён доступ через брандмауэр. И конечно, запускай от имени администратора.
🧩 Можно дополнить проверкой доступности (ping) перед выключением — если нужно, покажу в следующем посте.
💬 А вы автоматизируете выключение машин в своей сети? Или всё вручную/через GPO? Поделитесь практикой — будет полезно!
👉 @win_sysadmin
👍6🔥1
👋 Привет, админы!
Сегодня расскажу про простой, но очень полезный трюк, который помогает выявить подозрительные подключения к вашему Windows-серверу — особенно актуально, если сервер доступен извне.
🔥 Проверить активные входящие подключения можно командой:
А чтобы узнать, какой процесс стоит за каждым подключением, дополним это:
📌 Этот способ помогает быстро выявить:
- необычные подключения к RDP или кастомным портам;
- неизвестные процессы, которые “висят” в сети;
- потенциальный бэкдор или троян.
🧠 Совет: поставьте это на регулярный мониторинг через таск или скрипт с логом в файл.
💬 А вы мониторите сетевые подключения на проде? Используете PowerShell, Sysmon или что-то другое?
👉 @win_sysadmin
Сегодня расскажу про простой, но очень полезный трюк, который помогает выявить подозрительные подключения к вашему Windows-серверу — особенно актуально, если сервер доступен извне.
🔥 Проверить активные входящие подключения можно командой:
Get-NetTCPConnection -State Established | Where-Object { $_.RemoteAddress -ne '127.0.0.1' } |
Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess |
Sort-Object -Property RemoteAddress
А чтобы узнать, какой процесс стоит за каждым подключением, дополним это:
Get-NetTCPConnection -State Established |
Where-Object { $_.RemoteAddress -ne '127.0.0.1' } |
ForEach-Object {
$proc = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
[PSCustomObject]@{
RemoteAddress = $_.RemoteAddress
RemotePort = $_.RemotePort
LocalPort = $_.LocalPort
ProcessName = $proc.ProcessName
PID = $_.OwningProcess
}
} | Sort-Object RemoteAddress
📌 Этот способ помогает быстро выявить:
- необычные подключения к RDP или кастомным портам;
- неизвестные процессы, которые “висят” в сети;
- потенциальный бэкдор или троян.
🧠 Совет: поставьте это на регулярный мониторинг через таск или скрипт с логом в файл.
💬 А вы мониторите сетевые подключения на проде? Используете PowerShell, Sysmon или что-то другое?
👉 @win_sysadmin
👍6
👋 Привет, админы!
Иногда нужно быстро понять — кто и когда логинился на сервер или важную машину. Особенно если подозрения на взлом или кто-то заходит в неурочное время.
Вот простой PowerShell-скрипт, который вытащит логи входа в систему (
📌
📌 Можно заменить на
📌 Или убрать фильтр, чтобы увидеть всё.
Полезно для расследований, мониторинга активности админов, а ещё — если нужно зафиксировать "кто заходил ночью" 😅
💬 А вы ведёте аудит логинов? Через SIEM, syslog, журнал событий, или всё по-олдскулу?
👉 @win_sysadmin
Иногда нужно быстро понять — кто и когда логинился на сервер или важную машину. Особенно если подозрения на взлом или кто-то заходит в неурочное время.
Вот простой PowerShell-скрипт, который вытащит логи входа в систему (
Event ID 4624) из журнала безопасности:
Get-WinEvent -FilterHashtable @{
LogName = 'Security';
Id = 4624;
StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
$xml = [xml]$_.ToXml()
[PSCustomObject]@{
TimeCreated = $_.TimeCreated
AccountName = $xml.Event.EventData.Data | Where-Object {$_.Name -eq "TargetUserName"} | Select-Object -ExpandProperty '#text'
IPAddress = $xml.Event.EventData.Data | Where-Object {$_.Name -eq "IpAddress"} | Select-Object -ExpandProperty '#text'
LogonType = $xml.Event.EventData.Data | Where-Object {$_.Name -eq "LogonType"} | Select-Object -ExpandProperty '#text'
}
} | Where-Object { $_.AccountName -ne "ANONYMOUS LOGON" -and $_.LogonType -eq "10" } | Sort-Object TimeCreated
📌
LogonType = 10 — это удалённый интерактивный вход (RDP). 📌 Можно заменить на
2, если нужен локальный интерактивный логон. 📌 Или убрать фильтр, чтобы увидеть всё.
Полезно для расследований, мониторинга активности админов, а ещё — если нужно зафиксировать "кто заходил ночью" 😅
💬 А вы ведёте аудит логинов? Через SIEM, syslog, журнал событий, или всё по-олдскулу?
👉 @win_sysadmin
🔥6👍3
👋 Привет, админы!
Сегодня хочу поделиться небольшим, но полезным лайфхаком из практики — как быстро найти и перезапустить зависший сервис через PowerShell.
📌 Ситуация: сервис вроде как "работает", статус *Running*, но по факту не отвечает или не выполняет свои задачи. Такое бывает с агентами резервного копирования, антивирусами и даже SQL Server.
🔥 Вот скрипт, который мне помогает выявить такие "зомби-сервисы" и перезапустить их:
💡 Это особенно полезно на тех серверах, где нет стороннего мониторинга, а время реагирования критично.
💬 А у вас часто бывает, что сервис висит, но статус OK? Чем мониторите такие случаи — Task Scheduler, скрипты, Zabbix?
👉 @win_sysadmin
Сегодня хочу поделиться небольшим, но полезным лайфхаком из практики — как быстро найти и перезапустить зависший сервис через PowerShell.
📌 Ситуация: сервис вроде как "работает", статус *Running*, но по факту не отвечает или не выполняет свои задачи. Такое бывает с агентами резервного копирования, антивирусами и даже SQL Server.
🔥 Вот скрипт, который мне помогает выявить такие "зомби-сервисы" и перезапустить их:
$serviceName = "Имя_сервиса"
$svc = Get-Service -Name $serviceName
if ($svc.Status -eq "Running") {
$process = Get-WmiObject Win32_Service | Where-Object { $_.Name -eq $serviceName }
if ($process.ProcessId -ne 0) {
Write-Host "Сервис запущен с PID $($process.ProcessId). Перезапускаем..."
Restart-Service -Name $serviceName -Force
} else {
Write-Host "PID не найден. Возможна проблема – проверь вручную!"
}
} else {
Write-Host "Сервис не запущен. Статус: $($svc.Status)"
}
💡 Это особенно полезно на тех серверах, где нет стороннего мониторинга, а время реагирования критично.
💬 А у вас часто бывает, что сервис висит, но статус OK? Чем мониторите такие случаи — Task Scheduler, скрипты, Zabbix?
👉 @win_sysadmin
👍5🔥3
👋 Привет, админы!
Поймал недавно интересную ситуацию: нужно было автоматически проверять, включен ли у пользователей брандмауэр Windows, и если нет — включать. Звучит просто, но в доменной среде на 100+ машин — не до ручной проверки.
⚡ Вот скрипт, который я использовал через PowerShell Remoting и
💡 Полезно:
— Работает на всех профилях (
— Подходит для быстрого аудита
— Можно встроить в
🔐 P.S. Не забудьте убедиться, что WinRM открыт и включен на клиентах.
💬 А у вас как организована проверка и управление фаерволами? GPO? RMM? Или всё вручную? Делитесь опытом!
👉 @win_sysadmin
Поймал недавно интересную ситуацию: нужно было автоматически проверять, включен ли у пользователей брандмауэр Windows, и если нет — включать. Звучит просто, но в доменной среде на 100+ машин — не до ручной проверки.
⚡ Вот скрипт, который я использовал через PowerShell Remoting и
Invoke-Command. Проверяет состояние брандмауэра и включает его, если тот отключен:
$computers = Get-Content "C:\noscripts\computers.txt"
Invoke-Command -ComputerName $computers -ScriptBlock {
$profiles = Get-NetFirewallProfile
foreach ($profile in $profiles) {
if (-not $profile.Enabled) {
Write-Host "[$env:COMPUTERNAME] $($profile.Name) выключен — включаю..."
Set-NetFirewallProfile -Name $profile.Name -Enabled True
} else {
Write-Host "[$env:COMPUTERNAME] $($profile.Name) уже включен"
}
}
} -Credential (Get-Credential) -ErrorAction SilentlyContinue
💡 Полезно:
— Работает на всех профилях (
Domain, Private, Public) — Подходит для быстрого аудита
— Можно встроить в
Scheduled Task или GPO login noscript 🔐 P.S. Не забудьте убедиться, что WinRM открыт и включен на клиентах.
💬 А у вас как организована проверка и управление фаерволами? GPO? RMM? Или всё вручную? Делитесь опытом!
👉 @win_sysadmin
👍6
👋 Всем айтишный привет!
Недавно столкнулся с задачей: надо было массово проверить статус служб на нескольких серверах. Причём не просто глянуть, работают или нет, а убедиться, что определённые критически важные сервисы (типа
🛠️ Вот скрипт, который упростил мне жизнь:
🔥 Удобно, когда нужно быстро прогнать по десятку машин. Особенно помогает на продакшене, где простой службы — это потенциальный инцидент.
💬 А у вас есть свои заготовки для массовой проверки сервисов или состояния системы? Делитесь в комментах, обсудим!
👉 @win_sysadmin
Недавно столкнулся с задачей: надо было массово проверить статус служб на нескольких серверах. Причём не просто глянуть, работают или нет, а убедиться, что определённые критически важные сервисы (типа
w32time, WinRM, TermService) действительно в состоянии Running. 🛠️ Вот скрипт, который упростил мне жизнь:
$servers = @("server1", "server2", "server3")
$servicesToCheck = @("w32time", "WinRM", "TermService")
foreach ($server in $servers) {
Write-Host "🔍 Проверка $server" -ForegroundColor Cyan
foreach ($service in $servicesToCheck) {
$status = Get-Service -ComputerName $server -Name $service -ErrorAction SilentlyContinue
if ($status.Status -eq 'Running') {
Write-Host "$service: OK" -ForegroundColor Green
} else {
Write-Host "$service: НЕ РАБОТАЕТ!" -ForegroundColor Red
}
}
Write-Host ""
}
🔥 Удобно, когда нужно быстро прогнать по десятку машин. Особенно помогает на продакшене, где простой службы — это потенциальный инцидент.
💬 А у вас есть свои заготовки для массовой проверки сервисов или состояния системы? Делитесь в комментах, обсудим!
👉 @win_sysadmin
👍8
👋 Привет, админы!
Недавно нужно было срочно проверить, включен ли Secure Boot на парке серверов. BIOS GUI — зло, особенно когда всё удалённо. Решил всё сделать PowerShell’ем.
Вот скрипт, который поможет быстро определить статус Secure Boot на машине:
Если вернёт
🔒 Хочу напомнить, что Secure Boot — один из базовых элементов защиты от загрузки неподписанных (вредоносных) загрузчиков. Особенно актуально в среде, где есть автозагрузка ISO, PXE или кастомные live-образы.
📦 А чтобы прогнать это по сети — можно использовать PowerShell Remoting:
Либо через
💬 А у вас включен Secure Boot на проде? Или предпочитаете отключать из-за драйверов и кастомного софта? Делитесь опытом!
👉 @win_sysadmin
Недавно нужно было срочно проверить, включен ли Secure Boot на парке серверов. BIOS GUI — зло, особенно когда всё удалённо. Решил всё сделать PowerShell’ем.
Вот скрипт, который поможет быстро определить статус Secure Boot на машине:
Confirm-SecureBootUEFI
Если вернёт
True — Secure Boot активен. False — выключен. А если вылетает ошибка, значит либо UEFI не используется, либо железо/OS не поддерживают Secure Boot.🔒 Хочу напомнить, что Secure Boot — один из базовых элементов защиты от загрузки неподписанных (вредоносных) загрузчиков. Особенно актуально в среде, где есть автозагрузка ISO, PXE или кастомные live-образы.
📦 А чтобы прогнать это по сети — можно использовать PowerShell Remoting:
Invoke-Command -ComputerName SERVER01 -ScriptBlock { Confirm-SecureBootUEFI }
Либо через
Enter-PSSession, если хотите вручную посмотреть на конкретной машине.💬 А у вас включен Secure Boot на проде? Или предпочитаете отключать из-за драйверов и кастомного софта? Делитесь опытом!
👉 @win_sysadmin
👍7🔥1🌚1
👋 Всем айтишный привет!
Был недавно кейс: нужно настроить автологин для одного стендового сервера в изолированной сети — без домена, без пользователей, просто чтобы поднимался нужный софт после перезагрузки.
Решается это через редактирование реестра:
⚠️ Обратите внимание: пароль хранится в открытом виде в реестре (
🛡️ Есть ещё один способ — через
🔄 После внесения изменений — либо ребут, либо
💬 А используете ли вы автологин в каких-нибудь сценариях? Или строго по политике — никаких паролей в реестре?
👉 @win_sysadmin
Был недавно кейс: нужно настроить автологин для одного стендового сервера в изолированной сети — без домена, без пользователей, просто чтобы поднимался нужный софт после перезагрузки.
Решается это через редактирование реестра:
$RegPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
Set-ItemProperty -Path $RegPath -Name "AutoAdminLogon" -Value "1"
Set-ItemProperty -Path $RegPath -Name "DefaultUsername" -Value "UserName"
Set-ItemProperty -Path $RegPath -Name "DefaultPassword" -Value "UserPassword"
Set-ItemProperty -Path $RegPath -Name "DefaultDomainName" -Value "$env:COMPUTERNAME"
⚠️ Обратите внимание: пароль хранится в открытом виде в реестре (
DefaultPassword), поэтому использовать это стоит только в безопасной среде.🛡️ Есть ещё один способ — через
netplwiz, но он не автоматизируется скриптами. А если хотите чуть безопаснее — можно использовать специальные учетные записи без доступа к сети и минимальными правами.🔄 После внесения изменений — либо ребут, либо
shutdown /r /t 0 для применения.💬 А используете ли вы автологин в каких-нибудь сценариях? Или строго по политике — никаких паролей в реестре?
👉 @win_sysadmin
👍6🔥2
👋 Привет, админы!
Продолжаем тему автологина — только теперь наоборот. Сегодня покажу, как отключить автоматический вход в Windows, если его кто-то однажды настроил (и забыл).
🔧 Всё просто — правим те же ключи в реестре:
Если хотите полностью зачистить следы, можно ещё убрать
🎯 После этого автологин не будет срабатывать, и пользователь снова увидит окно входа.
👁️ Лайфхак: если нужно массово проверить, включен ли автологин на серверах, можно пробежаться скриптом по списку машин и вытащить
💬 А вы используете какие-нибудь средства для аудита автологина на серверах или рабочих станциях? Может быть, сканеры GPO, Defender for Endpoint, Intune?
👉 @win_sysadmin
Продолжаем тему автологина — только теперь наоборот. Сегодня покажу, как отключить автоматический вход в Windows, если его кто-то однажды настроил (и забыл).
🔧 Всё просто — правим те же ключи в реестре:
$RegPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
Set-ItemProperty -Path $RegPath -Name "AutoAdminLogon" -Value "0"
Remove-ItemProperty -Path $RegPath -Name "DefaultPassword" -ErrorAction SilentlyContinue
Если хотите полностью зачистить следы, можно ещё убрать
DefaultUsername и DefaultDomainName, особенно если вход теперь идёт по другим учеткам или через домен:
Remove-ItemProperty -Path $RegPath -Name "DefaultUsername" -ErrorAction SilentlyContinue
Remove-ItemProperty -Path $RegPath -Name "DefaultDomainName" -ErrorAction SilentlyContinue
🎯 После этого автологин не будет срабатывать, и пользователь снова увидит окно входа.
👁️ Лайфхак: если нужно массово проверить, включен ли автологин на серверах, можно пробежаться скриптом по списку машин и вытащить
AutoAdminLogon:
Invoke-Command -ComputerName (Get-Content servers.txt) -ScriptBlock {
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name "AutoAdminLogon"
}
💬 А вы используете какие-нибудь средства для аудита автологина на серверах или рабочих станциях? Может быть, сканеры GPO, Defender for Endpoint, Intune?
👉 @win_sysadmin
👍7🔥3
👋 Привет, админы!
Если вдруг замечаете странную активность по RDP — сессии отваливаются, логов много, сервер грузится — самое время проверить, кто брутфорсит.
Вот быстрый способ вытащить неудачные попытки входа по RDP через события:
📌 Покажет:
- когда была попытка
- откуда (IP)
- под каким логином пытались зайти
👮♂️ Можно быстро зафайрволить источник, добавить в blacklist или передать в SIEM.
🛡️ Плюс к этому — рекомендую включить защиту учётных записей от перебора пароля:
💬 А как вы отслеживаете попытки взлома по RDP? Вручную, через сторонние средства, или всё уже централизовано?
👉 @win_sysadmin
Если вдруг замечаете странную активность по RDP — сессии отваливаются, логов много, сервер грузится — самое время проверить, кто брутфорсит.
Вот быстрый способ вытащить неудачные попытки входа по RDP через события:
Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4625
} | Where-Object {
$_.Properties[10].Value -eq '10' # Logon Type 10 = RDP
} | Select-Object TimeCreated,
@{Name='Username';Expression={$_.Properties[5].Value}},
@{Name='IP';Expression={$_.Properties[18].Value}} |
Sort-Object TimeCreated -Descending | Select-Object -First 20
📌 Покажет:
- когда была попытка
- откуда (IP)
- под каким логином пытались зайти
👮♂️ Можно быстро зафайрволить источник, добавить в blacklist или передать в SIEM.
🛡️ Плюс к этому — рекомендую включить защиту учётных записей от перебора пароля:
net accounts /lockoutthreshold:5 /lockoutduration:15 /lockoutwindow:15
💬 А как вы отслеживаете попытки взлома по RDP? Вручную, через сторонние средства, или всё уже централизовано?
👉 @win_sysadmin
👍6🔥3👨💻2
👋 Привет, админы!
Сегодня — коротко и по делу: что включить в Audit Policy, чтобы отслеживать все подключения по RDP. Без нужных политик никакой логгер не поможет.
🎯 Включаем аудит входа и сетевых логинов:
📝 После этого в логе Security начнут появляться события:
-
-
-
-
📌 Также полезно включить аудит групповой политики:
💬 А вы централизуете такие события? Sysmon, WEF, SIEM, что в арсенале?
👉 @win_sysadmin
Сегодня — коротко и по делу: что включить в Audit Policy, чтобы отслеживать все подключения по RDP. Без нужных политик никакой логгер не поможет.
🎯 Включаем аудит входа и сетевых логинов:
AuditPol /set /subcategory:"Logon" /success:enable /failure:enable
AuditPol /set /subcategory:"Logoff" /success:enable
AuditPol /set /subcategory:"Special Logon" /success:enable
AuditPol /set /subcategory:"Logon with explicit credentials" /success:enable /failure:enable
📝 После этого в логе Security начнут появляться события:
-
4624 — Успешный вход (в том числе по RDP — Logon Type 10)-
4625 — Неудачный вход (ошибка пароля, нет такой учётки и т.п.)-
4634 — Выход из системы-
4778 и 4779 — Подключение и отключение от RDP-сессии📌 Также полезно включить аудит групповой политики:
AuditPol /set /subcategory:"Other Logon/Logoff Events" /success:enable /failure:enable
💬 А вы централизуете такие события? Sysmon, WEF, SIEM, что в арсенале?
👉 @win_sysadmin
👍9
👋 Привет, админы!
Если на сервер идёт брутфорс по RDP, лучше узнать об этом сразу — пока не увели учётку.
Рассказываю, как настроить оповещение о неудачных входах (4625) с Logon Type 10 (то есть RDP) через PowerShell +
📌 Сначала скрипт, который проверяет события и пишет лог/шлёт алерт:
⚙️ Потом создаём запланированное задание, чтобы скрипт запускался каждые 5 минут:
🛠️ Можно доработать под:
- Email-уведомления (
- Telegram-бота
- Интеграцию с Zabbix/PRTG/ELK
💬 А как вы реагируете на попытки брутфорса? Настраиваете уведомления или полагаетесь на внешние средства защиты?
👉 @win_sysadmin
Если на сервер идёт брутфорс по RDP, лучше узнать об этом сразу — пока не увели учётку.
Рассказываю, как настроить оповещение о неудачных входах (4625) с Logon Type 10 (то есть RDP) через PowerShell +
Scheduled Task. 📌 Сначала скрипт, который проверяет события и пишет лог/шлёт алерт:
# RDPBruteCheck.ps1
$Events = Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4625;
StartTime = (Get-Date).AddMinutes(-5)
} | Where-Object {
$_.Properties[10].Value -eq '10' # RDP Logon Type
}
if ($Events.Count -gt 0) {
$msg = "$($Events.Count) неудачных попыток входа по RDP за последние 5 минут!"
# Можно заменить на email, Telegram API, SIEM и т.п.
Add-Content -Path "C:\Scripts\RDPBruteLog.txt" -Value "$(Get-Date): $msg"
}
⚙️ Потом создаём запланированное задание, чтобы скрипт запускался каждые 5 минут:
$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-File C:\Scripts\RDPBruteCheck.ps1"
$trigger = New-ScheduledTaskTrigger -Once -At (Get-Date).AddMinutes(1) -RepetitionInterval (New-TimeSpan -Minutes 5) -RepetitionDuration ([TimeSpan]::MaxValue)
Register-ScheduledTask -TaskName "MonitorRDPBrute" -Action $action -Trigger $trigger -RunLevel Highest -User "SYSTEM"
🛠️ Можно доработать под:
- Email-уведомления (
Send-MailMessage)- Telegram-бота
- Интеграцию с Zabbix/PRTG/ELK
💬 А как вы реагируете на попытки брутфорса? Настраиваете уведомления или полагаетесь на внешние средства защиты?
👉 @win_sysadmin
👍3
👋 Привет, админы!
Если вы уже мониторите события 4625 (неудачные входы по RDP), следующий шаг — автоматическая блокировка IP-адресов, которые слишком активно пытаются попасть на сервер.
Вот скрипт, который парсит события и блокирует агрессивные IP:
📌 Что делает скрипт:
- Ищет за последние 15 минут события 4625 по RDP
- Вычисляет IP-адреса с 5+ неудачами
- Создаёт firewall-правило на блокировку
💡 Можно запустить по расписанию через
⚠️ Важно: не переусердствуйте — может прилететь блокировка легитимного VPN или админа. Лучше держать whitelist.
💬 А вы используете автоматические блокировки? Или предпочитаете fail2ban на edge-хостах/Linux-бастионках?
👉 @win_sysadmin
Если вы уже мониторите события 4625 (неудачные входы по RDP), следующий шаг — автоматическая блокировка IP-адресов, которые слишком активно пытаются попасть на сервер.
Вот скрипт, который парсит события и блокирует агрессивные IP:
# RDPBlockBadIPs.ps1
$events = Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4625;
StartTime = (Get-Date).AddMinutes(-15)
} | Where-Object {
$_.Properties[10].Value -eq '10' # Logon Type 10 = RDP
}
$badIPs = $events |
Group-Object { $_.Properties[18].Value } |
Where-Object { $_.Count -ge 5 } | # Порог блокировки
Select-Object -ExpandProperty Name
foreach ($ip in $badIPs) {
if ($ip -and ($ip -match '\d+\.\d+\.\d+\.\d+')) {
Write-Host "Блокирую IP: $ip"
New-NetFirewallRule -DisplayName "Block RDP Brute $ip" `
-Direction Inbound `
-RemoteAddress $ip `
-Action Block `
-Protocol TCP `
-LocalPort 3389 `
-Profile Any
}
}
📌 Что делает скрипт:
- Ищет за последние 15 минут события 4625 по RDP
- Вычисляет IP-адреса с 5+ неудачами
- Создаёт firewall-правило на блокировку
💡 Можно запустить по расписанию через
Scheduled Task, как в предыдущем посте. А если хочется очистку — можно добавить автоудаление блоков по TTL.⚠️ Важно: не переусердствуйте — может прилететь блокировка легитимного VPN или админа. Лучше держать whitelist.
💬 А вы используете автоматические блокировки? Или предпочитаете fail2ban на edge-хостах/Linux-бастионках?
👉 @win_sysadmin
👍5❤2
👋 Привет, админы!
Если у вас больше одного сервера, вручную выискивать RDP-брутфорс или другие попытки взлома — гиблое дело. Нам нужен централизованный сбор логов, особенно событий типа 4625, 4624, 4778 и т.п.
🎯 Есть несколько вариантов. Сегодня покажу один из самых доступных:
Windows Event Forwarding (WEF) + Event Collector.
📌 Как это работает:
- Сервер выступает как Collector (принимает логи)
- Клиенты (другие Windows-машины) — подписчики
- Всё через встроенный WinRM и GPO
🛠️ Настройка WEF в 3 шага
1. Включаем службу на Collector’е:
Это создаст необходимую подписку и включит службу Windows Event Collector.
2. Создаём подписку:
- Тип: Collector initiated
- Event log: Security
- Filter: Id=4625;4624;4778
- Advanced: выбрать нужные
3. Настраиваем GPO на клиентах:
В GPO для машин, откуда хотим собирать логи:
-
- Configure target Subnoscription Manager
Значение:
- Включаем WinRM:
📊 После настройки Collector будет видеть все входы/неудачные попытки и прочие события в одном месте.
Можно дальше интегрировать:
- в SIEM (например, Wazuh, ELK, Sentinel)
- или просто логировать/оповещать через PowerShell скрипты
💬 А вы уже собираете логи централизованно? Или только на проде? Что используете — WEF, Syslog, Agent’ы?
👉 @win_sysadmin
Если у вас больше одного сервера, вручную выискивать RDP-брутфорс или другие попытки взлома — гиблое дело. Нам нужен централизованный сбор логов, особенно событий типа 4625, 4624, 4778 и т.п.
🎯 Есть несколько вариантов. Сегодня покажу один из самых доступных:
Windows Event Forwarding (WEF) + Event Collector.
📌 Как это работает:
- Сервер выступает как Collector (принимает логи)
- Клиенты (другие Windows-машины) — подписчики
- Всё через встроенный WinRM и GPO
🛠️ Настройка WEF в 3 шага
1. Включаем службу на Collector’е:
wecutil qc
Это создаст необходимую подписку и включит службу Windows Event Collector.
2. Создаём подписку:
# Открыть Event Viewer → Subnoscriptions → Create Subnoscription
- Тип: Collector initiated
- Event log: Security
- Filter: Id=4625;4624;4778
- Advanced: выбрать нужные
LogonType, если хотите только RDP3. Настраиваем GPO на клиентах:
В GPO для машин, откуда хотим собирать логи:
-
Computer Configuration → Administrative Templates → Windows Components → Event Forwarding- Configure target Subnoscription Manager
Значение:
Server=http://COLLECTOR:5985/wsman/SubnoscriptionManager/WEC- Включаем WinRM:
Enable-PSRemoting -Force
📊 После настройки Collector будет видеть все входы/неудачные попытки и прочие события в одном месте.
Можно дальше интегрировать:
- в SIEM (например, Wazuh, ELK, Sentinel)
- или просто логировать/оповещать через PowerShell скрипты
💬 А вы уже собираете логи централизованно? Или только на проде? Что используете — WEF, Syslog, Agent’ы?
👉 @win_sysadmin
👍5
👋 Привет, админы!
Если вы уже используете Wazuh (open-source SIEM), то грех не настроить сбор событий безопасности с Windows, особенно для анализа логинов и брутфорса по RDP.
Вот как это делается 👇
🛠️ Установка Wazuh Agent на Windows
1. Скачиваем агент отсюда: https://wazuh.com/
2. Устанавливаем с указанием менеджера (сервер Wazuh):
3. После установки — правим
4. Перезапускаем агент:
📋 Что собирает агент?
По умолчанию:
- События из Security, System, Application
- Входы в систему (
- Изменения в учётках, политиках, реестре
- Информация об установке/удалении софта
🎯 Всё это попадает в дашборд Wazuh и может быть обработано правилами: алерты, уведомления, триггеры.
🔥 Пример алерта в Wazuh при брутфорсе по RDP:
📌 Это можно отправить на почту, в Telegram, или автоматизировать блокировку IP (например, через Active Responses).
💬 А вы уже пробовали Wazuh или у вас другая SIEM-система? Сравнивали с Graylog, Splunk, Sentinel?
👉 @win_sysadmin
Если вы уже используете Wazuh (open-source SIEM), то грех не настроить сбор событий безопасности с Windows, особенно для анализа логинов и брутфорса по RDP.
Вот как это делается 👇
🛠️ Установка Wazuh Agent на Windows
1. Скачиваем агент отсюда: https://wazuh.com/
2. Устанавливаем с указанием менеджера (сервер Wazuh):
msiexec /i "wazuh-agent-4.x.x.msi" /qn WAZUH_MANAGER="10.0.0.1" WAZUH_REGISTRATION_SERVER="10.0.0.1" WAZUH_AGENT_NAME="srv-win01"
3. После установки — правим
C:\Program Files (x86)\ossec-agent\ossec.conf (если надо вручную задать имя, группы и т.п.)4. Перезапускаем агент:
net stop wazuh-agent
net start wazuh-agent
📋 Что собирает агент?
По умолчанию:
- События из Security, System, Application
- Входы в систему (
4624, 4625, 4778, 4779)- Изменения в учётках, политиках, реестре
- Информация об установке/удалении софта
🎯 Всё это попадает в дашборд Wazuh и может быть обработано правилами: алерты, уведомления, триггеры.
🔥 Пример алерта в Wazuh при брутфорсе по RDP:
{
"rule": {
"id": "18107",
"level": 10,
"denoscription": "Windows RDP brute-force attempt detected",
"group": "windows, authentication_failed, brute_force"
},
"srcip": "192.168.1.200",
"user": "admin",
"location": "Security",
"full_log": "Logon failure: Type 10 (RemoteInteractive)"
}
📌 Это можно отправить на почту, в Telegram, или автоматизировать блокировку IP (например, через Active Responses).
💬 А вы уже пробовали Wazuh или у вас другая SIEM-система? Сравнивали с Graylog, Splunk, Sentinel?
👉 @win_sysadmin
👍7
👋 Привет, админы!
Когда ты видишь сотни логов с событиями 4625 и 4624 — хочется увидеть общую картину, а не ковыряться в логах.
🎯 Решение — визуализация в Grafana, подключённой к Elasticsearch, который использует Wazuh.
🛠️ Что тебе нужно:
✅ Рабочая инсталляция Wazuh с Elasticsearch
✅ Установленная Grafana
✅ Wazuh index (обычно
📊 Пример панели: RDP Logon Failures (Event ID 4625)
Создай визуализацию с такими настройками:
- Query:
- Metric: Count
- Group by:
-
-
-
📌 Это даст тебе:
- Топ IP-адресов, которые ломятся по RDP
- Частоту атак по времени
- Учетки, на которые идёт перебор
📈 Дополнительно:
- Успешные входы (4624) — для сравнения
- RDP session start (4778) и end (4779) — активность пользователей
- GeoIP — можно прикрутить GeoIP-плагин в Elasticsearch и рисовать карту атакующих
🔒 Бонус: Threshold + Alerting
Если за последние 10 минут по одному IP > 10 ошибок входа — можно задать алерт в Grafana и слать в Telegram, Discord, email, webhook.
💬 А вы визуализируете логи безопасности или только хардкор логами и текстами? Что используете — Grafana, Kibana, Zabbix?
👉 @win_sysadmin
Когда ты видишь сотни логов с событиями 4625 и 4624 — хочется увидеть общую картину, а не ковыряться в логах.
🎯 Решение — визуализация в Grafana, подключённой к Elasticsearch, который использует Wazuh.
🛠️ Что тебе нужно:
✅ Рабочая инсталляция Wazuh с Elasticsearch
✅ Установленная Grafana
✅ Wazuh index (обычно
wazuh-alerts-*) подключен как источник данных в Grafana 📊 Пример панели: RDP Logon Failures (Event ID 4625)
Создай визуализацию с такими настройками:
- Query:
data.win.system.eventID:4625 AND data.win.event_data.LogonType:"10" - Metric: Count
- Group by:
-
data.win.event_data.IpAddress.keyword — по IP-
data.win.event_data.TargetUserName.keyword — по пользователю-
@timestamp — по времени (в Histogram)📌 Это даст тебе:
- Топ IP-адресов, которые ломятся по RDP
- Частоту атак по времени
- Учетки, на которые идёт перебор
📈 Дополнительно:
- Успешные входы (4624) — для сравнения
- RDP session start (4778) и end (4779) — активность пользователей
- GeoIP — можно прикрутить GeoIP-плагин в Elasticsearch и рисовать карту атакующих
🔒 Бонус: Threshold + Alerting
Если за последние 10 минут по одному IP > 10 ошибок входа — можно задать алерт в Grafana и слать в Telegram, Discord, email, webhook.
💬 А вы визуализируете логи безопасности или только хардкор логами и текстами? Что используете — Grafana, Kibana, Zabbix?
👉 @win_sysadmin
🔥3👍1
👋 Привет, админы!
На днях столкнулся с интересной ситуацией: служба
Оказалось, что виноват битый файл базы данных обновлений. Решение оказалось простым, но мало кто его делает вручную:
🔥 Вот PowerShell-скрипт, который полностью сбрасывает Windows Update, включая очистку базы данных:
После этого сервер спокойно начал тянуть апдейты. Главное — не забудьте перезапустить сервисы, а лучше сразу проверить доступность обновлений:
(если стоит
🧠 Бонус: если хотите автоматизировать это на нескольких машинах — добавьте
💬 А как вы чините неработающий Windows Update? Используете
👉 @win_sysadmin
На днях столкнулся с интересной ситуацией: служба
Windows Update на одном из серверов Windows Server 2019 просто отказалась стартовать. Перезапуск, reset компонентов — ничего не помогло. Оказалось, что виноват битый файл базы данных обновлений. Решение оказалось простым, но мало кто его делает вручную:
🔥 Вот PowerShell-скрипт, который полностью сбрасывает Windows Update, включая очистку базы данных:
Stop-Service -Name wuauserv -Force
Stop-Service -Name bits -Force
Remove-Item -Path "C:\Windows\SoftwareDistribution" -Recurse -Force
Start-Service -Name wuauserv
Start-Service -Name bits
После этого сервер спокойно начал тянуть апдейты. Главное — не забудьте перезапустить сервисы, а лучше сразу проверить доступность обновлений:
Get-WindowsUpdate
(если стоит
PSWindowsUpdate модуль)🧠 Бонус: если хотите автоматизировать это на нескольких машинах — добавьте
Invoke-Command и в путь!💬 А как вы чините неработающий Windows Update? Используете
sfc, DISM, что-то своё? Расскажите в комментариях, будет полезно коллегам!👉 @win_sysadmin
👍8
👋 Привет, админы!
Сегодня делюсь историей, которая напомнила, насколько важно внимательно читать логи (да-да, даже если их много и лень).
🧩 Проблема: Windows Server 2019 перестал обновляться. Центр обновлений выдавал код ошибки
🔍 Разбор:
Этот код часто указывает на битые или несовместимые компоненты в хранилище компонентов Windows (WinSxS). Сам
Вернул: "Повреждение обнаружено". Тогда:
Процесс шёл долго, но в итоге ошибка осталась. Копнул глубже и выяснилось: проблема в том, что удалены нужные языковые пакеты, которые почему-то требуются при установке обновлений.
💡 Решение:
Переустановил нужный языковой пакет (в моем случае —
📌 Вывод: если видите
- целостность хранилища через
- наличие нужных языков (
- и не удалили ли вы что-то "ненужное" раньше для очистки WinSxS.
💬 А у вас были грабли с
👉 @win_sysadmin
Сегодня делюсь историей, которая напомнила, насколько важно внимательно читать логи (да-да, даже если их много и лень).
🧩 Проблема: Windows Server 2019 перестал обновляться. Центр обновлений выдавал код ошибки
0x800f0988. Вроде ничего критичного, но руководство требует, чтобы всё было "зелёным" в отчётах.🔍 Разбор:
Этот код часто указывает на битые или несовместимые компоненты в хранилище компонентов Windows (WinSxS). Сам
sfc /scannow ничего не нашёл. А вот DISM подсказал:
DISM /Online /Cleanup-Image /CheckHealth
Вернул: "Повреждение обнаружено". Тогда:
DISM /Online /Cleanup-Image /RestoreHealth
Процесс шёл долго, но в итоге ошибка осталась. Копнул глубже и выяснилось: проблема в том, что удалены нужные языковые пакеты, которые почему-то требуются при установке обновлений.
💡 Решение:
Переустановил нужный языковой пакет (в моем случае —
en-US), перезапустил RestoreHealth, после чего обновления пошли как по маслу.
Install-Language en-US
📌 Вывод: если видите
0x800f0988, проверьте:- целостность хранилища через
DISM,- наличие нужных языков (
Get-WinUserLanguageList),- и не удалили ли вы что-то "ненужное" раньше для очистки WinSxS.
💬 А у вас были грабли с
DISM и Windows Update? Делитесь в комментах, интересно собрать коллекцию ошибок 😊👉 @win_sysadmin
👍6
👋 Привет, админы!
Недавно прилетел тикет: "Пользователь не может поменять пароль — ошибка 0x80070056". Если кто не в курсе, это значит "The specified network password is not correct", и возникает она... когда всё вроде бы ОК 🤯
🛠️ В моём случае виновником оказался кэш старого пароля в Credential Manager. Пользователь менял пароль, но RDP-сессия, Outlook и прочее продолжали пытаться авторизоваться по старому — получался конфликт.
📌 Решение:
1. Открыл
2. Удалил все записи, связанные с этим аккаунтом.
3. Перезапустил сеанс — пароль сменился без проблем.
💡 Полезная PowerShell-команда, чтобы напомнить пользователям об этом автоматом (например, при смене пароля):
Иногда простые вещи — самые коварные. Не забывайте про этот момент, особенно если юзеры работают через RDP или VPN.
💬 А у вас часто бывает такое? Может, автоматизировали чистку кэша или используете GPO для этого?
👉 @win_sysadmin
Недавно прилетел тикет: "Пользователь не может поменять пароль — ошибка 0x80070056". Если кто не в курсе, это значит "The specified network password is not correct", и возникает она... когда всё вроде бы ОК 🤯
🛠️ В моём случае виновником оказался кэш старого пароля в Credential Manager. Пользователь менял пароль, но RDP-сессия, Outlook и прочее продолжали пытаться авторизоваться по старому — получался конфликт.
📌 Решение:
1. Открыл
Credential Manager (Панель управления → Учетные данные).2. Удалил все записи, связанные с этим аккаунтом.
3. Перезапустил сеанс — пароль сменился без проблем.
💡 Полезная PowerShell-команда, чтобы напомнить пользователям об этом автоматом (например, при смене пароля):
msg * "Если возникли проблемы после смены пароля — проверьте Credential Manager на старые записи!"
Иногда простые вещи — самые коварные. Не забывайте про этот момент, особенно если юзеры работают через RDP или VPN.
💬 А у вас часто бывает такое? Может, автоматизировали чистку кэша или используете GPO для этого?
👉 @win_sysadmin
👍4
👋 Привет, админы!
Был у меня недавно кейс: нужно было срочно проверить, кто и когда перезагружал сервер. Вроде бы задача простая, но в спешке иногда забываешь точные команды. Делюсь, чтобы не искать в следующий раз:
🕵️♂️ Ловим события перезагрузки через журнал:
Этот запрос покажет, кто инициировал перезагрузку, с какой причиной и когда это было. Очень полезно при разборе неожиданных рестартов или плановых работ, которые никто "не помнит".
✅ Дополнительно можно глянуть системные события ID
🔥 Удобно добавлять эти команды в свой набор “быстрых админских команд”.
💬 А вы ведёте собственный набор таких команд? Может, пора сделать свой PowerShell toolbox?
👉 @win_sysadmin
Был у меня недавно кейс: нужно было срочно проверить, кто и когда перезагружал сервер. Вроде бы задача простая, но в спешке иногда забываешь точные команды. Делюсь, чтобы не искать в следующий раз:
🕵️♂️ Ловим события перезагрузки через журнал:
Get-EventLog -LogName System -Source User32 | Where-Object { $_.EventID -eq 1074 } | Select TimeGenerated, Message | Sort-Object TimeGenerated -Descending
Этот запрос покажет, кто инициировал перезагрузку, с какой причиной и когда это было. Очень полезно при разборе неожиданных рестартов или плановых работ, которые никто "не помнит".
✅ Дополнительно можно глянуть системные события ID
6006 (нормальное выключение) и 6005 (загрузка журнала, т.е. запуск системы):
Get-EventLog -LogName System | Where-Object { $_.EventID -eq 6006 -or $_.EventID -eq 6005 } | Select TimeGenerated, EventID | Sort-Object TimeGenerated -Descending
🔥 Удобно добавлять эти команды в свой набор “быстрых админских команд”.
💬 А вы ведёте собственный набор таких команд? Может, пора сделать свой PowerShell toolbox?
👉 @win_sysadmin
👍11🔥1
👋 Привет, админы!
Недавно попался кейс на проде: скрипты, запускаемые через планировщик задач, начали зависать без ошибок. Вручную всё работало идеально. Начал копать — оказалось, дело в окружении задачи, которое отличается от интерактивной сессии.
Чтобы быстрее дебажить такие ситуации, я добавил в скрипт логирование переменных окружения и директории запуска. Вот минимальный шаблон, который теперь всегда кладу в начало таких задач:
🔥 Благодаря этому сразу видно, под кем и откуда запускается задача. Часто проблема оказывается в банальной нехватке прав или в том, что планировщик стартует скрипт из
💬 А у вас были случаи, когда скрипт в Task Scheduler вел себя не так, как вручную? Как отлавливаете такие баги? Делитесь своим опытом!
👉 @win_sysadmin
Недавно попался кейс на проде: скрипты, запускаемые через планировщик задач, начали зависать без ошибок. Вручную всё работало идеально. Начал копать — оказалось, дело в окружении задачи, которое отличается от интерактивной сессии.
Чтобы быстрее дебажить такие ситуации, я добавил в скрипт логирование переменных окружения и директории запуска. Вот минимальный шаблон, который теперь всегда кладу в начало таких задач:
$log = "C:\Logs\startup-debug-$(Get-Date -Format 'yyyyMMdd-HHmmss').log"
@"
Start Time: $(Get-Date)
User: $env:USERNAME
Computer: $env:COMPUTERNAME
WorkingDir: $(Get-Location)
ScriptPath: $PSCommandPath
ENV_VARS:
$(Get-ChildItem env: | Out-String)
"@ | Out-File -FilePath $log -Encoding UTF8
🔥 Благодаря этому сразу видно, под кем и откуда запускается задача. Часто проблема оказывается в банальной нехватке прав или в том, что планировщик стартует скрипт из
C:\Windows\System32, а не откуда мы ожидали. 💬 А у вас были случаи, когда скрипт в Task Scheduler вел себя не так, как вручную? Как отлавливаете такие баги? Делитесь своим опытом!
👉 @win_sysadmin
👍6🔥1