AnyDesk похоже всё…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Либо, переложив эту функцию на заказчика вы тут же станете оператором связи без лицензии.

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

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

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

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

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

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

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

По мотивам реальных событий

▫️ Вася решил мониторить температуру произвольных устройств.

▫️ Вася решил использовать для этого sensors

▫️ Вася добавил в конфигурацию агента Zabbix примерно следующие строки:

UserParameter=lm.nvme0Temperature,sensors | tail -n 3 | head -n 1 | awk -F'[:+°]' '{avg+=$3}END{print avg/NR}'

UserParameter=lm.nvme1Temperature,sensors | tail -n 8 | head -n 1 | awk -F'[:+°]' '{avg+=$3}END{print avg/NR}'

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

❓Что не так сделал Вася?

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

▫️ Начало понятно, он вызывает команду sensors и потом колдует над ее выводом, передавая его по конвейеру.

▫️ Обработка начинается с команды tail, которая берет указанное количество строк от конца вывода. В нашем случае это три или восемь.

▫️ Этот результат передаем команде head, которая берет оттуда первую переданную строку. Таким образом у нас остается только третья или восьмая строка от конца.

▫️ Затем это все передается команде awk, где и происходит основная магия.

🔹 -F'[:+°]' – делим строку по указанным разделителям, искомое нами значение является третьим полем, так как располагается между плюсом и градусом.

🔹 {avg+=$3} – суммируем третье поле от всех строк в файле, эта конструкция перекочевала сюда из вышестоящей директивы для процессора, где в выводе не было общей температуры, но была температура по ядрам. В итоге мы отбирали количество строк по числу ядер и выводили среднюю.

🔹 END{print avg/NR} – выводит среднее значение разделенное на количество строк в стандартны поток ввода-вывода.

👆 В целом – магия грамотная и особых вопросов к ней нет. Но! Ошибочен сам принцип парсинга вывода команды sensors. Дело в том, что он зависит от количества сенсоров и выводимой ими информации.

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

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

Как быть? Используйте grep. Находим вывод именно нашего сенсора и начинаем плясать он его имени. Допустим у нас есть:

nvme-pci-0100
Adapter: PCI adapter
Composite:    +37.9°C  (low  =  -0.1°C, high = +114.8°C)
                       (crit = +119.8°C)

Нас интересует третья строка, в которое находится искомая температура, поэтому пишем:

sensors | grep nvme-pci-0100 -A 2

Которая выведет нам строку с вхождением и еще две после. Затем откусим нижнюю строку через tail:

sensors | grep nvme-pci-0100 -A 2 | tail -n 1

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

sensors | grep nvme-pci-0100 -A 2 | tail -n1 | awk -F'[:+°]' '{print $3}'

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

Маска /31

Если говорить о современных сетях, то там хватает достаточно интересных особенностей. Одной из них являются сети с маской /31.

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

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

А давайте немного отойдем в сторону и вспомним о существовании таких соединений как точка-точка (Point-to-Point, PtP).

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

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

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

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

Если у вас таких соединений единицы, ну или даже десяток – то особой проблемы нет. Вы можете щедрой рукой раздавать PtP линкам хоть /24 сети из серых диапазонов (одного диапазона 10.0.0.0/8 хватит надолго).
Но все меняется если вы становитесь крупным провайдером или испытываете ограничения в используемом адресном диапазоне.

Минимальная сеть на 2 хоста – сеть /30, но при этом она ужасно неэффективна с точки зрения расходования адресного пространства. На два адреса сети у нас теряется еще два адреса на саму сеть и широковещание. В итоге мы теряем половину адресного пространства на служебные нужды.

Чтобы этого избежать в далеком 2000 году был принят стандарт RFC 3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links разрешающий использовать сети /31 для соединений точка-точка.

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

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

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

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

Единственной существующей проблемой для сетей /31 является их поддержка со стороны производителей оборудования, особенно класса SOHO и не только.

К примеру, нормальная поддержка /31 отсутствует в оборудовании Mikrotik, хотя возможность такого использования есть, хоть и не очень очевидная.

VPN и шифрование

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

Любимое народное развлечение – это накрутить на туннель шифров, да побольше, да посильнее. Особенно любят баловаться этим на Mikrotik.

И мы сейчас не про VPN для удаленного доступа, а про тот который пойди туда не знаю куда. После чего сразу поступают вопросы – а чего это все так медленно?

Вот здесь и хочется спросить: а что и от кого вы шифруете? И зачем?

Безопасность на уровне приложений решается с помощью SSL (HTTPS) и это действительно надежно.

Хотим приватности от провайдера - добавляем DNS over HTTPS и этого достаточно.

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

Здесь хватит простого и быстрого шифра и нет никакого смысла во всяких AES-256 + SHA-512. Разве что дома холодно, и вы решили погреться от роутера.

