Admin Future
239 subscribers
50 photos
1 video
4 files
87 links
Превращаем эникейщиков в System Architects.
🚀 Твой навигатор в мире IT-инфраструктуры:

▪️ Hard Skills: Linux, Windows, Network, Security
▪️ Tools: Лучший софт и скрытые фишки
▪️ Mindset: Как думать, чтобы платили много


Админ - @maksimshap
Download Telegram
🕸 PowerShell: Забудь про nslookup

Мы по привычке пишем nslookup, когда падает DNS. Но эта утилита — наследие старых времен, она возвращает текст, который трудно парсить.

В PowerShell есть родной инструмент архитектора: Resolve-DnsName.

В чем сила? Он возвращает объекты.

Примеры:

Базовый запрос (лучше чем ping):

Resolve-DnsName google.com

Получить только IP (для скриптов):

(Resolve-DnsName google.com).IPAddress

Проверка конкретного DNS-сервера (например, 8.8.8.8):

Resolve-DnsName -Name adminfuture.com -Server 8.8.8.8

Проверка TXT записей (SPF/DMARC): Это боль в nslookup, но кайф здесь:

Resolve-DnsName -Name google.com -Type TXT

💡 Совет: Добавьте алиас в профиль, если привыкли к короткому имени: Set-Alias -Name dns -Value Resolve-DnsName

#windows #powershell #dns #network #команды
🏗 Архитектура: Как НЕ нужно называть домен Active Directory

Вы поднимаете новый контроллер домена. Рука тянется написать company.local? Остановитесь. Имя домена AD выбирается один раз, а последствия вы будете разгребать годами. Миграция/переименование домена — это ад, которого лучше избежать на старте.

Вот 3 главные ошибки и одно правильное решение.


Ошибка 1: Зона .local (company.local) Классика 2000-х, которая в 2025 году стала проблемой.

Почему плохо: Конфликтует с протоколом mDNS (Bonjour), который используют macOS, Linux и IoT-устройства для поиска соседей.

Последствия: Глюки при подключении маков, принтеров и Linux-серверов. Плюс — вы никогда не купите доверенный SSL-сертификат для .local.

Ошибка 2: Совпадение с публичным сайтом (company.ru) Называете AD так же, как ваш внешний сайт.

Почему плохо: Привет, Split-Brain DNS. Контроллеры домена считают, что company.ru — это они.

Последствия: Юзеры внутри офиса вводят company.ru, чтобы попасть на сайт фирмы, а попадают на страницу входа IIS контроллера домена (или получают ошибку). Приходится костылить www и мучаться с записями.

Ошибка 3: Однословные имена (CORP) Single Label Domains (SLD).

Почему плохо: Устарело. Многие современные приложения (включая продукты Microsoft) просто откажутся работать с таким доменом корректно.

Как сделать правильно (Best Practice)


Используйте субдомен от вашего реального публичного домена.

Пример: если ваш сайт future-admin.ru, назовите AD: 👉 corp.future-admin.ru 👉 ad.future-admin.ru 👉 int.future-admin.ru

В чем профит:

SSL: Вы можете купить Wildcard-сертификат *.corp.future-admin.ru и он будет валиден везде.

DNS: Никаких конфликтов с внешним сайтом.

Azure/Entra ID: Идеальная синхронизация с облаком без лишних суффиксов.

Собственность: Вы гарантированно владеете этим пространством имен в интернете.

💡 Совет архитектора: Даже если у вас маленькая фирма «Рога и Копыта», стройте AD так, будто завтра вы будете интегрироваться с Azure или поглощать конкурентов.

#activedirectory #windows #architecture #bestpractice #dns #security
👍1
🌐 DNS: Шпаргалка архитектора. Не только A-записи
На картинке — база, которую должен знать любой Junior. Но архитектор отличается тем, что знает не только «что это», но и «как это не сломать».

Разберем основные типы записей с точки зрения граблей и Best Practices.

🔹 A / AAAA (Address) Классика. Связь имени и IP.

Pro Tip: Если внедряете IPv6, всегда следите за паритетом. Если есть A, но нет AAAA, некоторые клиенты могут «тупить» при попытке подключения по v6, ожидая таймаута.

🔹 CNAME (Canonical Name) Алиас. Одно имя ссылается на другое.

⚠️ Главное табу: Никогда не вешайте CNAME на корневой домен (APEX / @). Это ломает почту (MX) и другие записи.

Исключение: CNAME Flattening (или ALIAS records) у продвинутых провайдеров типа Cloudflare, которые «притворяются» A-записью.

🔹 MX (Mail Exchange)
Указывает, куда слать почту.

