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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как я за 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/

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

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

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

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

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

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

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, в то время как это один из важнейших показателей при анализе проблем с производительностью.

Жизнь и необычайные приключения 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.

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 будет добавлена секция для обратного проксирования вашего сервиса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так в 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

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

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

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

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

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

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

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