Очень интересно никто (или я не увидел) не сделал на AI Max+ 395 материнок стандартного форм фактора. AI 395 сам по себе проц на сегодняшний день очень уникальный. Сильно сомневаюсь что кто-то будет брать его для игр. А тем кому он действительно нужен, нужен именно сам проц а не готовое изделие с ним. С большим удовольствием бы купил только материнку, но похоже придется брать mini pc.
"И тут выяснилось, что производители СКУД трактуют стандарт Wiegand кто во что горазд! У одних импульсы длиннее, у других короче, третьи вообще меняют паузы между битами. Такое ощущение, что они соревнуются, кто дальше уйдет от изначальной спецификации."
А можно пожалуйста предоставить какой-то документ который стандартизирует интерфейс/протокол wiegand. В одном кабинете со мной сидят два программиста, один пишет прошивку для контроллеров СКУД, второй для считывателей. Ни один из них не знает ни какое ISO на которое можно было бы сослаться при настройки таймингов для Wiegand
Самое слабое место в любой подобной систем не Wiegand, который нужно еще суметь подслушать, это замок который управляется через сухой контакт.
Я могу еще один протокол подкинуть - modbus, в нем тоже нет шифрования (из коробки), тоже работает по 2 проводам. Но используется до сих пор и подключатся им устройства иногда более чувствительнее к безопасности чем считыватель весящий на двери внутри безопасного периметра.
Соглашусь с вами, что перебор это я приплел чисто для красного словца. Очень сомневаюсь что хоть кто-то так будет взламывать. Посыл тут скорей в том, что Wiegand это слабое место в связке карта - считыватель - контроллер. Какой бы защищенной и не копируемой не была карта данные c нее передают в незашифрованном виде, а провода от считывателя хорошо если в стену замурованы, а не идут в каком-нибудь кабель канале.
Да действительно wiegand это не шина. Но довольно часто считыватель устанавливается на значительном удалении от контроллера (до 150 метров). Например считыватель на калитке, а контроллер в доме или где-то в другом здании. В этом случае у вас есть доступ к проводам довольно открытый.
Обратной связи нет у протокола Wiegand, но обратная связь есть со стороны контроллера. (Считыватель же нам сигнализирует можно\нельзя) по этой связке можно понять, код подошел или нет.
500 милисекунд все таки тоже многовато. Все таки обычно контроллеры при простых логиках доступа (без хождения на сервер) обрабатывают проход в приделах 100 мс - 200 мс
Мне не известны системы СКУД, где код карты генерировался бы для каждой точки доступа свой. А это значит что получив номер карты где-то на проходной вам открыты все двери которые разрешены этой карте.
Примение OSDP как замена Wiegand в России не очень популярна. Хоть компания в которой я работаю и выпускаем считыватели с поддержкой OSDP, по общению с нашими продажниками практически все подключаются по Wiegand. Даже довольно крупные клиенты и повышают безопасность другими способами (видео наблюдение, добавление дополнительных факторов идентификации)
Wiegand это односторонний интерфейс\протокол разработанные несколько десятком лет назад. В нем нет ничего. Ни авторизации, ни шифрования, даже обратной связи от считывателя.
Следовательно возможны такие примитивные атаки:
Тупой перебор ключей, пока не откроется. Далеко не все контроллеры защищены от перебора.
Прослушивание линии Wiegand любым, даже самым дешевым логическим анализатором для сборки "работающих" ключей
У Wiegand такие тайминги срабатывания, и на столько простой интерфейс что вы можете даже микроконтроллер не использовать. Я писал Wiegand эмулятор для pi zero на python используя их стандартную либо по работе с GPIO, даже на Python все работало отлично.
Практически все архитектуры СКУД являются 2 уровневыми. Контроллер это управляющее устройство имеет некий уровень автономности, сервер для работы ему совершенно не нужен. Поэтому аварии на серверной в том числе долгая потеря связи с центральным сервером ни как не повлияет на работу самих контроллер.
Теперь о пожаре. СКУД, в отличии от пожарной системы не является обязательной системой. Поэтому там где СКУД ставить с огромной долью вероятности есть пожарная система. Так вот, на практически на любой замыкающей аппаратуре, будь то контроллер СКУД или обычный магнитный замок существуют контакты для подключения это самой пожарной сигнализации. Есть требование (документ не найду, но он гуглиться) который в вольном изложении звучит так: в случае возникновения пожара любые все точки доступа должны разблокироваться. Понятно что это не касается контроллеров которые управляют например сейфовыми замками, практиче везде это настраивается, но факт остается фактом. При наступлении пожара СКУД установленных хотя бы по минимальным требованиям не будет преграждать путь.
Судя по указанным моделям контроллеров NC-8000-D (Парсек) и представленным тут схемам подключения, ведится что в техническом задании на СКУД безопасность не была проставлена как отдельный критерий.
Любой СКУД построенный на Wiegand интерфейсе контроллер-считыватель и со свободным доступам к проводам DATA0-DATA1 ставит крест на любых способах защиты устройств считывания.
Представленные тут терминалы (На сколько я понял это какой-то из Хиков) действительно устройство все в одном и как любое подобное устройство не застраховано от прямого доступа к примитивным органам управления (реле, сухие контакты).
Если уже была установлена обычная карточная система, то не понятно почему не повесили Хик на контроллер Парсека, тогда бы Хик выступал только преобразователем лицо -> wiegand номер, а решение об управлении дверью принимал бы контроллер парсека находящийся в более защищенной зоне.
Около года активно использую devcontainers как дома, так и на работе. Devcontainer стал для меня спасением из-за мультиязычности проекта. Сам я Питонист и пишу на Python. периодически мне нужно работать с проектами на java, c++ и js
Плюсы:
Великолепная переносимость. Если devcontainer запустился и собрался у тебя, то скорее всего он соберется где угодно где есть vscode и docker (если вы запускаетесь локально)
Великолепное разделение контекстов. В devcontainer ты собираешь ровно тот набор плагинов, утилит и настроек которые нужны именно для этого стека
Скрипты автоматизации на проекте становятся проще, ты точно знаешь вплоть до отдельного файла что и где у тебя находится, тебе не нужно учитывать разницы операционных систем, у тебя она всегда одинаковая
Ты можешь раскатывать и работать со своим окружением удаленно через Remote SSH или GitHub Workspace и оно везде идентичное. Это оказалось очень удобно особенно если приходится скакать между разными компами.
Несколько вещей которые я извлек для себя пока работал:
Если вы на windows то моунтинг папки в devcontainer это боль и очень медленная работа. Если вы клонируете репозиторий локально то клонируйте его в WSL и запускаетесь от туда. А лучше вообще не клонируйте репозиторий локально а используйте "clone repository in container volume"
Если вам нужны разные утилиты раз от разу, особенно если они занимают кучу места, то лучше использовать эти утилиты через docker, управляя ими находясь же в контейнере (фича docker outside of docker)
Очень удобно когда вы собирайте свой docker контейнер на основе своего docker файла с мультисборкой. Приведу пример для poetry проекта:
FROM python:3.11 as base
# Install poetry
FROM base as devcontainer
# Install dev utils
FROM base as runner
# COPY . .
# Entrypoint.sh
Я не embedded разработчик, но на сколько я понимаю, там не все так просто. Та "дешевая" память к которой все привыкли это NAND Flash. Микроконтроллеры не умеют (или умеют но не все) грузиться с памяти такого типа. Поэтому им нужна флешка другого типа. Например к eps32 можно подключить внешнюю память NAND, но грузиться с нее нельзя. То-есть у устройств должно быть 2 флешки, первая с загрузчиком, вторая для данных. Например найти QSPI флешки больше 128 мегабайт, очень проблематично и неоправданно дорого. А для второй флешки еще же нужна обвязка. Для производителя выпускающего устройства по 100+ тысяч штук экономия на каждом элементе платы очень существенная. Поэтому, я думаю, если есть возможность установить только одну флешку, то они установят только одну, без серьезной на то необходимости. 99% все сетевых кейсов спокойно покрывается и ложиться в стандартные 64/128 мегабайт
А кто-то знает аналоги но сильно слабее, а следовательно и дешевле. Хочется чего-то по мощностям не больше orange pi zero (2/4 мелких ядра, 1/2gb ram, 1гб emmc), но что бы под собственную плату.
У некоторых производителей СКУД есть решения с проходом по приложению на телефоне. Даже карты покупать не нужно.
Форм-фактор карт может быть очень разный. Я хожу по работе с браслетом из фитнес зала. Такой потерять сложнее чем карту
P.S. Работаю в одной российской компании которые производят средства СКУД
Я по теме статьи. Тем родителями которым нужно следить когда ребенок пришел в школу и без турникетов найдут способ следить за ребенком более качественно.
10000 за месяц?
При средней цене занятия в 500 рублей (а у многих преподавателей и того меньше) я могу получить 20 индивидуальных занятий по скайпу. В чем профит? Либо заниматься 2 раза в неделю (8 занятий) а на оставшиеся 10000 рублей купить годовую подписку на Лингволео с разными тренажерами. Еще и на еду останется.
Страна ничего напечатать не может. Деньги может напечатать центральный банк. А этот самый центральный банк не подчиняется напрямую государству. Страна может взять в долг (выпустить облигации) и центробанк может купить этот долг, но вместе с этим самым цетробанком долг могут купить и другие страны и отвечать по долгам нужно будет и перед ними тоже, либо объявить дефолт с репутационными потерями.
Могу быть не компетентным в этом вопросе. Но на сколько я успел понять то главное отличие где у вас этот самый безнал хранится. Сейчас ваш безналичный счет обслуживает какой-то банк и он и является хранителем это самой базы данных. В случае же с цифровой валютой администратором и хранителем счета будет сам центральный банк. Какие привилегии это даст нам только предстоит выяснить, единственное пока что понятно, это то что скорее всего расплачиваться с таких счетов можно будет офлайн.
Интересно как эта система уживется с доставкой еды из магазинов. Тащить тяжелые сумки (даже если ты на машине) не у кого нет желания и понятно что и в направлении удаленной доставки индустрия будет развиваться. Я вижу смысл в таких магазинчиках когда ты, идя по улице, захотел быстро перекусить, зашел, взял что тебе нужно и вышел.
NanoPi R3S-LTSОперационные системы: Ubuntu, Debian, OpenMediaVault, Proxmox VE, Alpine, Buildroot, FriendlyWrt
Buildroot - не операционная система, а система сборки, на которой собранна указанная вами же дальше FriendlyWrt и OpenWRT тотжеProxmox VE - выпустили для ARM? Можно ссылочку на релиз?Очень интересно никто (или я не увидел) не сделал на AI Max+ 395 материнок стандартного форм фактора. AI 395 сам по себе проц на сегодняшний день очень уникальный. Сильно сомневаюсь что кто-то будет брать его для игр. А тем кому он действительно нужен, нужен именно сам проц а не готовое изделие с ним. С большим удовольствием бы купил только материнку, но похоже придется брать mini pc.
"И тут выяснилось, что производители СКУД трактуют стандарт Wiegand кто во что горазд! У одних импульсы длиннее, у других короче, третьи вообще меняют паузы между битами. Такое ощущение, что они соревнуются, кто дальше уйдет от изначальной спецификации."
А можно пожалуйста предоставить какой-то документ который стандартизирует интерфейс/протокол wiegand. В одном кабинете со мной сидят два программиста, один пишет прошивку для контроллеров СКУД, второй для считывателей. Ни один из них не знает ни какое ISO на которое можно было бы сослаться при настройки таймингов для Wiegand
Самое слабое место в любой подобной систем не Wiegand, который нужно еще суметь подслушать, это замок который управляется через сухой контакт.
Я могу еще один протокол подкинуть - modbus, в нем тоже нет шифрования (из коробки), тоже работает по 2 проводам. Но используется до сих пор и подключатся им устройства иногда более чувствительнее к безопасности чем считыватель весящий на двери внутри безопасного периметра.
Соглашусь с вами, что перебор это я приплел чисто для красного словца. Очень сомневаюсь что хоть кто-то так будет взламывать. Посыл тут скорей в том, что Wiegand это слабое место в связке карта - считыватель - контроллер. Какой бы защищенной и не копируемой не была карта данные c нее передают в незашифрованном виде, а провода от считывателя хорошо если в стену замурованы, а не идут в каком-нибудь кабель канале.
Да действительно wiegand это не шина. Но довольно часто считыватель устанавливается на значительном удалении от контроллера (до 150 метров). Например считыватель на калитке, а контроллер в доме или где-то в другом здании. В этом случае у вас есть доступ к проводам довольно открытый.
Обратной связи нет у протокола Wiegand, но обратная связь есть со стороны контроллера. (Считыватель же нам сигнализирует можно\нельзя) по этой связке можно понять, код подошел или нет.
500 милисекунд все таки тоже многовато. Все таки обычно контроллеры при простых логиках доступа (без хождения на сервер) обрабатывают проход в приделах 100 мс - 200 мс
Мне не известны системы СКУД, где код карты генерировался бы для каждой точки доступа свой. А это значит что получив номер карты где-то на проходной вам открыты все двери которые разрешены этой карте.
Примение OSDP как замена Wiegand в России не очень популярна. Хоть компания в которой я работаю и выпускаем считыватели с поддержкой OSDP, по общению с нашими продажниками практически все подключаются по Wiegand. Даже довольно крупные клиенты и повышают безопасность другими способами (видео наблюдение, добавление дополнительных факторов идентификации)
Wiegand это односторонний интерфейс\протокол разработанные несколько десятком лет назад. В нем нет ничего. Ни авторизации, ни шифрования, даже обратной связи от считывателя.
Следовательно возможны такие примитивные атаки:
Тупой перебор ключей, пока не откроется. Далеко не все контроллеры защищены от перебора.
Прослушивание линии Wiegand любым, даже самым дешевым логическим анализатором для сборки "работающих" ключей
У Wiegand такие тайминги срабатывания, и на столько простой интерфейс что вы можете даже микроконтроллер не использовать. Я писал Wiegand эмулятор для pi zero на python используя их стандартную либо по работе с GPIO, даже на Python все работало отлично.
Практически все архитектуры СКУД являются 2 уровневыми. Контроллер это управляющее устройство имеет некий уровень автономности, сервер для работы ему совершенно не нужен. Поэтому аварии на серверной в том числе долгая потеря связи с центральным сервером ни как не повлияет на работу самих контроллер.
Теперь о пожаре. СКУД, в отличии от пожарной системы не является обязательной системой. Поэтому там где СКУД ставить с огромной долью вероятности есть пожарная система. Так вот, на практически на любой замыкающей аппаратуре, будь то контроллер СКУД или обычный магнитный замок существуют контакты для подключения это самой пожарной сигнализации. Есть требование (документ не найду, но он гуглиться) который в вольном изложении звучит так: в случае возникновения пожара любые все точки доступа должны разблокироваться. Понятно что это не касается контроллеров которые управляют например сейфовыми замками, практиче везде это настраивается, но факт остается фактом. При наступлении пожара СКУД установленных хотя бы по минимальным требованиям не будет преграждать путь.
Судя по указанным моделям контроллеров NC-8000-D (Парсек) и представленным тут схемам подключения, ведится что в техническом задании на СКУД безопасность не была проставлена как отдельный критерий.
Любой СКУД построенный на Wiegand интерфейсе контроллер-считыватель и со свободным доступам к проводам DATA0-DATA1 ставит крест на любых способах защиты устройств считывания.
Представленные тут терминалы (На сколько я понял это какой-то из Хиков) действительно устройство все в одном и как любое подобное устройство не застраховано от прямого доступа к примитивным органам управления (реле, сухие контакты).
Если уже была установлена обычная карточная система, то не понятно почему не повесили Хик на контроллер Парсека, тогда бы Хик выступал только преобразователем лицо -> wiegand номер, а решение об управлении дверью принимал бы контроллер парсека находящийся в более защищенной зоне.
Около года активно использую devcontainers как дома, так и на работе. Devcontainer стал для меня спасением из-за мультиязычности проекта. Сам я Питонист и пишу на Python. периодически мне нужно работать с проектами на java, c++ и js
Плюсы:
Великолепная переносимость. Если devcontainer запустился и собрался у тебя, то скорее всего он соберется где угодно где есть vscode и docker (если вы запускаетесь локально)
Великолепное разделение контекстов. В devcontainer ты собираешь ровно тот набор плагинов, утилит и настроек которые нужны именно для этого стека
Скрипты автоматизации на проекте становятся проще, ты точно знаешь вплоть до отдельного файла что и где у тебя находится, тебе не нужно учитывать разницы операционных систем, у тебя она всегда одинаковая
Ты можешь раскатывать и работать со своим окружением удаленно через Remote SSH или GitHub Workspace и оно везде идентичное. Это оказалось очень удобно особенно если приходится скакать между разными компами.
Несколько вещей которые я извлек для себя пока работал:
Если вы на windows то моунтинг папки в devcontainer это боль и очень медленная работа. Если вы клонируете репозиторий локально то клонируйте его в WSL и запускаетесь от туда. А лучше вообще не клонируйте репозиторий локально а используйте "clone repository in container volume"
Если вам нужны разные утилиты раз от разу, особенно если они занимают кучу места, то лучше использовать эти утилиты через docker, управляя ими находясь же в контейнере (фича docker outside of docker)
Очень удобно когда вы собирайте свой docker контейнер на основе своего docker файла с мультисборкой. Приведу пример для poetry проекта:
Я не embedded разработчик, но на сколько я понимаю, там не все так просто. Та "дешевая" память к которой все привыкли это NAND Flash. Микроконтроллеры не умеют (или умеют но не все) грузиться с памяти такого типа. Поэтому им нужна флешка другого типа. Например к eps32 можно подключить внешнюю память NAND, но грузиться с нее нельзя. То-есть у устройств должно быть 2 флешки, первая с загрузчиком, вторая для данных. Например найти QSPI флешки больше 128 мегабайт, очень проблематично и неоправданно дорого. А для второй флешки еще же нужна обвязка. Для производителя выпускающего устройства по 100+ тысяч штук экономия на каждом элементе платы очень существенная. Поэтому, я думаю, если есть возможность установить только одну флешку, то они установят только одну, без серьезной на то необходимости. 99% все сетевых кейсов спокойно покрывается и ложиться в стандартные 64/128 мегабайт
А кто-то знает аналоги но сильно слабее, а следовательно и дешевле. Хочется чего-то по мощностям не больше orange pi zero (2/4 мелких ядра, 1/2gb ram, 1гб emmc), но что бы под собственную плату.
У некоторых производителей СКУД есть решения с проходом по приложению на телефоне. Даже карты покупать не нужно.
Форм-фактор карт может быть очень разный. Я хожу по работе с браслетом из фитнес зала. Такой потерять сложнее чем карту
P.S. Работаю в одной российской компании которые производят средства СКУД
Я по теме статьи. Тем родителями которым нужно следить когда ребенок пришел в школу и без турникетов найдут способ следить за ребенком более качественно.
10000 за месяц?
При средней цене занятия в 500 рублей (а у многих преподавателей и того меньше) я могу получить 20 индивидуальных занятий по скайпу. В чем профит? Либо заниматься 2 раза в неделю (8 занятий) а на оставшиеся 10000 рублей купить годовую подписку на Лингволео с разными тренажерами. Еще и на еду останется.
Страна ничего напечатать не может. Деньги может напечатать центральный банк. А этот самый центральный банк не подчиняется напрямую государству. Страна может взять в долг (выпустить облигации) и центробанк может купить этот долг, но вместе с этим самым цетробанком долг могут купить и другие страны и отвечать по долгам нужно будет и перед ними тоже, либо объявить дефолт с репутационными потерями.
Могу быть не компетентным в этом вопросе. Но на сколько я успел понять то главное отличие где у вас этот самый безнал хранится. Сейчас ваш безналичный счет обслуживает какой-то банк и он и является хранителем это самой базы данных. В случае же с цифровой валютой администратором и хранителем счета будет сам центральный банк. Какие привилегии это даст нам только предстоит выяснить, единственное пока что понятно, это то что скорее всего расплачиваться с таких счетов можно будет офлайн.
Интересно как эта система уживется с доставкой еды из магазинов. Тащить тяжелые сумки (даже если ты на машине) не у кого нет желания и понятно что и в направлении удаленной доставки индустрия будет развиваться. Я вижу смысл в таких магазинчиках когда ты, идя по улице, захотел быстро перекусить, зашел, взял что тебе нужно и вышел.