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

​​Жизнь и приключения молодого и перспективного хостинга. Серия, скорее всего, последняя

Сегодня в СМИ проскочила достаточно интересная новость: были арестованы гендиректор небезызвестного хостинга Аеза Юрий Бозоян и его учредитель Арсений Пензев.

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

🔹 https://t.me/interface31/1699

🔹 https://t.me/interface31/1701

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

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

🔹 https://t.me/interface31/1600

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

И вот сегодня получаем сообщение об аресте директора, учредителя и еще ряда сотрудников хостера. Первоначально информация не совсем понятна, вроде бы инкриминируется ч. 2 ст. 172 УК РФ, а говоря простым языком – обнал.

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

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

Тем более что сам термин «отмыв» пришел к нам из США, где в 20-х годах прошлого века мафия для легализации средств использовала автоматические прачечные.

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

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

В итоге нашим фигурантам предъявили:

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

Статья 210. Организация преступного сообщества (преступной организации) или участие в нем (ней)
2. Участие в преступном сообществе (преступной организации)

Статья 228.1. Незаконные производство, сбыт или пересылка наркотических средств, психотропных веществ или их аналогов, а также незаконные сбыт или пересылка растений, содержащих наркотические средства или психотропные вещества, либо их частей, содержащих наркотические средства или психотропные вещества
4. Деяния, предусмотренные частями первой, второй или третьей настоящей статьи, совершенные:
а) организованной группой;
г) в крупном размере

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

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

Ну и срока там по совокупности от 15 до 20 лет. Ну самое оно, в 21 присядет, в 41 выйдет, это о нашем молодом даровании. Отличный жизненный старт, хотя были и возможности и перспективы…

Раз уж подняли эту тему в обсуждениях еще раз напомню:

Mikrotik и несколько провайдеров. Резервирование каналов

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

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

https://interface31.ru/tech_it/2023/03/mikrotik-i-neskol-ko-provayderov-rezervirovanie-kanalov.html

​​Про домашний Wi-Fi, роутеры и Mikrotik

В конце 2023 года я серьезно обновил ядро домашней сети поставив туда вместо RB 2011 новый hAP ax2. Переход с ROS 6 на ROS 7 прошел не без вопросов, но достаточно гладко. Кроме Wi-Fi с которым я просто не стал тогда разбираться. Беспроводную сеть продолжил тянуть двухдиапазонный TP-Link.

В этом году, вернувшись из новогоднего отпуска я решил дать Wi-Fi на Mikrotik новую жизнь и все-таки попытался настроить Wave2, тем более что в кои-то веки в Mikrotik поставили адекватное железо с поддержкой Wi-Fi 6 (AX).

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

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

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

Но свежо предание, да верится с трудом. Практика показала, что заставить работать канал на 160 МГц никак не удалось, а при использовании 80 МГц так и не получилось добиться стабильной связи. Что сильно отравляло жизнь при тех же голосовых и видеозвонках в мессенджерах и прочих подобных задачах.

И снова курим настройки, меняем частоты, параметры, снова курим, снова меняем. Ну кое как стабильной работы на 80 МГц вроде добились. Только вот все тоже самое обеспечивал относительно старенький AC TP-Link, который просто настраивался в два тычка.

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

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

В общем, анализ эфирной ситуации показал, что у кого-то из соседей появился новый роутер, который светится в 5 ГГц как новогодняя елка, выбивая клиентские устройства на кухне в более стабильный 2.4 ГГц с более мощным сигналом, но крайне тоскливой скоростью – 10-15 Мбит/с как норма жизни.

В целом стало понятно, что проверку практикой Wave2 от Mikrotik не прошел и было принято решение сделать все проще и дешевле. Анализ рынка выявил, что наиболее интересными по соотношению цена-возможности являются устройства на MediaTek Filogic 820, в частности Xiaomi Router AX3000T.

