Почему доступ в интернет по белым спискам это плохая идея

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

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

🔹 Настройка черного и белого списков в роутерах Mikrotik

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

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

🔹 Создаем собственный фильтрующий DNS-сервер на базе Pi-hole

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

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

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

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

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

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

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

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

Ладно, нашли эти адреса и добавили. Но что это? Почему он так выглядит? Что это за кошмар?

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

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

Ну вроде победили… Но радоваться рано. Пробуем войти на сайт и ничего не работает. Потому что вход реализован через сторонние сервисы вроде ЕСИА, соцсетей, Яндекса и т.д.

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

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

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

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

Форматируем раздел как ReFS в Windows 10/11

Файловая система ReFS была представлена в 2012 году и имеет ряд существенных преимуществ над своей предшественницей – NTFS. Также она имеет ряд особенностей и ограничений.

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

Подробнее обо всем этом можно почитать в первоисточнике: https://learn.microsoft.com/ru-ru/windows-server/storage/refs/refs-overview

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

Начиная с выпуска 1709 в Windows 10 убрали поддержку ReFS для всех редакций кроме Professional for Workstation и Enterprise.

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

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

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

В общем Microsoft поступили в своем репертуаре, сначала дали попробовать, потом спрятали.

Но они бы не были собой, если бы с последними обновлениями Windows 11 не случилось второго пришествия ReFS под видом «дисков для разработки», о чем мы писали в дневной заметке.

Однако, если вам нужна ReFS не следует бежать за Windows 11 и срочно обновлять ее. Можно поступить проще.

Энтузиастом создана утилита mkrefs, которая позволяет быстро и просто отформатировать любой том в ReFS в любых выпусках Windows 10 и 11.

Скачать ее можно с репозитория разработчика на Github: https://github.com/0xbadfca11/mkrefs

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

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

mkrefs E: /X

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

Также доступны ключи:

▫️ /V:label – метка тома, задаем произвольно, при наличии пробелом заключаем в кавычки

▫️ /A:{4096 | 64K} – размер блока файловой системы, по умолчанию 4К

▫️ /I:{enable | disable} – включение проверки целостности файловой системы, по умолчанию выключено

Например:

mkrefs E: /X /V:”My ReFS Vol” /A:64K /I:enabled

После чего в вашей системе появится диск с файловой системой ReFS который вы сможете полноценно использовать.

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

Длина имени файла и абсолютного пути

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

☝️ Начнем с Windows. Классическая длина имени – 255 символов, максимальная длина пути – 260 символов.

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

Однако начиная с Windows 10 1607 и Server 2016 эти ограничения можно отключить, в этом случае лимит имени файла или абсолютного пути будет определяться файловой системой, для NTFS это 32767 символов, для ReFS - 32000 символов.

👉 Теперь Linux. Имена файлов в Linux могут быть длиной до 255 байт. Полная длина пути не должна превышать 4096 байт. В отличие от Windows в ограничениях используются не символы, а байты. А кодировка UTF-8 для символов национальных алфавитов предусматривает до 4 байт на 1 символ.

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

Кириллица занимает 2 байта на символ, поэтому в Linux вы будете ограничены 127 символами в имени файла и 2048 символами в пути.

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

Обычно это вызывает сложности при копировании или распаковке файлов из систем с кодировками CP-1251 или KOI-8.

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

Безопасность? Нет, не слышали…

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

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

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

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

🔷 Предсказуемая система паролей, построенная по принципу постоянная часть + уникальная, в виде ФИО. Т.е. если уволенный человек не дурак и ему надо зайти – он зайдет под любым сотрудником.

🔷 OpenVPN без списка отзыва сертификатов, сертификаты на 10 лет, эти же сертификаты используются для доступа еще к некоторому количеству сервисов (мы насчитали пять).

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

Папка доступна только IT-отделу, но мы все прекрасно понимаем, что одно неловкое движение – и все это будет достоянием общественности.