Еще раз про Load Average и логические / виртуальные ядра

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

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

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

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

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

Если мы возьмем некоторое время, а при вычислении LA берется промежуток из 5000 тиков, то это самое количество тиков мы можем принять за 100% или единицу.

Таким образом значение 1 для LA означает, что все тики были отданы процессам, но очереди не возникло. А если LA = 0.25 – то это значит, что процессы использовали только четверть доступных тиков.

А если процессов больше, чем доступных тиков? Возникает очередь и LA начинает принимать значения выше единицы. При этом LA > 1 вовсе не означает недостатка именно процессорных ресурсов, процесс может не использовать свой тик по причине ожидания, например, дискового ввода вывода.

Таким образом тормозная дисковая подсистема также может сильно увеличить значение LA при фактическом простое процессора.

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

Что будет если мы добавим еще одно ядро, не важно физическое, логическое или виртуальное. У нас появятся еще 5000 тиков и полной нагрузке на систему будет соответствовать LA = 2.

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

Но теперь за одну и ту же единицу времени доступ к CPU получат уже не 5 000, а 10 000 процессов. А, как известно, лучше плохо ехать, чем хорошо стоять.

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

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

Настраиваем Uptime Kuma с обратным прокси-сервером Caddy и TLS-защитой

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

Традиционно это решается при помощи Certbot и Nginx, но есть способ проще – веб-сервер Caddy, который крайне прост в настройках и показывает отличную производительность при скромном потреблении ресурсов.

В целом особой проблемы запустить связку Uptime Kuma и Caddy нет, но всегда полезно читать официальную документацию. Так в документации Uptime Kuma мы нашли отсылку к проекту Caddy-Docker-Proxy, который работает с контейнерами Docker при помощи меток.

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

Интересно? Тогда приступим. Нам потребуется следующий docker-compose.yml

networks:
    default:
        name: "proxy_network"
services:
    uptime-kuma:
        image: louislam/uptime-kuma:1
        restart: unless-stopped
        volumes:
            - /srv/uptime:/app/data
        labels:
            caddy: uptime.example.com
            caddy.reverse_proxy: "* {{upstreams 3001}}"
    caddy:
        image: "lucaslorentz/caddy-docker-proxy:ci-alpine"
        ports:
            - "80:80"
            - "443:443"
            - "443:443/udp"
        volumes:
            - /var/run/docker.sock:/var/run/docker.sock:ro
            - /srv/caddy/:/data
        restart: unless-stopped
        environment:
            - CADDY_INGRESS_NETWORKS=proxy_network

Все, что вам потребуется в нем поменять – это вместо uptime.example.com указать свой домен.

После чего просто делаем

docker compose up -d

И переходим в браузере по указанному адресу.

Если вам нужно использовать этот же контейнер Caddy для других контейнеров, то просто добавьте к нему метки:

caddy: service.example.com
caddy.reverse_proxy: "* {{upstreams 8080}}"

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

Имитация плохого канала в Mikrotik

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

Это легко сделать на оборудовании Mikrotik при помощи опции Random в правилах брандмауэра. Допустимые значения от 1 до 100, которые указывают вероятность срабатывания правила в процентах.

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

Самый простой пример:

add action=drop chain=forward in-interface=bridge1 out-interface=ether5 random=3

Данное правило будет блокировать случайным образом 3% проходящих через него пакетов.

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

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

Самозаверенные сертификаты. Мифы и реальность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выдача адресов клиентам в OpenVPN

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

По умолчанию, если не указано иных настроек, OpenVPN выдает адреса динамически из диапазона совпадающего с подсетью сервера, указанной в директиве:

server 10.8.0.0 255.255.255.0

В данном случае сервер возьмет себе первый адрес в сети – 10.8.0.1, а клиенты будут получать адреса из диапазона 10.8.0.2 – 10.8.0.254.

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

ifconfig-pool 10.8.0.100 10.8.0.199

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

Но как быть, если мы хотим выдать клиенту постоянный IP-адрес? Можно воспользоваться файлом CCD (Client Configuration Directory), где хранятся персональные инструкции для подключившегося клиента, добавьте туда:

ifconfig-push 10.8. 0.5 255.255.255.0

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

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

Чтобы ее активировать добавьте в конфигурационный файл сервера опцию:

ifconfig-pool-persist ipp.txt

Теперь при каждом подключении клиента OpenVPN считывает его имя – поле CN в сертификате и просматривает файл ipp.txt на предмет наличия записи с указанным CN.

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

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

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

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

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