Два таких устройства на маркетплейсах обошлись примерно в 6 500 руб. Пришла версия RD03 - материковый Китай. Весь веб-интерфейс на китайском, но, если настраивать через приложение – русский язык есть, не везде, но в основном.

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

В кухне лучше не стало, устройства также периодически перескакивали в 2,4 ГГц и поэтому в ход пошел второй роутер. Создать Mesh-сеть по проводу проще простого, включаем ведомый роутер патч-кордом в WAN-порт и нажимаем на нем кнопку Mesh, если в сети есть уже настроенный роутер, то он автоматически конфигурирует ведомый и включает его в единую сеть.

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

Корпоративное применение? Так там есть Uni-Fi и Omada, которые проще и на голову выше.

​​Предсказуемые имена сетевых интерфейсов systemd

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

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

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

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

Другой применяемый подход – biosdevname, в этом случае ядро пыталось считать из BIOS топологию сетевого устройства по принципу порт – индекс – слот и на этом основании присваивать сетевые имена.

Недостаток данного подхода - он полностью неприменим для не x86 устройств.

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

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

Она состоит из нескольких политик:

1️⃣ Имена, включающие индексные номера прошивки/BIOS для встроенных устройств (например: eno1)

2️⃣ Имена, включающие индексные номера слотов PCI Express, предоставленные прошивкой/BIOS (например: ens1)

3️⃣ Имена, включающие физическое/географическое расположение разъема оборудования (например: enp2s0)

4️⃣ Имена, включающие MAC-адрес интерфейсов (например: enx78e7d1ea46da)

5️⃣ Классическое, непредсказуемое именование ethX, встроенное в ядро (например: eth0)

Выбор имени происходит следующим образом: политика 3 если она применима и доступна, иначе переход к политике 2, от нее к политике 1. Если не одна политика не подходит, то применяется политика 5.

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

Политика 5 применяется только в крайнем случае. Это означает, что, если в системе установлено имя biosdevname, оно будет иметь приоритет. Если пользователь добавил правила udev, которые изменяют имена устройств ядра, они также будут иметь приоритет. Кроме того, любые схемы именования, специфичные для дистрибутива, также будут иметь приоритет.

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

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

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

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

Подключаем диск из NAS в Linux, или монтирование RAID и LVM разделов

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

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

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

https://interface31.ru/tech_it/2022/04/podklyuchaem-disk-iz-nas-v-linux-ili-montirovanie-raid-i-lvm-razdelov.html

​​Spamhaus RBL/DNSBL и публичные DNS сервера

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

Если вы используете один из таких серверов, то получить доступ к спискам RBL/DNSBL не получится и, в зависимости от настроек почтового сервера, вы можете столкнуться с невозможностью приема или отправки почты, в логах при этом будет следующее сообщение:

blocked using zen.spamhaus.org; Error: open resolver

Некоторые пугаются и начинают считать, что их адрес попал в списки, но это не так, строка Error: open resolver говорит именно о том, что вы используете DNS-сервер заблокированный Spamhaus.

Как быть? Официально предлагается получить специальный DQS (Data Query Service) ключ в поддержке Spamhaus и использовать его.

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

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

​​Большинство администраторов знают про опции DHCP и про то, что с их помощью можно передать на клиент много чего интересного.

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

Однако есть одна тонкость. Опции всегда запрашиваются клиентом и в ответ сервер передаст именно то, что клиент запросил. Если клиент не запрашивает опцию, то добавлена она на сервер или нет - значения не имеет.

Состав запрашиваемых опций передается серверу в опции 55, на скриншоте ниже можно сравнить запрашиваемые опции в Linux и Windows. Например, Linux запрашивает опцию 42 - NTP сервер, а Windows нет.

Подробнее про работу DHCP читайте в нашей статье:

https://interface31.ru/tech_it/2019/07/kak-ustroen-i-rabotaet-protokol-dhcp.html