🔷 Секреты от тестовой среды, залитые на Git вместе с композами и плейбуками внезапно подошли к проду.

🔷 Сертификаты руководителей и сотрудников с МЧД просто лежали в общедоступной папке, потому что нужны почти везде, задолбались с ними. И установлены прямо в реестр целевых ПК.

🤷‍♂️ В общем отчет мы написали, и он не понравился ни руководству, ни админам. Но тут уж извините, если мы отрапортуем, что все хорошо, а завтра их сломают – вопросы будут уже к нам.

Продление сертификата

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

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

И не найдут, потому что у сертификата нет такой функции – продлить. Почему нет? Да потому что не предусмотрена.

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

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

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

Поэтому важной частью сертификата является его владелец (юридическое или физическое лицо, доменное имя или сетевой узел), который указан в поле Common Name (CN).

В настоящий момент это поле считается устаревшим и для размещения данных о владельце сертификата используется поле Subject Alternative Name (SAN), которое может содержать сразу несколько значений. Это может быть как несколько доменных имен, так и доменные имена вместе с IP-адресами, что позволяет защищать объекты с разным набором доступных имен и разными вариантами обращений.

При этом поле Common Name продолжает поддерживаться для сохранения обратной совместимости и там принято указывать «основное» имя владельца.

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

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

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

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

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

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

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

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

Почему у нас все так плохо с безопасностью?

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

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

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

Типичный набор «безопасности» от администратора:

🔹 Закрыть периметр и (возможно) наиболее критичные узлы брандмауэром.

🔹 Настроить политику паролей согласно формальных требований (часто по минимуму)

🔹 Нарезать доступ по группам, спискам, адресам и т.д.

🔹Время от времени ставить обновления (да и то не факт)

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

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

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

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

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

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

Да и самим админам нафиг это надо, особенно когда все работает. Один пароль на все сервисы? А что такого, это наши, админские сервисы.

Один SSH-ключ на всех устройствах – так проще и удобнее. Общие пароли в тесте и проде? Так удобнее тестировать, все равно это наш тест и наш прод.

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

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

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

Это, совсем другая профессия, с другими подходами и другими методами, которым администраторов не учили и многие из которых идут в разрез с привычными им нормами.

И снова о выборе мыши

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

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

Сегодня основной размер экранов в пикселях – это FHD, так, для 1920 x 1080 диагональ экрана составит 2202 px, а для 2K экрана – уже 2937 px.

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

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

Возьмем дешевую мышь с разрешением 800 dpi, это значит, что при движении мыши на 1 дюйм в физическом пространстве курсор пройдет на экране 800 px.

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

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

Но если мы увеличим разрешение мыши вдвое, то нам потребуется для этого всего 3,5 см физического расстояния, а если взять мышь с разрешением 2400 dpi, то получим весьма комфортные 2,33 см.

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

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

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

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

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

И это вне зависимости от характеристик сенсора мыши. Чем больше расстояние физического перемещения мыши, тем больше погрешность позиционирования на экране.

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

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

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

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

Так увеличив радиус всего на 10, мы увеличим площадь на 100. В нашем случае 10 – это скорость, а 100 – точность. Ну это совсем ни в какие ворота. И именно этим страдают дешевые мыши, где разрешение подняли программно.

Почему IT всегда проигрывает?

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

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

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

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

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

Чтобы понять роль и место IT в фирме проведем простую аналогию. Вот у нас есть стадо овец, пастух и овчарка. Прибыль у нас исключительно с овец (шерсть и мясо), а овчарка только ест, с нее ни шерсти, ни мяса.

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

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

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

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

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

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

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

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

После чего на разговор вызывается IT. Вопрос простой: зачем вы это сделали? Чтобы не сломали. А нас ломают? Вроде нет, но… Хорошо, какая вероятность что сломают? Ну или сломают или нет…

То же самое касается и выхода из строя оборудования, и прочих моделей IT-рисков. Там все как в анекдоте про блондинку и динозавра. Или сломается или нет, 50/50.

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

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

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

