• infosec - это один из самых ламповых каналов по информационной безопасности, где говорят об истории ИТ, публикуют актуальные новости и пишут технический материал на разные темы:

- Что из себя представляет официально взломанный iPhone от Apple?
- Кому и для чего выдавалось разрешение на ношение сотового телефона?
- Бесплатные курсы для ИБ специалистов на различные темы;
- Бесплатный бот, который проверит файлы на предмет угроз более чем 70 антивирусами одновременно.

• Присоединяйся, у нас интересно: @it_secur

👋 Привет, админы!

Если у вас больше одного сервера, вручную выискивать 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 → Subscriptions → Create Subscription

- Тип: Collector initiated
- Event log: Security
- Filter: Id=4625;4624;4778
- Advanced: выбрать нужные LogonType, если хотите только RDP

3. Настраиваем GPO на клиентах:

В GPO для машин, откуда хотим собирать логи:

- Computer Configuration → Administrative Templates → Windows Components → Event Forwarding
- Configure target Subscription Manager
Значение: Server=https://COLLECTOR:5985/wsman/SubscriptionManager/WEC

- Включаем WinRM:

Enable-PSRemoting -Force

📊 После настройки Collector будет видеть все входы/неудачные попытки и прочие события в одном месте.

Можно дальше интегрировать:
- в SIEM (например, Wazuh, ELK, Sentinel)
- или просто логировать/оповещать через PowerShell скрипты

💬 А вы уже собираете логи централизованно? Или только на проде? Что используете — WEF, Syslog, Agent’ы?

👉 @win_sysadmin

🎯 Проверка доступности портов: nmap, netcat, telnet, nc

Иногда нужно быстро проверить, доступен ли нужный порт на удалённой машине. Вот шпаргалка по самым популярным способам:


🔹 TCP-порты

Netcat:

# Проверка конкретного порта
netcat domain.com 80

# Сканирование диапазона портов
netcat -z -v domain.com 1-1000

# Слушать порт 4444 на хосте
netcat -l 4444

# Проверка подключения к удалённому netcat
netcat domain.com 4444

NC (аналог Netcat):

nc -vt <ip> <port>

Telnet:

telnet <ip> <port>

Nmap:

# Проверка TCP-порта 25
nmap -p25 11.11.11.11

🔹 UDP-порты

Netcat:

netcat -u <host> <port>

NC:

nc -vu <ip> <port>

Nmap:

# Проверка UDP-порта 53
nmap -sU -p U:53 11.1.11.12

📌 Удобно сохранять в закладки — пригодится в любой момент.

👉 @sysadminof

Потерян и не найден: каталог в Linux и UNIX

В этой статье я попытался разобрать назначение и основные сценарии использования директории lost+found в Linux.

Если мы запустим fsck, команду проверки и восстановления файловой системы, она может найти фрагменты данных, на которые нет ссылок нигде в файловой системе. В частности, могут быть обнаружены данные, которые выглядят как полный файл, но не имеют имени в системе — индексный дескриптор без соответствующего имени файла. Они по-прежнему занимают место, но недоступны обычными способами, поэтому в корне файловой системы присутствует специальная директория lost+found, куда помещаются такие файлы.

Таким образом, рассматриваемый каталог служит временным хранилищем для тех редких случаев, когда fsck не может собрать все обратно после повреждения файловой системы.

При каких сценариях файлы могут оказаться там?

https://habr.com/ru/companies/timeweb/articles/789908/

👉 @sysadminof