Pro Tip: Цифра приоритета (10, 20) важна. Чем меньше число, тем выше приоритет. Резервный сервер всегда должен иметь число больше.

🔹 SRV (Service) Самая загадочная запись для новичков, но критическая для Windows-админов.

Зачем: Указывает не только хост, но и порт + вес сервиса.

Где живет: Active Directory держится на SRV. Если клиенты «теряют» домен, а пинги ходят — 99% проблема в битых SRV-записях в _msdcs.

🔹 TXT (Text) На слайде нет, но в 2025 году это маст-хэв.

Зачем: Это уже не просто заметки. Это безопасность почты (SPF, DKIM, DMARC) и верификация владения доменом для SSL/Google/Microsoft.

🛠 Инструмент для проверки: Забудьте про nslookup. Используйте мощь:

Windows (PowerShell):
Resolve-DnsName -Name domain.com -Type ALL

Linux / macOS:
dig domain.com ANY +noall +answer

Сохраняй шпаргалку, чтобы не путать CNAME с A-записью в пятницу вечером. 😉

#dns #network #basics #troubleshooting #шпаргалка #adminfuture
🔥3
📍 DNS: Зачем нужна точка в конце (google.com.)?

Вы наверняка видели в конфигах BIND или в старых учебниках домены с точкой на конце: example.com. Зачем она?

Это FQDN (Fully Qualified Domain Name) — полностью определенное имя домена.

Как это работает: Когда вы пишете в браузере google.com (без точки), ваш компьютер на самом деле пытается быть умным. Если вы находитесь в корпоративной сети corp.local, резолвер может сначала попробовать найти:

google.com.corp.local (А вдруг это внутренний сервер?)

И только потом google.com. (Корень интернета).

Точка в конце говорит системе жестко:

"Не пытайся подставить локальные суффиксы. Иди сразу в корневой DNS (Root Zone)."