​​Чем отличаются DHCP Option 015 (DNS Domain Name) и DHCP Option 119 (Domain Search List)

Не так давно в обсуждениях снова всплыли плоские имена и связанные с ними проблемы.

Что такое плоское имя? Это имя компьютера из одного слова, например, SERVER-01 или PC-003.

Чтобы обратиться к компьютеру по сети, мы должны преобразовать (разрешить) его имя в IP-адрес. Для плоского имени это можно сделать только при помощи широковещательных протоколов сетевого обнаружения или WINS-сервера.

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

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

В тоже время задачу разрешения имен призван решать DNS-сервер, но он не работает с плоскими именами, точнее DNS-клиент дополнит плоское имя до FQDN следующим образом:

SERVER-01.

Что обозначает домен первого уровня SERVER-01, аналогичный RU или COM. Естественно, такой зоны на вашем DNS-сервере найдено не будет и поиск закончится неудачей.

Поэтому нужно научить DNS-клиент правильно дополнять плоские имена до FQDN и для этого предназначена опция DHCP 015 (DNS Domain Name), которая задает имя домена используемое при разрешении имен на DNS-сервере. Также ее часто называют DNS Suffix.

Если мы передали в этой опции домен example.office, то любое плоское имя будет дополнено как:

SERVER-01. example.office.

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

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

http://webserver-005/otchet.pdf

Где указанное плоское имя соответствует веб-серверу филиала на хуторе Гадюкино который использует домен example.gadykino.office.

Как быть в таком случае? Опция 015 не предусматривает передачу нескольких имен, хотя некоторые реализации DHCP-клиентов в Linux умеют разбирать строку, состоящую из нескольких значений.

Поэтому была введена опция DHCP 119 (Domain Search List), которая содержит список доменов используемых для разрешения имен, теперь мы можем передать в нем как example.office, так и example.gadykino.office.

DNS-клиент будет выполнять поиск в порядке следования доменов в списке, поэтому «родной» домен указывайте первым.

Таким образом опции 015 и 119 фактически выполняют одно и то же действие. Только 015 передает единственный домен, а 119 – список доменов.

Что будет, если опции 015 и 119 указаны одновременно? Стандарты не описывают данную ситуацию, поэтому все отдается на откуп конкретной реализации DHCP-клиента.

Общая рекомендация: указывать домен из опции 015 первым в списке доменов опции 119.

Какую из них использовать? Если домен поиска один, то используйте 015, это обеспечит наибольшую совместимость с оборудованием и ПО. Если несколько, то 119.

В доменных сетях от использования опций DHCP 015 и 119 лучше отказаться и настроить домены поиска через GPO используя политику Computer Configuration -> Administrative Templates -> Network -> DNS Client and open DNS Suffix Search List.

Ansible в действии: развернем кластер с Kuberspray и запустим AI-приложение 🚀

Приглашаем на бесплатный вебинар от Слёрма, на котором расскажем и покажем:

🔸 Как развернуть нейронную сеть в контейнере и сделать её доступной для всего мира?
🔸 Как быстро настроить кластер и управлять им?
🔸 Как Kubernetes управляет AI-приложениями?
🔸 Как Docker работает в Kubernetes?

🎁 Бонус: каждый зритель получит репозиторий для собственного Kubernetes-кластера с AI-приложением и полную инструкцию по развертыванию.

Дата: 9 апреля 19:00
Занять место — через бота 👈

erid: 2W5zFJxjGB2

​​Однострочный веб-сервер на Bash

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

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

И в этом нам поможет команда netcat (nc), мы не будем подробно разбирать ее применение, а просто покажем примеры.

Например, мы хотим видеть свободную память:

while true;
  do echo -e "HTTP/1.1 200 OK\n\n$(free)" \
  | nc -l -k -p 8080 -q 1; 
done

Здесь следует обратить внимание на опции -p – порт и q – время в секундах до закрытия соединения, если у вас там выполняется сложная команда, то возможно его придется увеличить.

