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

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

Так в 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, где вы еще не были, даже если заходили вы просто посмотреть.

Reverse Proxy в Mikrotik

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

Обычно задача решалась установкой Caddy/NGINX на отдельном сетевом узле или контейнере и пробросу на него веб-портов. Однако это дополнительный элемент инфраструктуры, который надо где-то размещать и отдельная точка отказа.

Кроме того, Mikrotik серьезно взялся за контейнеризацию и поэтому функция обратного прокси напрашивалась сама собой, что и было реализовано в обновлении RouterOS 7.22.

Данная возможность располагается в IP - Reverse Proxy и для создания нового проксирования вам нужно заполнить поля:

▫️ SNI – полное доменное имя (FQDN) сервиса, которое должно разрешаться в IP-адрес роутера
▫️ IP Address – внутренний IP-адрес сервиса
▫️ Port – внутренний порт сервиса
▫️ Сertificate – сертификат сервиса, который мы должны выбрать из установленных на устройство сертификатов.

👉 Если поле Сertificate не заполнено, то будет использоваться сертификат назначенный службе reverse-proxy в меню IP – Service.

👆 Также начиная с ROS 7.22 появился полноценный ACME-клиент, который упрощает получение и управление сертификатами.

❗️Обратите внимание, что служба reverse-proxy конфликтует с www-ssl и вам нужно либо отключить последнюю, либо поменять используемый ей порт.

В терминале для добавления прокси используйте команды:

/ip reverse-proxy
add sni=service1.example.com ip-address=192.168.1.100 port=8080 certificate=cert1
add sni=service2.example.com ip-address=192.168.1.101 port=3000 certificate=cert2

Для роутеров архитектуры ARM, ARM64 и x86 поддерживается протокол HTTP/2. Однако явных настроек протоколов и шифров нет. Как нет и никаких дополнительных опций.

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

ACME-клиент в Mikrotik

Еще одно нововведение в выпуске RouterOS 7.22 тесно связанное с предыдущим - Reverse Proxy – теперь для получения сертификатов можно использовать полноценный ACME-клиент с поддержкой не только Let’s Encrypt, но и любых CA работающих по этому протоколу.

До этого сертификат Let’s Encrypt можно было получить командой:

/certificate enable-ssl-certificate dns-name=...

Которая имела ряд особенностей:

🔹Только один сертификат

🔹Только один домен в сертификате

🔹Сертификат автоматически привязывался к службе www-ssl

Теперь многие из этих ограничений сняты и поддерживаются:

🔹Множество ACME-клиентов

🔹 Несколько доменов в сертификате

🔹 Сертификат не привязывается к службам по умолчанию

Для его использования перейдите в System – Сertificates и нажмите Add ACME, откроется окно настройки ACME-клиента где вам потребуется заполнить поля:

▫️ Name - имя клиента ACME, укажите понятное имя, например, наименование домена или проекта, оно же будет использоваться в качестве имени сертификата.