Роутеры бывают разные

Читатели спрашивают: кто что использует сейчас в качестве роутера, чтобы удовлетворял всем современным требованиям к трубопроводам, КВН и всему такому прочему?

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

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

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

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

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

Это может быть как «малинка» / «бананка» / «репка» или что-то более серьезное на x86. Из нового – это компактные неттопы на N100, которые можно купить от 18 000 - 25 000 руб., из б/у можно посмотреть на Авито неттопы на J1900 / N 3xxx, которые можно купить в хорошем состоянии где-то за 8000-10 000 руб.

А если у меня есть NAS / Медиасервер / Домашняя лаба (нужное подчеркнуть)? Нет и еще раз нет. Сетевые службы являются критически важными и поэтому должны быть доступны 24/7 вне зависимости от других сервисов.

Поэтому отдельная железка – самое то. Сегодня на нее, как минимум, логично возложить функции VPN / Прокси и локального кеширующего DNS.

А что же роутер? А роутеру оставим его основную функцию – маршрутизацию.

Что касается самого роутера, то мы видим тут три основных варианта:

🔹 Mikrotik – умеет все, что нужно домашнему роутеру и даже намного больше. Но требует определенных знаний и умений. В наше время еще и дороговат, также потребует стороннего решения для Wi-Fi, если вы не садомазохист.

🔹 Keenetic – достаточно мощная и продвинутая платформа с низким порогом входа и дружелюбным интерфейсом. Может многое и не требует специфичных знаний для настройки. Минусы – достаточно дорого. Плюсы – хороший Wi-Fi из коробки.

🔹 OpenWRT – привет красноглазие. Порог входа не ниже, чем на Mikrotik, а то еще и побольше. Потому как надо еще уметь прошивать, заливать, разблокировать и прочую аппаратно-программную магию. Но возможности там практически как у нормального Linux и роутер можно взять относительно недорогой. По Wi-Fi – как повезет, но скорее да, чем нет.

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

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

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

Отдельный хост – как сосредоточие сетевых служб: VPN, Proxy, DNS и все что может понадобиться еще. Там стоит классический Linux и возможности ограничены только вашей фантазией и наличием пакетов.

Узкий профиль или болото?

В комментариях время от времени всплывает вопрос эксплуатации откровенно старых систем. Мол все что вы пишете – хорошо, но попробуйте это применить на … (можете вписать любой устаревший софт).

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

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

Далее от его лица, моя только литературная обработка.

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

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

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

Стек технологий у меня оставался стабильным, точнее стабильно древним: FoxPro, Visual Basic 6, Windows, COM и 1С на обычных формах. Новая 1С, которая 8.3 и на управляемых формах как-то не зашла (там сильно переучиваться надо было) и стояла только в бухгалтерии, благо дорабатывать ее было не нужно.

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

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

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

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

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

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

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

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

Но что делать как-то в голову не приходило. Да, надо было учить, но когда?

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

По приезду состоялся разговор, мол, а если тебе завтра кирпич на голову упадет? Я сказал, что тоже об этом думал и «покаялся», рассказал дяде про халтурку и то, как там было все устроено.

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

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

Интернет по паспорту

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

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

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

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

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

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

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

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

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

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

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

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

Сегодня для этого уже есть специальный термин Proof of Personhood (доказательство человечности) и ведутся первые такие разработки, скажем World ID от Сэма Альтмана, также рассматриваются аппаратные ключи и телеметрия без деанонимизации.

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

Кризис доверия. Часть 1: как нейросети ломают общественный договор открытого веба

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

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

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

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

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

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

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

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

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

Фактически это будет реализация теории «Мёртвого интернета» (Dead Internet Theory), т.е. сети, в которой генерируют и потребляют контент боты, они же комментируют и голосуют и делать живому человеку в таком вебе нечего.

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

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

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

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

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

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