Таким же образом можно просматривать логи:

while true;
  do echo -e "HTTP/1.1 200 OK\n\n$(tail -n 15 logfile)" \
  | nc -l -k -p 8080 -q 1; 
done

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

cmd1=$(free) 
cmd2=$(ss -tpln)
body="$cmd1\n$cmd2"
 
while true;
  do echo -e "HTTP/1.1 200 OK\n\n$body" \
  | nc -l -k -p 8080 -q 1; 
done

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

while true; do { \
  echo -ne "HTTP/1.1 200 OK\r\n"; sh my_script.sh; } \
  | nc -l -k -p 8080 -q 1; \
done

Просто? Да. Удобно? Да. И только bash и никаких дополнительных инструментов!

Вышла бета-версия Ubuntu 25.04

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

По сути, 25.04 типичный промежуточный релиз – что могли обновить, то обновили. Где хотели что-то добавить – добавили, изменить – изменили.

Из важного – добавлена поддержка Dracut для формирования образов начального RAM-диска (initrd). Сейчас этим занимается initramfs-tools, в осеннем выпуске 25.10 планируется использовать Dracut по умолчанию.

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

​​Про бумажки

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

Что делать, если руководство или заказчики игнорируют потребности IT и требуют работать на том, что есть? Как обезопасить себя? Каким образом снять ответственность?

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

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

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

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

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

А вот и нет. Самая плохая ситуация, когда сложившаяся ситуация однозначно попадет под одну из статей скучной книжки с названием Уголовный кодекс.

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

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

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

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

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

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

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

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

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

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

Поэтому – просто не работайте с чудаками на букву «м».

​​За героизм нам не платят

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

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

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

В нашей отрасли – это накопление критической массы ошибок, недоработок, халатного отношения и прочего, прочего, прочего.

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

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

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

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

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

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

Таких причин можно найти множество и именно их накопление провоцирует в критической ситуации уже упомянутую нами лавину.

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

Обычно это начинается так: нам нужно…

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

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

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

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

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

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

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

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

А если делали, то вам и отвечать. А что не выделили, так это вы не объяснили и не довели.

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

​​Зависимости DEB-пакетов

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

Начнем с того, что низкоуровневым пакетным менеджеров в DEB-системах является dpkg, именно он занимается распаковкой и установкой пакетов. Упрощенно говоря, установка пакета состоит из двух этапов: распаковки и настройки.

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

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

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

Посмотреть зависимости можно командой:

apt-cache depends package_name

И чтобы правильно понимать ее вывод давайте разберем какие именно типы зависимостей существуют:

▫️ Предзависит (Pre-Depends) – означает критическую зависимость пакета А от пакета Б, которая требует строгой последовательности распаковки, если данная зависимость не удовлетворена, то dpkg даже не будет пытаться распаковать пакет А.

▫️ Зависит (Depends) – для работы пакету А обязательно требуется пакет Б, также могут выдвигаться требования к версии пакета, например, не ниже чем. Данные зависимости автоматически разрешаются через apt или apt-get. Если при установке зависимость отсутствует, то dpkg распаковывает пакет, но оставляет не настроенным.

▫️ Рекомендует (Recommends) – не является обязательной, но сопровождающий пакета считает, что большинство сценариев использования пакета А потребуют пакет Б, установка производится вручную при необходимости.

▫️ Предлагает (Suggests) – обычно это пакеты, расширяющие функциональность пакета А или просто используемые с ним совместно. Также не являются обязательными, но ознакомиться с ними будет полезно.

▫️ Конфликтует (Conflicts) – обозначает что пакет А не может работать одновременно с пакетом Б, чаще всего конфликт происходит в тех случаях, когда А содержит обновленные компоненты пакета Б. Часто используется совместно с Заменяет.

▫️ Заменяет (Replaces) – в этом случае файлы пакета Б удаляются или замещаются файлами пакета А.