▫️ Directory URL - URL ACME сервера (для Let's Encrypt: https://acme-v02.api.letsencrypt.org/directory)

▫️ Domain - доменное имя для сертификата, можно указать несколько, через запятую.

▫️ Поля EAB KID и EAB Key - параметры для External Account Binding (опционально, нужны для некоторых ACME провайдеров, преимущественно коммерческих).

В терминале создать ACME-клиент можно следующим образом:

/certificate add-acme \
    name=my_site \
    directory-url=https://acme-v02.api.letsencrypt.org/directory \
    domain-names=example.com,www.example.com

Сразу же после создания ACME-клиент попробует получить сертификат, а потом будет заниматься его продлением, ничего руками делать не надо.

Для назначения сертификата службе выполните команду:

/ip service set reverse-proxy certificate=my_site

В данном случае мы назначили его службе reverse-proxy, также просто можете использовать его везде, где есть возможность указать сертификат явно. Например:

/interface sstp-server server set certificate=my_site

Для работы ACME-клиента вам по-прежнему потребуется работа службы www и открытый порт 80 TCP, что вызывает у многих коллег обоснованные опасения. Поэтому рекомендуем ознакомиться с вариантами ограничения доступа к веб-интерфейсу, описанные в нашей статье (там же подробно описан старый метод получения сертификата):

✅ Работаем с сертификатами Let's Encrypt на роутерах Mikrotik (RouterOS 7)

Или принять дополнительные меры по защите:

✅ Настраиваем защиту от атак BruteForce на роутерах Mikrotik

Почему тормозит 1С. Файловый режим и Microsoft Defender

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

https://interface31.ru/tech_it/2021/12/pochemu-tormozit-1s-faylovyy-rezhim-i-microsoft-defender.html

Для того, чтобы облегчить данный процесс правильной настройки антивируса для совместной работы с 1С мы написали специальный скрипт. Что он делает?

🔹 Добавляет к исключениям расширения: 1CD, DT, CF

🔹 Добавляет в исключения пути рабочих папок 1С:

▫️ %APPDATA %\1C
▫️ %LOCALAPPDATA%\1C

🔹 Добавляет в исключения каталоги установки 1С:

▫️ %PROGRAMFILES%\1cv8
▫️ %PROGRAMFILES(x86) %\1cv8

🔹 Анализирует файл ibases.v8i и добавляет в исключения все найденные в нем файловые информационные базы.

🔹 Анализирует установленные платформы и для каждой из них создает исключения для процессов, запускаемых из директории \bin (поддерживается не всеми версиями Defender).

🔹 Создает исключения для процессов запускаемых из %APPDATA %\1C\1cv8\ExtCompT, где расположены драйвера подключаемого оборудования.

Скрипт поставляется в виде архива, который содержит собственно скрипт PowerShell и BAT-файл для его запуска. Архив следует распаковать в произвольное место и запустить BAT-файл от имени администратора.

‼️ Обновили скрипт для поддержки платформы 8.5

👇👇👇 Архив со скриптом в комментариях

Что такое passthrough в брандмауэре Mikrotik и зачем он нужен

Обсуждение в предыдущих постах показало, что далеко не все понимают назначение флага passthrough в брандмауэре.

Начнем с того, что вспомним принцип работы брандмауэра: пакет движется по цепочке пока не будет совпадения с критериями правила.

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

В таблицах nat или filter большинство действий является терминирующими, за редкими исключениями, например, добавить адрес в список.

А вот с таблицей mangle все по другому. Там у нас появляется выбор. Обычно все действия по маркировке пакетов и соединений начинаются в цепочке prerouting данной таблицы.

Хорошо, вот кинули мы марку на соединение, а дальше что? А дальше все зависит от последующей логики. Если потом эту марку мы будем использовать где-нибудь в nat или filter, то пакет можно смело терминировать. Делать в этой цепочке ему больше нечего.

А если нам нужно затем промаркировать пакеты на основании марки соединения, скажем, сделать им mark-routing, то терминировать пакет никак нельзя. С таблицей маршрутизации надо определиться здесь и сейчас, до принятия решения о маршрутизации.

И здесь нам на помощь приходит как раз passthrough, установка этой опции делает правило не терминирующим. И пакет продолжает движение по цепочке дальше.

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

Форматы сертификатов X.509 (SSL) и преобразования между ними

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

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

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

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

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

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

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

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

Сакральная желтая бумажка

С завидным постоянством наблюдем необъяснимое, можно даже сказать – сакральное отношение некоторых пользователей к пин-кодам программных лицензий 1С:Предприятие.

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

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

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

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

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

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

Также та же самая поддержка рекомендует:

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

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

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

Ну и не ждите слета лицензии, если по правилам она должна слететь. Просто переактивируйте не дожидаясь слета, а то, что она слетит – это 100%. И никакие соображения о мнимой «экономии» лицензий тут неприемлемы.

Экономить тут нечего и незачем, разве что заведомо спровоцировать остановку сервиса в самый неподходящий момент. Оно вам надо?

Удалить за девять секунд или кто виноват и что делать

В сети уже несколько дней стоит шум: ИИ-агент в Cursor за девять секунд удалил всю базу данных стартапа PocketOS вместе с резервными копиями. Подается это все как огромный косяк со стороны ИИ и вызывает воодушевление у хейтеров технологии – мол мы же вам говорили, мы вас предупреждали.

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

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

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

Но в этой истории так «удачно» сложился ряд факторов, который сделал простую ошибку катастрофической.

Основатель PocketOS Джер Крейн рассказал, что агент работал в тестовой среде и столкнулся с проблемой доступа. Вместо остановки и запроса помощи система начала искать необходимый API-токен, нашла его в стороннем файле и выполнила команду на удаление тома данных в Railway, где размещалась инфраструктура стартапа.

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

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

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

Дальше еще интереснее:

Запрос прошёл сразу, а резервные копии хранились в том же томе, поэтому исчезли вместе с основной базой.

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

Любая ошибка, отказ оборудования, атака злоумышленника – и у вас нет ничего, ни рабочего экземпляра, ни копии. Это крайне грубая ошибка, причем ошибка именно того, кто эту инфраструктуру проектировал.

Но не будем же мы в этом признаваться? Конечно же нет, поэтому у Крейна виноваты все, кроме него самого:

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

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

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

Copy Fail – как ИИ нашел дыру в ядре, с которой мы жили девять лет

Еще одна свежая новость – уязвимость Copy Fail, которая позволяет любому непривилегированному пользователю получить права root. Уязвимости подвержены все дистрибутивы на протяжении девяти последних лет.

Уязвимость вызвана логической ошибкой в crypto API ядра Linux, допущенной в 2017 году при проведении оптимизации. Ну людям свойственно ошибаться.

Ошибка выявлена при помощи AI примерно после часа экспериментов с анализом кода криптоподсистемы ядра. Проблема проявляется начиная с ядра Linux 4.14, выпущенного в 2017 году, и устранена в ядрах 6.18.22, 6.19.12 и 7.0.

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

В том же Proxmox уже сейчас доступно обновление на версию 9.1.9 с ядром 7.0

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

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

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

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

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

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

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

Насколько вреден Wi-Fi

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

Напомним, что законодательно установленное ограничения для Wi-Fi передатчиков это 100 мВт для диапазона 2,4 ГГц и 200 мВт для 5 ГГц.

Данные ограничения накладываются на эквивалентную изотропно-излучаемую мощность (ЭИИМ), которая рассчитывается с учетом коэффициента усиления антенны.

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

Если у нас есть передатчик с мощностью 20 дБм (100 мВт) и антенна с усилением 3 дБи, то ЭИИМ такой системы будет 200 мВт (23 дБм), для передатчика с мощностью 1 Вт ЭИИМ с такой антенной составит 2 Вт.

Таким образом для оборудования имеющего мощность передатчика 1 Вт и антенну с усилением 3-4 дБи мы можем смело получить ЭИИМ 2 - 2,5 Вт. И такое оборудование есть, например, некоторые модели Mikrotik (подчеркнем – именно некоторые, не все).

Закономерный вопрос- насколько это вредно. Мы нашли исследование Роспотребнадзора для домашних роутеров диапазона 2,4 ГГц, которое показало, что излучаемая ими мощность не превышает допустимой на любых расстояниях.

Для оценки воздействия излучения на организм человека используется показатель плотности потока энергии (ППЭ), который измеряется в мкВт/см2, предельно допустимым уровнем (ПДУ) для граждан является 10 мкВт/см2, для работников сферы связи – 18 мкВт/см2.

Максимальное значение ППЭ при котором допускается находиться без средств индивидуальной защиты – 1000 мкВт/см2.

Для расчета времени пребывания в местах с превышением ПДУ ППЭ существует еще один показатель - энергетическая экспозиция потока плотности энергии, предельное значение которой 200 мкВт/см2 в час.

❗️ Т.е. при значении ППЭ в 1000 мкВт/см2 там можно находиться не более 12 минут.

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

На расстоянии 50 см и ближе ПДУ ППЭ превышают передатчики с мощностью от 300 мВт выше, но если отойти уже на метр, то превышение нормы будет только у передатчика в 2 Вт.

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

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

И снова почему не надо работать на выходные и праздники

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

Сегодня произошел еще один подобный случай, в котором наш коллега получил себе целый набор проблем на ровном месте.

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

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

Четверг, 30 апреля, вечер. Офис ушел домой на все праздники, магазины закрылись. Местный админ, назовем его Вася, решил массово обновить гипервизоры Proxmox, которых там целых три штуки.

Два обновились нормально, а на третьем у Васи дрогнула рука и вместо Reboot он нажал Shutdown. Бывает…

В этот момент все еще можно было исправить, время было еще не слишком позднее, примерно 22:30, свяжись с руководителем, объясни ситуацию, попроси пропуск, там делов то на минуту.

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

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

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

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

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

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

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

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

Шеф решил, что если суетиться – так по полной и набрал нас с претензией и требованием предоставить отчет об инциденте сразу после праздников.

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

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

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

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

Проходит еще час и вечер праздничного дня окончательно перестает быть томным, звонит Вася, бьется в истерике и вопрошает – а зачем мы его так подставили?

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

Стоит ли бравировать собственным невежеством?

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

Взрослые серьезные (вроде-бы) люди начинают наперебой рассказывать про то, какой это хлам, что это совсем не IT и как они максимально дистанцированы от этого, пусть сами 1С-ники в ней и ковыряются, заодно отказывая специалистам по 1С в звании настоящих айтишников.

Мол ваша 1С – недоделанная, и сами вы недоделанные, не специалисты, не программисты и вообще сидите с краю, когда серьезные люди о серьезных вещах разговаривают.

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

И очень часто у таких товарищей видишь монолит в виде терминального сервера, на котором сразу и пользователи, и сервер 1С, и SQL-сервер в одной куче. А на вопрос «зачем?» - просто разводят руками: «Ну это же 1С…»

А дальше начинаются сплошные открытия, о том, что давно есть тонкий клиент, веб-публикация, что 1С отлично работает на Linux и т.д. и т.п.

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

А кто будет в этом виноват? Недоспециалист 1С-ник или ТруЪ-админ? На самом деле виновата будет «кривая 1С, которая нормально не умеет в сервер и ее только вот так, через костыли», ну и «тупые пользователи, которые запускают все что попало».

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

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

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

Но если мыслить рационально, то такое поведение только удивляет. На постсоветском пространстве 1С:Предприятие – стандарт учетной системы де-факто. А бухгалтерия и 1С – практически слова синонимы. 1С в том или ином виде вы встретите везде, от небольшой фирмы до крупного предприятия.

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

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

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

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

В том же проекте админ, причем опытный и достаточно грамотный дядечка лет под 50, отлично знающий Linux купил для сервера 1С Intel Xeon Silver 2,1ГГц, зато серверный, зато Xeon, все по-взрослому.

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

Вопрос, а почему не купили Ryzen R9 был сразу отвергнут, мол он не труЪ и не серверный. А на новом сервере ко всему прочему стояла «старая добрая терминалка». Занавес!

Админы сдают позиции

Классический образ ТруЪ админа рисует утро с чашки кофе и чтения логов. Где опытный специалист цепким взглядом быстро выявляет все аномалии и принимает необходимые меры.

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

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

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

И это дальше уже можно парсить, ухватившись за ниточку, но ведь ее еще нужно найти…

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

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

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

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

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

С этим можно соглашаться, можно не соглашаться, но факт остается фактом – ИИ разбирает логи значительно быстрее и эффективнее человека.

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

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

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

Для них настали плохие времена: ИИ быстрее, эффективнее и дешевле. Хотите выжить и остаться в индустрии – развивайтесь, иначе вас скоро заменит искусственный болванчик, который может даже и тупее вас, но работает 24/7 и не требует социалки и повышения заработной платы.

Бизнес – он про деньги, а не про все остальное. Если вы полезны бизнесу – бизнес готов вам платить, нет – ничего личного, до свидания.

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

Здесь должна была быть непереводимая игра слов…

Минпромторг России исключил из перечня товаров для параллельного импорта компьютерную технику и запоминающие устройства от ведущих иностранных производителей. Изменения вступают в силу 27 мая 2026 года.

В приказе ведомства № 4769 от 26 сентября 2025 года под ограничение попадают компьютеры и запоминающие устройства таких брендов, как Acer, Adata, AIC, Apacer, Asus, Cisco, Fujitsu, Hewlett Packard (HP), Hitachi, HPE, Hynix, IBM, Inspur, Intel, Kingston, Samsung, Sandisk, Toshiba, Transcend, xFusion.

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

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

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

C:\Deb - каждый сходит с ума по своему

Видели мы многое, видели мы всякое, но такое...

C:\Deb — это система Win32/Linux, созданная на базе Debian 13 и Wine, с заимствованным пользовательским пространством из ReactOS, ориентированная на беспроблемную поддержку Windows‑приложений без отказа от традиционного ПО для Linux.

И ладно бы он воспроизводил лучшие практики мира Windows, но ReactOS крайне далека как от стабильности, так и от современных технологий и развивается более как исследовательский проект, так еще стилизация под Windows 9x.

И выпустили его не на первое апреля, чтобы было бы объяснимо и воспринято с пониманием, а первого мая, в день весны и труда.

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

✅ Посмотреть своими глазами: https://github.com/cusdeb-com/os

Перенос сертификатов и закрытых ключей CryptoPro хранящихся в реестре

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

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

При переносе обычно возникает несколько проблем:

🔹 Узнать серийный номер установленного экземпляра КриптоПро
🔹 Перенести ключи расположенные в реестре
🔹 Перенести пользовательские сертификаты

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

✅ Как это сделать можно прочитать в нашей статье: https://interface31.ru/post/perenos-sertifikatov-i-zakrytyh-klyuchey-cryptopro-hranyashhihsya-v-reestre

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

👉 Скрипт состоит из двух файлов: собственно PS-скрипта и BAT-вфайла для его запуска. Поместите их в одном расположении и запустите с правами Администратора.

В результате его работы вы получите:

🔹Текстовый файл с серийным номером Крипто-Про
🔹Файл реестра с закрытыми ключами
🔹Архив с сертификатами из хранилища пользователя

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

👇👇👇 Файлы скрипта можно скачать в первом комментарии

Особенности эксплуатации CA на роутерах Mikrotik: резервное копирование, экспорт и импорт сертификатов

Mikrotik предоставляет пользователям достаточно широкие возможности, одна из них - создание на роутере собственного центра сертификации (CA), который позволяет управлять собственной инфраструктурой открытых ключей (PKI).

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

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

Коротко напомним, что такое инфраструктура открытых ключей (PKI), это область доверия, где каждый участник может доверять другому участнику, не имея никаких предварительных данных о нем. В основе PKI лежит центр сертификации (CA), авторитет CA неоспорим, а доверие к нему не подвергается сомнению.

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

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

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

Также корневой сертификат содержит адрес CRL - списка отозванных сертификатов, что позволяет дополнительно убедиться, что предъявленный сертификат не был отозван.

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

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

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

Что не так с Base64?

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

Что не так с Base64 и почему для админа его наличие является своеобразной красной тряпкой. Начнем с того, что такое вообще Base64 — это стандарт кодирования двоичных данных при помощи только 64 символов ASCII.

Изначально Base64 использовался для передачи вложений посредством текстовых сообщений в электронной почте и продолжает широко использоваться для подобных целей сейчас.

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

А теперь представьте себе, что в скрипте или где-то еще вам встретилась команда:

eval "$(echo c3VkbyBhcHQgdXBkYXRlIC15ICYmIHN1ZG8gYXB0IGZ1bGwtdXBncmFkZSAteQ== | base64 -d)"

Ничего не понятно, но очень интересно. Вы знаете, что она обозначает? Можете быстро сказать безопасно ли запустить это или нет?

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

В данном случае ничего страшного тут нет, просто закодировано:

sudo apt update -y && sudo apt full-upgrade -y

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

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

Поэтому увидев Base64 там, где его в принципе не должно быть: скрипте, тексте веб-страницы, выполняемых командах – сразу следует насторожиться и, лучше всего, отказаться от выполнения. Либо тщательно проверить что именно там закодировано и сделать выводы.

Самохостинг

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

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

Поэтому, когда мы говорим о хостинге, то основным требованием к нему является доступность. У хостеров одним из основных параметров является SLA (Service Level Agreement или соглашение об уровне сервиса), который регламентирует допустимое время простоя и обычно его значения начинаются с 95-99%.

На самом деле это достаточно большие цифры, так 95% допускает простой 18,25 суток в год, а 99% - 3,65 суток.

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

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

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

Ок, давайте просто прикинем. Сервер из неоткуда не берется, его надо купить. Давайте прикинем стоимость платформы на N100 с дисками на 1 ТБ.

Такая машинка по актуальным ценам обойдется плюс-минус в 60 000 рублей.

Определим ей срок полезного использования в пять лет. В результате получим стоимость владения (не считая затрат на содержание) в размере 12 000 рублей в год или 1 000 рублей в месяц.

1 ТБ на Яндекс Диске стоит без скидок 250 руб./мес., со скидками еще меньше, и голова не болит.

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

При этом у вас больше не болит голова насчет всей этой кухни. А болеть там на самом деле есть чему.

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

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

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

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

Ну или это будет стоить совсем других денег…

При этом не забываем, что наше оборудование коптит небо, расходует ресурс, стареет, что рано или поздно потребует его замены. У хостера это делает сам хостер, вы просто оплачиваете услугу по тарифу.

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

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

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

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

В остальном самохостинг – это дорого и ненадежно. Оправдан только если вы просто хотите в это все поиграться с целью получить некоторый опыт.