Практика: В критических скриптах и конфигах серверов (особенно Nginx/Postfix) использование точки в конце (proxy_pass http://backend.local.;) ускоряет резолвинг и защищает от атак с подменой локальных доменов.

#network #dns #theory #fqdn #internet #basics
👍2
🌐 Network: Полная трассировка DNS (dig +trace)

Сайт не открывается. Вы пингуете — IP нет. nslookup говорит "Server failed".
Проблема у вас? У провайдера? Или у регистратора домена?

Используйте dig с флагом трассировки. Она покажет весь путь запроса: от корневых серверов интернета до конечной записи.

Команда:


dig +trace google.com

Как читать вывод:
1. Сначала ответят корневые сервера (.).
2. Потом сервера зоны TLD (.com).
3. Потом NS-сервера компании (ns1.google.com).

На каком этапе получите тайм-аут — там и проблема. Если nslookup просто говорит "ошибка", то dig +trace показывает кто именно виноват.

#network #dns #dig #troubleshooting #cli #internet
🧠 Network: Тест сайта без правки hosts (curl --resolve)

Ситуация: Вы переносите корпоративный портал на новый сервер (IP 10.0.0.5 ). Вам нужно проверить, как он отвечает, до того, как вы переключите DNS для всех пользователей.

Боль: Править файл hosts , сбрасывать кэш браузера, потом не забыть удалить запись... Долго и грязно. 😖

Решение Архитектора: Используйте curl с подменой IP на лету.

Команда:


# Запросить domain.com, но стучаться принудительно на 10.0.0.5
curl -v --resolve domain.com:443:10.0.0.5 https://domain.com

В чем магия: Вы увидите, валиден ли SSL-сертификат именно на новом сервере и какие заголовки он отдает. Файл hosts трогать не нужно! Чисто, быстро, профессионально.

#network #curl #dns #migration #testing #web #hacks
🔥2👍1
Network: Когда обновится этот чертов домен? (TTL)

Вы сменили IP-адрес сервера в DNS. Клиенты жалуются, что видят старый сайт. Вы говорите: "Ждите обновления кэша". Но сколько ждать? Час? Сутки?

Смотрите на TTL (Time To Live). Это число, которое показывает, сколько секунд запись будет жить в кэше резолвера.

Команда:

dig google.com

Смотрим в ответ (ANSWER SECTION):

google.com. 185 IN A 142.250.185.78

Вот это число 185 — это секунды. Запустите команду еще раз через 10 секунд — число станет 175. Как только оно дойдет до 0, резолвер пойдет спрашивать авторитетный DNS-сервер и получит ваш новый IP.

Вывод: Перед переездом всегда заранее снижайте TTL до 60 секунд (за сутки до работ), чтобы переключение прошло мгновенно.

#network #dns #ttl #dig #migration #theory #troubleshooting
🌐 Networking: DNS-over-HTTPS (DoH) в Linux — приватность уровня 2026

В 2026 году обычный DNS-трафик (порт 53) — это открытая книга для любого, кто сидит на транзите. Если хочешь скрыть свои запросы от посторонних глаз и защититься от подмены DNS, пора переходить на DoH. В современных дистрибутивах (Ubuntu 24.04+/Debian 13+) это настраивается через systemd-resolved. 🔐

Как включить за 1 минуту:

Отредактируй конфиг: sudo nano /etc/systemd/resolved.conf

Добавь или измени строки:

[Resolve]
DNS=1.1.1.1#cloudflare-dns.com
DNSOverHTTPS=yes

Перезапусти службу: sudo systemctl restart systemd-resolved

Как проверить: resolvectl status — в строке "Protocols" должно появиться +DoH.

Теперь твои DNS-запросы зашифрованы внутри обычного HTTPS-трафика. Провайдер видит, что ты куда-то ходишь, но не знает, на какие именно домены. 🕵️‍♂️

#networking #security #linux #doh #privacy #sysadmin #dns 🛡️
🔥1
🪟 Windows: Кто «стучит» в интернет? Ловим malware без Wireshark

Подозрение, что сервер соединяется с C&C-сервером хакеров или майнинг-пулом? Wireshark ставить нельзя, а Firewall логи слишком объемные. В Windows есть скрытый журнал, который пишет только DNS-запросы.

Как включить «черный ящик» DNS: По умолчанию этот лог выключен, чтобы не тратить ресурс.

Открываем Event Viewer (eventvwr.msc).

Идем: Applications and Services Logs -> Microsoft -> Windows -> DNS Client Events -> Operational.

Правой кнопкой -> Enable Log.

Что мы увидим: Теперь каждое разрешение имени (хост -> IP) будет падать в событие ID 3008.
QueryOptions: 100000000 QueryName: bad-hacker-site.com

Это лучший способ найти скрытые майнеры или «маячки» внутри корпоративной сети, не перехватывая гигабайты трафика.

#windows #security #forensics #dns #sysadmin #troubleshooting #blueteam 🕵️‍♂️
🔥32👍2
🌐 Сеть: DNS-over-HTTPS (DoH) в браузере и системе — обходим цензуру на уровне имен 🔍

Если сайты перестали открываться, часто проблема не в блокировке IP, а в подмене DNS-ответов провайдером. В 2026 году использовать стандартный 53-й порт для DNS — значит позволять любому узлу на пути видеть и менять твои запросы.

Как настроить DoH в Linux через systemd-resolved:

В /etc/systemd/resolved.conf добавь:


[Resolve]
DNS=1.1.1.1 8.8.8.8
DNSOverHTTPS=yes

Перезапусти: systemctl restart systemd-resolved

Как проверить, что всё работает:
resolvectl query google.com — ты должен увидеть, что запрос ушел в зашифрованном виде.


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

#networking #dns #doh #privacy #security #sysadmin #linux #admin_future
👍3
🪟 Windows: Май 2026 Patch Tuesday — 120 CVE, ноль zero-days, два приоритета

Коллеги, вчера вышел майский Patch Tuesday. Хорошая новость: впервые с июня 2024 года — ни одного активно эксплуатируемого или публично раскрытого zero-day. Плохая: несмотря на это, три компонента требуют срочного внимания.

CVE-2026-41096 — Windows DNS Client RCE, Critical.
Злоумышленник-контролируемый DNS-сервер может отправить специально сформированный DNS-ответ на уязвимую Windows-систему, что вызовет некорректную обработку памяти клиентом DNS и позволит выполнить код удалённо. DNS-клиент есть на каждой Windows-машине. Вектор — любой ответ от вредоносного DNS-сервера.

CVE-2026-41089 — Windows Netlogon RCE, Critical.
Stack-based buffer overflow в Netlogon. Контроллеры домена — это не обычные серверы, это структура авторизации всего Windows enterprise. Ошибка которая может быть применена против DC, даже при ограниченных условиях, должна быть в топе любого совещания по приоритизации патчей.

CVE-2026-41103 — Microsoft SSO Plugin для Jira/Confluence, CVSS 9.1, Critical.
Сетевая эксплуатация, не требует привилегий, не требует взаимодействия пользователя. Microsoft пометил как «Exploitation More Likely». Успешный эксплойт даёт неаутентифицированному атакующему доступ к Jira/Confluence с повышенными привилегиями.

# Проверяем установлены ли майские обновления:
Get-HotFix | Where-Object {$_.InstalledOn -ge "2026-05-12"} |
Select-Object HotFixID, InstalledOn |
Sort-Object InstalledOn -Descending

# Для Windows 11 — KB5089549:
# Для Windows 10 — KB5087544:
Get-HotFix | Where-Object {$_.HotFixID -in @("KB5089549","KB5087544")}

# Prioritization список:
# 1. DC: KB c Netlogon fix (CVE-2026-41089) — ставим первыми
# 2. Все хосты: DNS Client (CVE-2026-41096) — широкая поверхность
# 3. Atlassian-интеграции: SSO Plugin (CVE-2026-41103) — проверить версию

# Для Hyper-V хостов: CVE-2026-40402 (guest-to-host escape) — Critical
Get-VM | Select-Object Name, State, Version # смотрим что запущено

# Хорошая новость этого Patch Tuesday:
# KB5089549 (Windows 11) закрывает проблему с неожиданными
# запросами BitLocker recovery key, которая была с апреля:
Get-HotFix "KB5089549"


Зачем это важно: фраза «не эксплуатируется в дикой природе» описывает знания Microsoft на момент релиза, а не гарантию завтрашнего поведения атакующих.

Итог: отсутствие zero-day не означает «можно подождать». DNS Client + Netlogon — это патчить в первую очередь на DC и серверах. Плюс майский патч закрывает апрельскую BitLocker-проблему — два повода для обновления.

#windows #patchtuesday #security #dns #netlogon #sysadmin #admin_future
🪟 Windows: DNS over HTTPS на сервере стал GA — шифруем DNS для клиентов

Коллеги, в июньском обновлении Windows Server 2025 (KB5094125) тихо приехала фича которую ждали — и которую затмили 206 CVE и Secure Boot. Разбираем.

Июньское обновление включает server-side DNS over HTTPS (DoH) как generally available. Это обеспечивает шифрованную DNS-коммуникацию между сервером и его клиентами, улучшая приватность и безопасность за счёт защиты DNS-запросов, особенно против определённых атак. Важно: DoH-поддержка применяется только к server-to-client коммуникации, не к шифрованию между серверами.

Почему это важно: DNS-запросы исторически идут открытым текстом. Любой кто видит трафик — видит какие домены резолвят твои клиенты. Для внутренней сети это вектор разведки при компрометации, для филиалов через недоверенные каналы — прямая утечка. DoH закрывает это на уровне DNS-сервера.

Также в этом же обновлении — важный фикс по теме которую мы разбирали в апреле:

Обновление решает проблему когда некоторые устройства могли входить в BitLocker recovery после обновления boot-файлов, на системах с определёнными настройками TPM validation (особенно невалидными PCR7-конфигурациями). Это поведение возникало после установки апрельского обновления KB5082063.

# Включаем DNS over HTTPS на Windows Server 2025 DNS-сервере:

# 1. Проверяем что июньское обновление установлено:
Get-HotFix -Id KB5094125 -ErrorAction SilentlyContinue

# 2. Включаем DoH на DNS-сервере:
Set-DnsServerSetting -Name "EnableDoHServer" -Value $true
# (точное имя командлета может отличаться — проверяем доступные:)
Get-DnsServerSetting -All | Select-String -Pattern "DoH|HTTPS"

# 3. Привязываем сертификат для DoH (нужен валидный TLS-сертификат):
# Сертификат с SAN = FQDN DNS-сервера
$cert = Get-ChildItem Cert:\LocalMachine\My |
Where-Object {$_.Subject -like "*dns-server-fqdn*"}
# Регистрируем сертификат для DoH listener

# 4. Проверяем что DoH слушает (порт 443):
Get-NetTCPConnection -LocalPort 443 -State Listen |
Where-Object {$_.OwningProcess -eq (Get-Process dns).Id}

# 5. Также новая GPO для контроля Secure Boot телеметрии:
# Computer Config -> Admin Templates -> Windows Components
# -> Secure Boot -> LimitSecureBootRequiredServiceData
# Позволяет ограничить какие Secure Boot данные уходят в Microsoft

# 6. Настраиваем клиентов на использование DoH:
# GPO: Computer Config -> Admin Templates -> Network -> DNS Client
# -> Configure DNS over HTTPS (DoH) name resolution -> Require DoH


Зачем включать сейчас: после месяцев фокуса на патчинге уязвимостей — это редкая возможность улучшить базовую безопасность инфраструктуры проактивно. Шифрование DNS закрывает целый класс пассивной разведки в сети.

Итог: июньское обновление это не только 206 CVE и Secure Boot. Это DoH server-side GA + фикс апрельской BitLocker-проблемы. Подними DoH в лабе на этой неделе — это базовая гигиена которую долго ждали в Windows Server.

#windows #dns #doh #windowsserver2025 #security #sysadmin #admin_future
1