Что будет, если указанный в CCD адрес уже занят? OpenVPN выдаст первый свободный и занесет запись в ipp.txt. А если окажется занят адрес, указанный в ipp.txt, то поиск по файлу продолжится и если там есть вторая запись, то будет выдан указанные в ней адрес. Нет – снова первый свободный с созданием дубля записи.

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

DH Group на роутерах Mikrotik

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

Начнем с начала. Алгоритм Диффи-Хеллмана, названный так по именам его разработчиков, применяется для реализации совершенной прямой секретности (PFS).

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

Почему Диффи-Хеллман? Потому что данный протокол позволяет сторонам сформировать общий ключ шифрования не передавая его по каналам связи. Подробнее об этом можете прочитать в нашей статье:

🔹 Введение в криптографию. Общие вопросы, проблемы и решения

Но вернемся к нашим Микротикам. В настоящий момент поддерживаются следующие Группы Диффи-Хеллмана:



Group 1    768 bits MODP group
Group 2    1024 bits MODP group
Group 3    EC2N group on GP(2^155)
Group 4    EC2N group on GP(2^185)
Group 5    1536 bits MODP group
Group 14   2048 bits MODP group
Group 15   3072 bits MODP group
Group 16   4096 bits MODP group
Group 17   6144 bits MODP group
Group 18   8192 bits MODP group
Group 19   256 bits random ECP group
Group 20   384 bits random ECP group
Group 21   521 bits random ECP group
Group 31   256 bits Curve25519 


Все группы делятся на использование модульного экспоненциального алгоритма - MODP или эллиптических кривых - EC, последние являются предпочтительными.

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

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

Последние рекомендации советуют для 128-битных шифров использовать группы 19 и 20, а для 256-битных и выше - 21 группу.

Несколько особняком стоит 31 группа на эллиптической кривой Curve25519, которая обладает более высокой скоростью работы и безопасности чем аналогичная 256-битная кривая NIST P-256 группы 19.

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

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

Как правильно «лечить» файловые базы 1С:Предприятие

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

В частности это фронтовые решения для торговли и общепита, такие как 1С:РМК или 1С:Касса, которые вообще не предусматривают клиент-серверный режим работы, а также и более взрослые конфигурации: 1С:Розница или 1С:РМК в режиме РИБ в качестве рабочего места кассира или локальной базы торговой точки.

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

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

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

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

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

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

Более подробно про Тестирование и исправление вы можете прочитать в нашей статье:

🔹 Тестирование и исправление информационной базы - что делает и для чего нужно

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

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

Бесплатно: 5 дней Python для новичков → 4 мини-проекта 🐍
Телеграм-боты, парсер данных в таблицу и простой сайт. Без математики, только практика.

Запись до 15 марта → тут
Реклама. ЧОУ ДПО "ОБРАЗОВАТЕЛЬНЫЕ ТЕХНОЛОГИИ "СКИЛБОКС (КОРОБКА НАВЫКОВ)". ИНН 9704088880.

Эволюция энергосбережения в архитектуре x86 или что такое ACPI

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

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

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

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

Если мы снизим на 25% частоту процессора на такое же значение снизится и потребление. А вот при снижении на 25% напряжения мы получим уже 44% экономии, а снизив одновременно и частоту, и напряжение получим целых 58% снижения потребления.

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

1️⃣ Для этого в 1996 году был принят стандарт ACPI 1.0, который вводил новые универсальные состояния системы.

🔹 Начнем с S-states (System states) – глобальные состояния всей платформы, которые подразумевали следующие варианты:

▫️ S0 — работа
▫️ S3 (Suspend to RAM) — сон с сохранением в памяти
▫️ S4 (Hibernate) — сохранение на диск
▫️ S5 — мягкое выключение (дежурный режим БП и доступен WoL)

🔹 Одновременно с ним вводились состояния простоя - C-states (CPU Idle states), которые существовали только внутри режима S0:

▫️ C0 — исполнение инструкций
▫️ C1 (Halt) — базовый простой с мгновенным пробуждением
▫️ C2/C3 — более глубокие состояния с отключением тактового генератора и кэшей

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

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

2️⃣ В ответ появились первые проприетарные технологии Intel SpeedStep (1999) и AMD PowerNow! (1999), которые умели управлять частотой и напряжением питания в зависимости от реальной нагрузки.

🔹 В результате в 2000 году появился новый стандарт ACPI 2.0, который ввел понятие P-state (CPU Performance States), которые существовали внутри уровня C0.

Первоначально предполагались:

▫️ P0 – полная производительность процессора
▫️ P1/P2 – энергосберегающие режимы со снижением частоты и напряжения процессора

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

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

3️⃣ В 2004 году увидел свет стандарт ACPI 3.0, который ввел в прошивку BIOS таблицы DSDT, в которые вендором записывались все возможные сочетания частоты и напряжения, и система в зависимости от нагрузки могла выбирать один из них.

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