Записки IT специалиста

Неочевидное - невероятное

Работая с определенным оборудованием накапливается опыт и определённые практики. Некоторые действуют на подсознательном уровне.

Так в Mikrotik если мы что-то изменили - оно становится синим. Но не всегда и не везде.

Откроем брандмауэр и создадим там правило пустышку, ну, скажем, такое.



0    chain=forward action=accept log=no log-prefix="" 


Теперь откроем его в Winboх и полазим на закладке Extra, ничего не трогаем, просто смотрим. Как видим ничего не посинело, спокойно уходим и жмем OK.

Но не тут-то было, вывод правил в терминал покажет нам:



0    chain=forward action=accept psd=21,3s,3,1 limit=1,5:packet dst-limit=1,5,dst-address/1m40s time=0s-1d,sun,mon,tue,wed,thu,fri,sat log=no log-prefix="" 


👀 Внезапно!

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

Официальный выход Ubuntu 26.04

В четверг, 23 апреля 2026 года был официально выпущен релиз Ubuntu 26.04, о самой системе мы уже недавно писали (https://t.me/interface31/5994) и к уже опубликованному особо добавить нечего.

Основное нововведение – это полный переход на Wayland и отказ от X11 в головном дистрибутиве. Также на Wayland перешли и такие популярные выпуски как Kubuntu и Ubuntu Budgie, но в них возможность сеанса X11 можно вернуть вручную, необходимые пакеты остались в репозитории, хотя более не поддерживаются.

В общем и целом все уверенно идет к тому, что X11 в течении нескольких следующих лет полностью сдаст свои позиции в ведущих средах рабочего стола и останется уделом энтузиастов.

И это скорее хорошо, чем плохо, так как X11 архитектурно сильно устарел, а скорость разработки Wayland откровенно не радовала, теперь же есть надежда на то, что ситуация коренным образом изменится.

Также в этом выпуске «дружное семейство» дистрибутивов на базе Ubuntu понесло потери. Так Ubuntu MATE вообще не смог сформировать сборки для 26.04 (как и не сформировал их для 25.10), а в конце марта проект покинул лидер и ведущий разработчик.

Скорее всего на Ubuntu MATE, как и на среде MATE вообще можно ставить жирный крест, проект находится в стагнации с 2024 года, и он не интересен крупным игрокам, которые могли бы вдохнуть в проект новую жизнь.

Более интересна другая сборка - Ubuntu Unity, которая все-таки выпустила релиз 26.04, но он не получил статуса LTS. А интересен этот проект тем, что основной разработчик проекта – индийский студент Rudra Saraswat, который оставил проект по причине поступления в университет.

В 2021 году, когда он только начинал работу над Unity ему было 12 лет, а уже в 2022 Ubuntu Unity вошел в число официальных редакций.

Сегодня в проекте остался только модератор, но тем не менее сборка 26.04 была сформирована на базе Unity 7.7 от декабря 2022 года.

Несмотря на это будущее проекта также туманно, так как не видно желающий подхватить проект, в то время как основной разработчик теперь имеет иные интересы.

Великое вымирание видов

Каждая наша публикация на тему ИИ всегда вызывает комментарии вида, что тем самым мы просто роем себе могилу и сужаем «кормовую базу», ведь если клиент может все сделать сам при помощи ИИ, то зачем ему нанимать специалиста.

Другие сетуют, что, заменив младшую ступень специалистов, так называемых «джунов» ИИ уничтожает рост квалифицированных кадров, ибо откуда тогда возьмутся «мидлы» и «сеньоры»?

Однако ничего принципиального нового не происходит, идет планомерное изменение технического уклада, которые оставит за бортом одни профессии, изменит другие и создаст третьи.

Все это уже было в человеческой истории, те же луддиты не на пустом месте возникли, но ничего, не вымерло человечество, как-то адаптировалось.

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

Инженер в процессе разработки или проектирования создавал чертеж, который потом те самые чертежники старательно дублировали, создавали дополнительные проекции, разрезы и все такое прочее.

Была ли эта работа творческой? Нет. Создавали ли чертежники что-то новое? Снова нет, их работа – повседневная рутина.

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

Но инженеры как были, так и остались, им даже лучше стало, не надо проверять за чертежниками, потому что CAD делает все точно и не ошибается.

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

В системном администрировании скоро тоже наступит перелом от повсеместного внедрения ИИ агентов. Да, в нынешнем виде агенты косячат, местами фатально, но давайте будем честны – люди косячат не реже, а даже чаще, с теми же самыми фатальными последствиями.

Но ИИ-агент, в отличие от человека, никогда не будет лениться сделать дополнительные проверки, резервные копии и все такое прочее, на что живой коллега вполне себе может забить, мол не очкуй, сто раз так делал.

Но если ИИ плотно займет позиции «джунов», откуда тогда браться более квалифицированным специалистам?

Честно? Откуда они до сих пор брались, оттуда и продолжат. Это в идеальной вселенной у нас есть «дорога из желтого кирпича» - джун, мидл, сеньор, тимлид. В реально жизни все немного иначе.

Для примера возьмем спортивную секцию в спальном районе. Туда ходит много детей, но сколько из них достигнут реальных результатов? Станут лауреатами хотя бы на уровне города?

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

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

Но человек ленив, ошибается, ему надо отдыхать, спать, кушать и т.д. и т.п. Поэтому заменить его на ИИ – это только плюсы и для работодателя, и для старших товарищей. Что задачу джуну ставить, что промт написать.

А как же карьерная лестница? Да никак, ее там не было и сейчас нет. В мидлы выбиваются не те, кто хорошо умеет набивать код буквами, а кто мыслит и понимает абстракции, которые находятся выше этих букв.

Но это могут не только лишь все и для такого начинающего ИИ будет только помощником, которые реализует его идеи в коде, проверит гипотезы, расскажет, покажет и вообще поможет профессиональному росту.

Кто хочет – тот найдет пути и инструменты. А вот кто не хочет, там да, впереди великое вымирание видов. Как раньше вымерли чертежники, так скоро вымрут писатели кода буквами и админы начального уровня,

Использование Routing Rules в роутерах Mikrotik

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

Вопрос не праздный, потому как при том же переключении на мобильный интернет неконтролируемый выход в сеть быстро способен исчерпать доступный лимит трафика.

Можно воспользоваться брандмауэром, но есть способ лучше - Routing Rules. Это правила, используемые при маршрутизации и которые в ряде случаев позволяют решать задачи фильтрации более дешево и эффективно, нежели брандмауэр.

Однако следует помнить, что правила в Mangle имеют больший приоритет, так как будут отработаны раньше, чем будет принято решение о маршрутизации.

Правила Routing Rules начнут работать уже после того, как решение о маршрутизации принято.

Немного напомним, основной задачей маршрутизации является поиск интерфейса выхода среди непосредственно присоединенных сетей (т.е. интерфейсов маршрутизатора).

По умолчанию в роутере присутствует основная таблица маршрутизации – main, также мы можем создать сколько угодно пользовательских.

В процессе поиска маршрута роутер ищет маршрут с самой широкой маской в своей таблице маршрутизации, если ни одна запись не найдена, то выбирается «нулевой» маршрут, он же основной шлюз сети.

Очень многие ошибочно считают, что на этом процесс выбора маршрута завершен, но это не так. Да, мы знаем куда нам надо пройти, но не знаем как.

Поэтому маршрутизатор начинает искать интерфейс выхода к найденному нами шлюзу среди непосредственно присоединенных сетей, если таковой находится, то поиск считается завершенным и пакет уходит по назначению.

Если же узел назначения недоступен – поиск продолжается. Правило маршрутизации по умолчанию – lookup – поиск. И если маршрут не будет найден в собственной таблице, он будет продолжен в основной.

Поэтому, если мы не хотим, чтобы при отказе одного провайдера пакет уходил другому, то нам следует ограничить поиск только собственной таблицей маршрутизации, установив правило lookup-only-in-table.

В качестве критериев задаем метку маршрутизации и таблицу маршрутизации. Фактически правило читается так: для всех пакетов с меткой такой-то ограничить поиск таблицей маршрутизации такой-то.

Но это далеко не все. В качестве критериев мы можем использовать адреса источника и назначения, а также интерфейс.

В действиях нам также доступны drop, который молча блокирует пакет и unreachable, который отравит ICMP-ответ с сообщением о недоступности узла назначения.

Это можно использовать для ограничения доступа между сетями или отдельными узлами без использования брандмауэра.

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

ИИ в современной разработке

Вчера была ровно неделя релизу нашего нового сайта и самое время подвести итоги и рассказать о той роли ИИ, которую он взял на себя в этом нелегком процессе.

В настоящее время бытует два противоположных мнения. Одно из них, что ИИ — это баловство и ничего серьезного он не напишет, дольше будете за ним разгребать и проверять. Второе, что это прямо серебряная пуля, только успевай загадывать желания.

Истина, как всегда, где-то посередине и пока фанатики с обеих сторон ломают копья, практики играют от сильных сторон доступных решений.

Мы не раз и не два пытались перевести сайт на новый движок, но все упиралось в то, что если, в общем и целом, все было хорошо, то оставшиеся 20% «мелочи» требовали оставшиеся 80% времени, которые надо было потратить на глубокое погружение в новый движок.

Никакой Америки мы тут не открыли, это в любой отрасли так. Но всегда лучше, если у тебя есть наставник, который хотя бы покажет примеры и пояснит почему тут так, а не эдак.

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

Я просто закидывал ему насущные задачи, проверял ответы и просил пояснить что именно он сделал и почему.

Можно ли это было сделать самому? Можно, но вопрос не в этом, а в затраченном времени. То, что я сделал с ИИ за вечер самостоятельно я бы искал неделю – читал документацию, проверял варианты, отлаживал, искал ответы на форумах и т.д. и т.п.

А тут интенсивная и быстрая прокачка прямо по ходу решения актуальных вопросов.

Поэтому, если вы действительно настроены на изучение новой темы, то ИИ дают вам возможность быстрого старта за счет концентрации уже накопленных знаний в одном месте.

Но можно ли просто не вникать, а заставить ИИ довести проект до конца? Можно, только вот далеко не факт, что вы придете туда, куда хотели, а не заплутаете в трех соснах.

В части освоения азов сетки дают отличный старт, но вот после они уже не так уверенны в себе, хотя вам никогда этого не покажут.

На сложных вопросах сетка может начать галлюцинировать или ходить по кругу, предлагая набор неработающих решений по кругу.

Именно с этим я столкнулся при решении вопроса транслитерации таксономии. ИИ выдавал одно нерабочее решение за другим, потом говорил, что он все понял и выдавал очередную дребедень и так по кругу.

Тут помогли знания, которые я почерпнул на первом этапе освоения движка, с его же помощью. Я просто ткнул его носом в кусок кода и спросил – а почему тут так, ведь надо совсем иначе.

В ответ получил стандартное – ты абсолютно прав и пояснения, почему это не будет работать.

Дальше предлагаю ему поискать в сети эту же проблему и через минуту получаю ссылку на форум с рабочим решением.

Проверяю – работает, но у меня не один шаблон и не два. Беру ссылку отдаю ИИ и говорю, вот так работает, давай ка сделай на проекте как надо и очень скоро получаю все необходимые правки.

Много ли я написал кода сам? Строки две-три, остальное старалась сетка. Результат – он перед вами. Полгода на перенос проекта с историей более 15 лет, большая часть которого это именно перенос контента, а не работа над сайтом.

Да, в любом случае в новом проекте будет все и косяки, и баги, но факт не в этом, а в том, что ИИ позволяет вам сократить путь от задумки до релиза. А не зависнуть надолго в промежуточной стадии.

Код написан ИИ? А что в этом плохого? Сетка давно пишет лучше человека, читая ее код я понимаю, что сам бы проигнорировал все эти проверки, обработки исключений и прочее, так как это в «типовом сценарии» маловероятно.

Поэтому не стоит чураться ИИ, равно как и превозносить их, это просто современный рабочий инструмент, который способен быстро подсказать, помочь, ввести в курс дела или взять на себя рутину.

Но руководите проектом именно вы и вы решаете в какую именно сторону будет грести ИИ и что конкретно он будет делать.

Caddy-Docker-Proxy

Веб-сервер Caddy крайне популярен не только в виде веб-сервера, но и обратного прокси, благодаря крайне простой настройке, автоматической конфигурации TLS, включая прозрачную интеграцию с Let’s Encrypt.

Также Caddy популярен как обратный прокси для Docker, который обычно принято настраивать «классически», например:

grafana.example.com {
    reverse_proxy grafana:3000
}

nextcloud.example.com {
    reverse_proxy nextcloud:8080
}

Но Docker – это в первую очередь динамические среды, контейнеры могут создаваться, удаляться, меняться, особенно в тестовых средах и каждый раз править руками конфигурацию обратного прокси – занятие утомительное.

Поэтому был разработан специальный плагин Caddy-Docker-Proxy, который позволяет Caddy работать с метками Docker, автоматически подхватывая конфигурацию, как Traefik.

Для этого просто используйте готовый контейнер от разработчика плагина, для этого создайте следующий docker-compose.yaml

services:
  caddy:
    image: lucaslorentz/caddy-docker-proxy:ci-alpine
    ports:
      - 80:80
      - 443:443/tcp
      - 443:443/udp
    environment:
      - CADDY_INGRESS_NETWORKS=caddy
    networks:
      - caddy
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - caddy_data:/data
    restart: unless-stopped

networks:
  caddy:
    external: true

volumes:
  caddy_data: {}

Затем в compose нужного сервиса добавьте:

services:
  my_app:
    image: my_app:latest
    networks:
      - caddy
    labels:
      caddy: my_app.example.com
      caddy.reverse_proxy: "{{upstreams 80}}"

networks:
  caddy:
    external: true

Теперь при запуске контейнера my_app в конфигурацию Caddy будет добавлена секция для обратного проксирования вашего сервиса.

Жизнь и необычайные приключения DNS в одной сети

Продолжая тему DNS, точнее борьбы с утечкой DNS хотим рассказать о собственном опыте, он во многом частный и субъективный, но во многом помогает понять на что надо обратить внимание и куда смотреть.

Начнем со всеми любимых роутеров Mikrotik. Если мы заглянем с настройки DNS, то можем увидеть там, как доступные к редактированию поля, где записаны указанные нами значения вышестоящих серверов, так и недоступные к редактированию значения, которые берутся из настроек DHCP или коммутируемого соединения. Т.е. то, что передал нам провайдер.

Они используются как дополнительные DNS, если не отвечают те, которые мы указали явно – в дело идут следующие по списку. Это не хорошо и не плохо, это нормальное поведение DNS-клиента.

Далее есть еще одна тонкость, если в настройках DHCP-сервера у вас явно не указана Option 6, она же адрес(а) DNS, то ваш DHCP передаст как собственный адрес (первым), так и все внешние адреса, которые указаны в настройках вышестоящих DNS.

Таким образом, если ваш роутер вдруг по какой-то причине перестал отвечать на DNS-запросы они пойдут напрямую внешним серверам.

Вот так вы можете легко и непринужденно начать использовать на клиентах совсем не те DNS-сервера, которые предполагали.

Но это еще не все. Проанализировав DNS-трафик в сети, мы выяснили, что мобильные устройства на Android эпизодически обращаются к DNS-серверам Google, хотя эти сервера нигде в настройках сети до этого не фигурировали.

Скорее всего такое поведение зашито где-то внутри ОС и предполагает использование именно доверенных для нее серверов. Такое поведение можно понять, но с позиции наших целей, а именно защитить DNS-запросы от просмотра третьими лицами – налицо типичная утечка.

Но это половина беды. От тех же мобильных устройств и телевизоров были обнаружены DNS-запросы к вообще третьим DNS-серверам, о существовании которых мы ранее не догадывались.

Причем это не какие-то левые сервера, а достаточно крупные региональные сервисы или сервисы крупных хостеров, как вероятно зашитые разработчиками приложений в свои разработки. Это тоже не особо страшно и не особо плохо, но в наличии у нас имеется факт, что отдельные приложения могут также игнорировать системные настройки DNS.

Вы думаете, что это все? Но нет. Отдельно порадовали два роутера Xiaomi AX3000T, которые продолжили обращаться к внешним серверам, используемыми нами до этого и серверам провайдера.

При этом сетевые настройки они получают от DHCP-сервера на Mikrotik, но все настройки, кроме адреса и шлюза тупо игнорируют.

В веб-интерфейсе и приложении доступа к этим настройкам также нет. Перезагрузка не помогает и приводит только к замене одного сервера на другой из списка.

Есть предположение что DNS-сервера были взяты при первоначальной настройке и добавлены в некоторый конфигурационный файл, который при смене настроек DHCP не обновляется.

В данном случае они работают именно как точки доступа и разрешают только свои внутренние запросы. Но все равно, данный факт показывает, что активное сетевое оборудование в вашей сети также может иметь свои собственные взаимоотношения с DNS, что может приводить к утечкам.

Пока мы плотно не занялись этим вопросом, то предполагали, что основной риск утечки DNS несут пользователи, которые могут вручную поменять сервера в настройках сетевого подключения.

В реальности же это оказалось далеко не так и основной риск исходит от сетевых устройств и сетевых приложений, которые могут игнорировать (и успешно это делают) системные настройки DNS.

psistat – монитор Pressure Stall Information (PSI) в Linux

Про метрики Pressure Stall Information мы уже рассказывали в материале про новые возможности Proxmox VE 9.

Но это универсальные Linux метрики, которые появились в ядре 4.20 и показывают процент времени, в течении которого процессы ожидают освобождения критичных ресурсов: процессора, памяти, ввода-вывода.

👉 У данных метрик есть две основные категории:

🔹 some — показывает время, когда хотя бы один процесс ожидает освобождения ресурсов
🔹 full — показывает время, когда все активные процессы ожидают освобождения ресурсов

Про интерпретацию их значений мы повторяться не будем, все это можно прочитать в заметке по ссылке. Сегодня мы расскажем про инструмент их контроля в реальном времени – psistat.

Он написан на python и для его установки вам сначала потребуется pipx:

apt install pipx

Затем:

pipx install psistat

Он установит утилиту в ~/.local/bin и если вы хотите, чтобы утилита была доступна без указания полного пути, выполните:

pipx ensurepath

После чего выйдите и снова войдите в систему.

Затем просто запустите:

psistat

Вы увидите интерактивный текстовый интерфейс как на скриншоте, метрики со средними значениями в 60 и 300 секунд предоставляются ядром и доступны сразу, метрики за 1, 3 и 10 секунд рассчитываются утилитой на основе накопленных данных и появляются не сразу.

Управление происходит при помощи клавиш:

▫️ t – задает порог превышения метрики, по умолчанию 5%
▫️ i – интервал превышения, по умолчанию 10 сек

Теперь любое событие, значение которого превысит 5% за 10 секунд появится в таблице ниже.

Остальные клавиши управляют отображением этой таблицы:

▫️ b – ограничивает ее размером экрана, остальные события вытесняются, иначе доступен полный список
▫️ d – дамп, прерывает интерактивный режим и выводит список событий в консоль, чтобы вы могли его скопировать, после чего переходит в режим нормальной работы.

Инструмент крайне интересный и полезный, потому что сегодня мало интерактивных инструментов для Pressure Stall Information, в то время как это один из важнейших показателей при анализе проблем с производительностью.

И снова одно и тоже... Выключился свет, бесперебойник погас, сервера упали... А теперь... В общем - беда, да еще и вечером.

А надо было всего-лишь подстелить соломки...

Настраиваем централизованное управление электропитанием в сети при помощи NUT

Всем известно, что для защиты от сбоев электропитания нужно купить бесперебойник. Но сам по себе источник бесперебойного питания не решает проблему, а только отсрочивает негативные последствия.

Действительно, если питание пропадет надолго, то после разрядки батарей ИБП ваши системы аварийно завершат работу. Избежать этого позволяют модели, имеющие обратную связь, но, чтобы использовать эти возможности нам потребуется система управления электропитанием и сегодня мы расскажем об открытом и бесплатном продукте - NUT (Network UPS Tools).

✅ Читать далее

Интересная статья на Хабре

Как я за 15 лет устал диагностировать серверы руками и сделал инструмент, который делает это за 60 секунд

Предыстория:

Я работаю с Linux больше 15 лет. Начинал с хостинга, где «сервер тормозит» означало зайти по SSH и запустить top. Потом были выделенные серверы, кластеры, Kubernetes. Задачи менялись, но вопрос оставался один и тот же:

Сервер тормозит. Что не так?

За эти годы у меня накопились инструкции, SSH-скрипты, обёртки над vmstat, iostat, ss, perf. Каждый раз, подключаясь к проблемному серверу, я тратил 20-40 минут на одни и те же действия вроде команды top

Это Tier 1 — базовый уровень. Но когда top показывает что всё вроде нормально, а приложение всё равно тормозит, начинается настоящая диагностика.

Глубже: BPF, softnet, NUMA и другие невидимые проблемы

С опытом я погружался глубже. BPF/eBPF инструменты от Brendan Gregg — runqlat, biolatency, tcpretrans, offcputime — открыли целый мир проблем, невидимых через top

Проблема в том, что подобные задачи решаются не каждый день. Между инцидентами проходят недели, иногда месяцы. И каждый раз я забывал: как называлась та утилита для softnet? Какой файл в /proc показывает conntrack drops? Какой sysctl отвечает за watermark?

Я снова гуглил, перечитывал свои же заметки, вспоминал синтаксис BCC-тулз.

AI изменила правила игры — но не до конца

Появление ChatGPT, а затем Claude изменило workflow. Теперь не нужно парсить глазами вывод cat /proc/net/netstat — можно скормить его нейронке и получить анализ. Не нужно помнить, что PruneCalled > 0 означает давление на TCP-память — AI это знает.

Но есть проблемы в том что нейросеть не умеет сама находить правильные инструменты и строить связи для вывода между ними. Давать root и SSH не безопасно. Запуски программ диагностики съедают кучу токенов и т.д.

Я понял, что нужен мост между сервером и AI: инструмент, который соберёт все данные за один прогон, в структурированном виде, и отдаст нейронке для анализа.

Что я сделал

melisai — один Go-бинарник. Без зависимостей, без конфигов, без демонов. Одна команда.

✅ Читать далее: https://habr.com/ru/articles/1019782/

Удобство против безопасности

Стоило нам опубликовать днем новую заметку о фишинге через RDP и предпринятых разработчиками Windows мерами по этому поводу, как тут же появились советы как все это отключить.

На первый взгляд – парадокс, но на самом деле все закономерно. Человек существо ленивое и подверженное привычкам, от которых очень трудно избавляется. И для обычного пользователя все эти нововведения - только очередное неудобство, которое придумало IT чтобы еще сильнее затруднить им работу.

И здесь можно позавидовать тем, у кого в штатном расписании есть нормальная СБ, которая учитывает и IT-риски и на которую всегда можно перевести стрелки: мол, если недовольны – вам туда.

А в остальных случаях IT-отдел остается один на один с недовольными пользователями и раздраженным начальством. И да, появляется желание вернуть все как было, лишь бы отстали, но не стоит ему потакать.

Хотя не стоит и бросаться в крайности. Мы давно говорим о том, что затраты на безопасность не должны превышать возможный ущерб от ее отсутствия. Если проводить аналогию, то не стоит вешать на дачный сарай замок стоимостью выше, чем все имущество внутри этого сарая.

Но в данном случае следует исходить именно из оценки возможного ущерба, а он тут потенциально велик. Протокол RDP позволяет пробросить на удаленный компьютер практически все локальные ресурсы ПК, включая подключенные к нему токены и электронные ключи.

А это дает возможность выполнить определенные действия от вашего имени, которые потом будет очень сложно оспорить, либо вообще увести ваши ключи, если у вас там что-то простое, наподобие Rutoken Lite.

Если такое случится, то кто будет виноват? Конечно же IT-отдел и отмаза, что пользователям было неудобно тут не прокатит. Потому что руководство сразу задаст резонный вопрос: а видел ли ты подобный вариант развития событий? А если видел, то почему не настоял, не донес в понятной нам форме? Почему не был достаточно настойчив?

При том, что поиск крайнего – это любимое развлечение управленческой прослойки во все времена. И стать крайним очень и очень плохо. Особенно в бюджете и госах.

В тоже время всегда надо помнить, что безопасность и удобство – это два разных полюса и иногда надо настоять на своем и пожертвовать удобством ради безопасности.

Пользователи поворчат, но привыкнут, а вы снимите с себя еще одну головную боль. И не нужно вестись на шантаж, потому как удобно будет им, а отвечать будете вы.

Ну или требуйте письменный приказ от лиц, принимающих решения, в которых они явно приказывают вам понизить уровень безопасности и берут ответственность на себя.

Главное не забыть про последний пункт, потому что без делегирования ответственности эта бумага будет просто филькиной грамотой.

В заключение хочется сказать: коллеги, будьте разумны, осознавайте рамки ответственности и грамотно проводите политику, балансируя между безопасностью и удобством не выходя в зону риска.

Фишинг через RDP

Старый-добрый RDP известен всем, казалось бы, что тут можно придумать нового и вообще, что может пойти не так?

Взломать? Да, возможно, ломали и этот вектор атаки остается актуальным, так как обновления на Windows Server далеко не все устанавливают своевременно, а также в эксплуатации достаточно откровенно старых систем.

Но фишинг? Да, именно фишинг. Причем уязвимость оказалась очень серьезной и заставила Microsoft выпустить усиливающие защиту обновления.

Все дело в возможностях протокола RDP, который позволяет пробрасывать на удаленное устройство ресурсы локальной машины: буфер обмена, диски, токены и т.д.

Сценарий последующей атаки очень прост: злоумышленник присылает жертве RDP-файл и убеждает запустить его под благовидным предлогом. Далее идет подключение к серверу злоумышленника с пробросом всех локальных ресурсов, после чего последний получает полный доступ к ним.

Просто, но эффективно. Все окружение пользователя, все доступные ему ресурсы прямо на блюдечке с голубой каемочкой.

Исправления вошли в апрельское обновление безопасности:

🔹KB5082200 для Windows 10

🔹KB5083769/KB5082052 для Windows 11

Теперь при подключении показывается более подробные сведения о системе назначения, явно отображаются ресурсы, которые предлагается расшарить, но разрешения по умолчанию сброшены, т.е. пользователь должен явно подтвердить разрешение доступа к каждому ресурсу.

✅ Более подробно можно прочитать здесь: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/understanding-security-warnings

Обновляем Proxmox Virtual Environment с версии 8 до 9

Практически сразу после выхода Debian 13 была выпущена новая версия известного гипервизора Proxmox Virtual Environment 9. Это плановое обновление, с которым можно не спешить, поддержка восьмой версии запланирована до августа 2026 года, поэтому есть время подготовиться.

Наша инструкция, как всегда, написана на основе официальной документации, но нацелена именно на использование бесплатной версии и дополнена собственным опытом, накопленном в процессе эксплуатации данного продукта.

✅ Читать далее

Подборка наших статей про BIND, ISC DHCP и Kea

▫️ Настраиваем отказоустойчивый DHCP-сервер на базе ISC DHCP

▫️ Настраиваем отказоустойчивый DNS-сервер на базе BIND 9

▫️ Настраиваем динамическое обновление DNS-сервера BIND 9 при помощи ISC DHCP

▫️ Установка и базовая настройка DHCP-сервера Kea

▫️ Настраиваем динамическое обновление DNS-сервера BIND 9 при помощи Kea DHCP

Zettlr – мощный визуальный Markdown редактор

Уже заканчивая работу над переносом старого сайта, мы начали подбирать инструменты для работы над новым. Нужен был удобный редактор для работы с Markdown как в визуальном режиме, так и в сыром виде.

Попробовано было не мало, но все так или иначе чем-то не подходило. Многие коллеги предлагают использовать для этого Joplin/Obsidian, да, там неплохой редактор, но это отдельные приложения для ведения заметок, а не редакторы.

Особенно учитывая наличие проекта с 16-летней историей, запихать ее всю в заметки – не самая лучшая идея, как и жить на два дома: новое здесь, старое там.

Тем более что за это время уже сложился определенный технологический процесс работы над статьями и менять в нем хотелось что-либо в самую последнюю очередь. Поэтому инструмент должен был органично встроиться в рабочий процесс, а не заставлять менять процесс под инструмент.

У нас есть большая структура, примерно на 9 ГБ, с файлами черновиков, картинок, дополнительных материалов и т.д., разложенных в определенной иерархии папок. Осталось только добавить туда MD и вопрос решен.

При подготовке к публикации мы использовали для редактирования редактор VS Code, в целом, при помощи плагинов его несложно превратить в неплохой Markdown WYSIWYG редактор, но есть еще одно НО.

В среде профессиональных авторов и людей много работающих с текстом существует принцип «чистого листа», которые не следует путать с «боязнью чистого листа».

Данный принцип гласит, что при работе над текстом ничего не должно отвлекать от текста, с этим VS Code не справляется, да и не должен, это инструмент разработки, а не писательства.

В итоге пошел на поклон к ИИ и Gemini после нескольких попыток что-то посоветовать и выслушав мои претензии неожиданно посоветовала Zettlr.

Данный редактор возник в 2017 году как проект одного человека - Хендрика Эрца, которому нужен был простой и удобный редактор для академического письма, результат своего труда он опубликовал под лицензией GPL, что привело к привлечению в команду новых людей.

И Zettlr выстрелил, в своей среде, разумеется, среди людей, которые постоянно имеют дело с большими объемами текста. Сегодня это инструмент, управляемый сообществом и широко используемый в университетской, журналистской и писательской среде.

И он действительно удобен. Основной режим редактирования – гибридный, в том месте, где стоит курсор вы видите сырую MD-разметку, но как только вы поменяли его позицию вы видите, как это будет выглядеть в готовом документе.

При необходимости вы можете быстро переключиться в RAW-режим и проконтролировать разметку.

Редактор поддерживает проверку орфографии и пунктуации на многих языках с возможностью самостоятельно дополнять словари.

Файлы и изображения вы можете напрямую перетаскивать в окно редактора, он их сохранит в папку проекта, а если вы перетащили из папки – корректно оформит ссылку.

Есть режим автоматического сохранения при каждой правке, что ценно в наших условиях приграничья, когда в любой момент может случиться всякое.

Готовый материал можно не только сохранить как MD, но и экспортировать во все популярные офисные форматы или PDF.

А для человека много работающего с текстом у редактора есть ряд интересных и полезных режимов.

Во-первых, режим печатной машинки, когда активная область ввода (выделена серым на скриншотах) всегда остается в середине листа и текст плавно уезжает вверх. Тому, кто работает с длинными текстами не нужно пояснять удобство данного режима.

Для остальных поясним. При работе с большим текстом, более чем на 1 экран курсор у вас постоянно будет внизу страницы, что неудобно, а так вы постоянно фокусируете взгляд на одну и ту же область.

К ней можно прибавить режим «без отвлекающих факторов», он же режим «чистого листа», когда с вами только ваш текст и ничего лишнего, уже написанные абзацы немного затемняются и не отвлекают вас от текущей мысли.

На первый взгляд странно и неудобно, но постоянно работая над текстом такой режим дает наибольшую концентрацию и результативность.