▫️ Ломает (Breaks) – означает, что нельзя настроить пакет А, если в системе установлен и настроен пакет Б, в этом случае dpkg предотвращает установку пакета. Для его установки нам потребуется вручную удалить пакет Б.

▫️ Предоставляет (Provides) – это значит, что все функции пакета Б предоставляются пакетом А, т.е. пакет его полностью поглощает. Изучение данных зависимостей может быть полезно для контейнеров или встраиваемых систем, когда вам не нужны все функции пакета А и вы можете заменить их легковесным Б.

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

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

Часто задают еще один вопрос: стоит ли установить зависимости вручную или отдать это на откуп apt? Действительно, во многих инструкциях зависимости явно перечислены в команде на установку.

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

​​Завершающий слеш в путях Linux

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

В Linux символом разделения каталогов является слеш, если после имени файла стоит этот символ, то подразумевается, что данный файл является каталогом. А в Linux, как мы помним, всё есть файл.

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

~/video

Может быть как файлом, так и каталогом. Если же мы напишем так, то перед нами предположительно каталог:

~/video/

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

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

Например, в нашем скрипте написано в цикле что-то вроде:

mv -f “$file” /new_path/video

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

Если же мы напишем:

mv -f “$file” /new_path/video/

То при отсутствии директории получим ошибку:

mv: невозможно создать обычный файл ' video/': Это не каталог

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

mv: не удалось получить доступ к ' video /': Это не каталог

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

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

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

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

Поэтому в скриптах такие вещи всегда лучше проверять явно, например:

if ! [ -d /new_path/video/ ]; then
   mkdir /new_path/video
fi

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

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

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

​​И на старуху бывает проруха

Трой Хант (Troy Hunt), известный деятель в области компьютерной безопасности, автор курсов по защите информации, создатель сервиса проверки скомпрометированных паролей "Have I Been Pwned?" и региональный директор Microsoft, раскрыл сведения об утечке базы пользователей собственного списка рассылки. История показательна тем, что даже признанные специалисты в области компьютерной безопасности могут стать жертвами типового фишинга при определённом стечении обстоятельств.

Трою пришло письмо от имени сервиса Mailchimp c предупреждением о приостановке работы его списка рассылки и необходимости выполнения определённых проверок. Трой перешёл по ссылке в письме, ввёл на открывшейся странице параметры учётной записи в Mailchimp, подтвердил запрос двухфакторной аутентификации и страница зависла...., а атакующие получили доступ к пользовательской базе его списка рассылки и выгрузили сведения о email и IP-адресах 16627 подписчиков. Примечательно, что в выгрузку вошли 7535 адресов пользователей, ранее отписавшихся от рассылки, но сервис Mailchimp сохранил их несмотря на отписку и включил в экспортируемые данные.

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

Вторым фактором стало то, что письмо вначале было просмотрено на iPhone с почтовым клиентом Outlook, который показал только имя отправителя и не отобразил email. Затем, когда письмо было повторно открыто утром на компьютере, Трой не стал перепроверять параметры и не обратил внимание на то, что письмо отправлено с подозрительного адреса "hr@group-f.be".

Текст был стилизован под стандартное сообщение Mailchimp и предупреждал об ограничении отправки рассылки из-за получения жалобы на спам. Информация была подана ровно в той мере, чтобы вызвать беспокойство, но не переусердствовать. В письме предлагалось проверить недавно отправленные рассылки и предпринять действия для разблокировки. По ссылке вместо mailchimp.com открылся сайт mailchimp-sso.com. Менеджер паролей 1Password автоматически не заполнил форму входа, но и это было проигнорировано. После зависания формы аутентификации Трой очнулся и перезашёл на реальный сайт Mailchimp, но было уже поздно - атакующие использовали захваченные учётные данные для получения токена для доступа к API и выполнили экспорт информации.

✅ Источник: https://www.opennet.ru/opennews/art.shtml?num=62964

​​О радиомостах

В свете материала о нормативном регулировании Wi-Fi неизбежно всплывает вопрос о радиомостах.

Бытуют распространенные заблуждения, что радиомосты можно поднимать над своей территорией, только в диапазоне 2,4 ГГц или только в диапазоне 5 ГГц и много всего такого прочего.

Но увы, радиомосты без регистрации незаконны в любом виде. Абсолютно в любом.

Чтобы понять откуда ноги растут вернемся к Постановлению Правительства РФ от 20.10.2021 N 1800 "О порядке регистрации радиоэлектронных средств и высокочастотных устройств", а именно пункту 14 приложения Изъятия из перечня радиоэлектронных средств и высокочастотных устройств, подлежащих регистрации.

Этот пункт прямо гласит, что регистрации не требует:

Пользовательское (оконечное) оборудование передающее, включающее в себя приемное устройство, малого радиуса действия семейства стандартов IEEE 802.11 (Wi-Fi), работающее в полосе радиочастот 2400 - 2483,5 МГц, с допустимой мощностью излучения передатчика не более 100 мВт, в том числе встроенное либо входящее в состав других устройств.

Пользовательское (оконечное) оборудование передающее, включающее в себя приемное устройство, малого радиуса действия семейства стандартов IEEE 802.11 (Wi-Fi), работающее в полосах радиочастот 5150 - 5350 МГц и 5650 - 6425 МГц, с допустимой мощностью излучения передатчика не более 200 мВт, в том числе встроенное либо входящее в состав других устройств.

Начнем с формулировки Пользовательское (оконечное) оборудование, для этого заглянем в Федеральный закон от 07.07.2003 N 126-ФЗ "О связи", статья 2, п. 10:

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

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

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

Таким образом никаких иных оговорок в законе, которые бы предоставляли лазейки нет.

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

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

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

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

А именно пункта 2:

Использование без регистрации радиоэлектронного средства и (или) высокочастотного устройства, подлежащих регистрации, -

влечет наложение административного штрафа *на граждан* в размере *от пятисот до одной тысячи рублей* с конфискацией радиоэлектронных средств … или без таковой;
*
на должностных лиц - от одной тысячи до двух тысяч пятисот рублей*;

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

*на юридических лиц - от десяти тысяч до двадцати тысяч рублей* с конфискацией радиоэлектронных средств … или без таковой.

Отягчающими обстоятельствами считаются:

1) совершение длящегося административного правонарушения, продолжительность которого превышает три месяца;

2) создание в результате совершения административного правонарушения радиопомех радиоэлектронным средствам других пользователей радиочастотным спектром.

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

​​И снова вой на болотах

Начнем с новости:

Начиная с 11 марта встроенный в ОС Windows антивирусный пакет Windows Defender начал блокировать (помещать в карантин) свободный драйвер WinRing0. Драйвер используется для получения доступа из пространства пользователя к различному оборудованию, для которого не предусмотрено другого API в системе.

Драйвер WinRing0 востребован в проектах, управляющих настройками оборудования, как свободных (OpenRGB, Libre Hardware Monitor, FanControl), так и проприетарных (SignalRGB, Razer Synapse 3). Среди программ, использующих драйвер, есть официальное ПО от десятков производителей оборудования, в том числе популярных. Стоит отметить, что драйвер был подписан самостоятельно автором (разработчиком CrystalDiskMark) и принят Microsoft.

Отмеченная Microsoft проблема, из-за которой произведена блокировка, связана с тем, что доступ к установленному в системе драйверу может получить любая программа, и посредством драйвера программа может манипулировать любым устройством в системе или повысить свои привилегии (CVE-2020-14979).

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

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

В целом имя данного драйвера наглядно об этом говорит - Ring0 – нулевое кольцо защиты – режим, в котором работает ядро ОС.

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

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

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

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

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

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

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