Считаю это вредными советами. Все эти методы работают только против совсем не опытных "исследователей", и у кого-то могут создать ложное чуство защищенности...
Спасибо). Основной целью данной статьи имел поделиться с сообществом результатом. Хотелось показать, что искуственно созданные проблемы решаемы и зачастую без особого ущерба функциональности.
Мне кажется, что в обязательных атрибутах NAC сервера, пропущена хостовая проверка. Без нее решение нельзя назвать полноценным NAC - ведь это просто классический AAA сервер, как, например, проверенный годами freeradius. По сути, на данном этапе развития, решение от Efros отличается от freeradius только web интерфейсом, но плюс это или минус, вопрос не однозначный.
В текущей версии проекта, я выделил большую часть незадействованной flash памяти ( offset: 0x300000 size: 0xF0000) под 3 кольцевых буфера. Размер каждого буфера выбрал пропорционально предполагаемой частоте записи в него. Думаю, что так мне ресурса flash хватит надолго.
К сожалению и я займу темную сторону в этом вопросе.
Несмотря на то, что UG, на текущий момент, пожалуй один из лучших NGFW отечественной разработки, он изобилует массой недостатков.
1) Отсутствует технически подробная документация, критически важная для промышленной эксплуатации NGFW. Если работа с политиками FW интуитивно понятна и в большинстве случаев не требует особых разъяснений, то например документация на NAT должна быть технически исчерпывающей. В текущей документации https://docs.usergate.com/nat-i-marshrutizaciya_713.html не указано на каких этапах обработки пакетов меняются source и на каких destination адреса, как NAT взаимодействует с политиками FW. Packet Flow описан только для 6 версии https://docs.usergate.com/usergate-ngfw-6-packet-flow_576.html и очевидно для 7 уже не актуален, так как на практике оказывается, что при некоторых настройках NAT из процесса исключается обработка правилами FW - такие особенности должны быть жирным шрифтом выделены в документации.
2) Отсутствует публичная информация о фактической производительности ПАК. Для тех кто привык работать с асами и пр., среди которых даже не топовые железки легко работают с десятками тысяч правил, будет неприятным сюрпризом, что даже для топовых ПАК UG, 1-2 тысячи правил будет практическим потолком. Это крайне важно знать при планировании миграции.
3) На портале поддержки для зарегистрированных пользователей хотелось бы иметь доступ хотя бы к критическим багам и путям их обхода. Очевидно, что команда работает над продуктом и активно его развивает, но это так же очевидно ведет и к массе багов. Хотелось бы заранее о них узнавать, чтобы не бегать по лужайке с граблями с завязанными глазами.
В отношении миграции, автор в статье явно не упоминает конвертер, днако он есть https://github.com/ran1024/UserGate-utilities . Соглашусь, что конвертер далек от совершенства, но открытый код позволяет отладить и дописать его для миграции именно ваших политик.
Очень хочется и верю, что ребята из UG рано или поздно доработают/переделают свой NGFW, но пока могу поставить только троечку. ((
Думаю, что@kostprof21имел ввиду, что каждый нулевой бит области соотвествует единичному инкременту счетчика. Т. е. если в байте уже записано, например, 0F то туда можно записать 07, потом 03, потом 01 и 00. На мой взгляд хорошоя идея. Но я еще решил поэкспериментировать с ботом и использовать его как энергонезависимое хранилище. Бот к сожалению не может вычитывать историю чата, но у бота есть description до 250 байт и short description до 120 и это для каждого из 189 языков. Суммарно почти 50 кБайт.
Как сейчас, в 2023 году, живут сети sd-access развернутые у нас? Спрашиваю потому, что у самого такая. Очень всем доволен, за исключением, конечно, ise и dnac, и отказываться от l3 underlay, микросегментирования и trustsec не хочется. У кого какие идеи?
На самом деле у меня рядом стоит neptun base и я подумываю подключить этот esp к шине датчиков. Брать оттуда питание и ацп детектировать срабатывание датчиков. Так совсем базовый нептун превратится в весьма продвинутый)
Периодическая активация wifi это идея интересная но тоже иммет свои минусы. В моем случае телеграм бот станет не таким отзывчивым. Но над периодическим отключением wifi я полумаю. Спасибо за идею. Правда это меня больше интересует не с точки зрения энергопотребления, а с точки зрегия загруженности wifi в B диапазоне. Дело в том что fastbot который я использую, общается с сервером телеграм посредством полинга, раз в секуду он делает запросы чтобы проврить наличие новых сообщений.
В моем случае без wifi не обойтись. Ведь именно он обеспечивает нкжную мне автонлмность и связь устройства с внешним миром. А за качеством wifi в своем скворечнике я периодически посматриваю. У меня по работе и оборудование для этого есть и в целом базовын понимания принципов работы wifi. Школьник с глушилкой конечно всегда возможен) но ведь и этому школьнику самому рано или поздно вайфаем захочется воспользоваться) вот и выключит.
Да, электричество мне тоже интересно. У меня счетчик стоит совсем умный, у него и оптопорт и PLC модем внутри есть. Он на очереди). Вот тут интересная идея, https://habr.com/ru/companies/samsung/articles/768864 но к сожалению ребята не поделились как сделали дешевый оптопорт ((.
В данном случае можно и проще, счетчики могут только увеличиваться, значит можно писать в кольцевой буфер или даже в случайную позицию из N а при рестарте просто искать максимум.
Пока эксплуатирую пару месяцев с текущим алгроитмом подсчета импульсов и отклонения пока не выявлены. +- 10л на десятки кубов. Электричесиво за этот период отключали пару раз. Меня такая точность устраивает. За гды эксплуатации погрешность накопится в единицы кубов.
Согласен с Вами. У проекта с распознаванием картинки есть и очевидный плюс - работает с любым счетчиком, но и минусы тоже есть, изготовление крепежа в первую очередь.
В отношении ошибки в своем проекте я вставил защиту в виде лимита на разницу показаний в 30 единиц. Перед подачей показаний esp ходит на сайт поставщика, считывает последние учтенные там показания и сравнивает с теми которые собирается передать.
Считаю это вредными советами. Все эти методы работают только против совсем не опытных "исследователей", и у кого-то могут создать ложное чуство защищенности...
Спасибо). Основной целью данной статьи имел поделиться с сообществом результатом. Хотелось показать, что искуственно созданные проблемы решаемы и зачастую без особого ущерба функциональности.
Да, но это было сделано тогда, когда поддержка была нужна и обязательна
Мне кажется, что в обязательных атрибутах NAC сервера, пропущена хостовая проверка. Без нее решение нельзя назвать полноценным NAC - ведь это просто классический AAA сервер, как, например, проверенный годами freeradius. По сути, на данном этапе развития, решение от Efros отличается от freeradius только web интерфейсом, но плюс это или минус, вопрос не однозначный.
В текущей версии проекта, я выделил большую часть незадействованной flash памяти ( offset: 0x300000 size: 0xF0000) под 3 кольцевых буфера. Размер каждого буфера выбрал пропорционально предполагаемой частоте записи в него. Думаю, что так мне ресурса flash хватит надолго.
Реализованы эти буферы в виде отдельного класса
https://github.com/Ar4w/wc_server/blob/main/saver.h
Но чтобы его использовать, в корень проекта нужно положить файл default.csv
К сожалению и я займу темную сторону в этом вопросе.
Несмотря на то, что UG, на текущий момент, пожалуй один из лучших NGFW отечественной разработки, он изобилует массой недостатков.
1) Отсутствует технически подробная документация, критически важная для промышленной эксплуатации NGFW. Если работа с политиками FW интуитивно понятна и в большинстве случаев не требует особых разъяснений, то например документация на NAT должна быть технически исчерпывающей. В текущей документации https://docs.usergate.com/nat-i-marshrutizaciya_713.html не указано на каких этапах обработки пакетов меняются source и на каких destination адреса, как NAT взаимодействует с политиками FW. Packet Flow описан только для 6 версии https://docs.usergate.com/usergate-ngfw-6-packet-flow_576.html и очевидно для 7 уже не актуален, так как на практике оказывается, что при некоторых настройках NAT из процесса исключается обработка правилами FW - такие особенности должны быть жирным шрифтом выделены в документации.
2) Отсутствует публичная информация о фактической производительности ПАК. Для тех кто привык работать с асами и пр., среди которых даже не топовые железки легко работают с десятками тысяч правил, будет неприятным сюрпризом, что даже для топовых ПАК UG, 1-2 тысячи правил будет практическим потолком. Это крайне важно знать при планировании миграции.
3) На портале поддержки для зарегистрированных пользователей хотелось бы иметь доступ хотя бы к критическим багам и путям их обхода. Очевидно, что команда работает над продуктом и активно его развивает, но это так же очевидно ведет и к массе багов. Хотелось бы заранее о них узнавать, чтобы не бегать по лужайке с граблями с завязанными глазами.
В отношении миграции, автор в статье явно не упоминает конвертер, днако он есть https://github.com/ran1024/UserGate-utilities . Соглашусь, что конвертер далек от совершенства, но открытый код позволяет отладить и дописать его для миграции именно ваших политик.
Очень хочется и верю, что ребята из UG рано или поздно доработают/переделают свой NGFW, но пока могу поставить только троечку. ((
Думаю, что@kostprof21имел ввиду, что каждый нулевой бит области соотвествует единичному инкременту счетчика. Т. е. если в байте уже записано, например, 0F то туда можно записать 07, потом 03, потом 01 и 00. На мой взгляд хорошоя идея. Но я еще решил поэкспериментировать с ботом и использовать его как энергонезависимое хранилище. Бот к сожалению не может вычитывать историю чата, но у бота есть description до 250 байт и short description до 120 и это для каждого из 189 языков. Суммарно почти 50 кБайт.
Как сейчас, в 2023 году, живут сети sd-access развернутые у нас? Спрашиваю потому, что у самого такая. Очень всем доволен, за исключением, конечно, ise и dnac, и отказываться от l3 underlay, микросегментирования и trustsec не хочется. У кого какие идеи?
На самом деле у меня рядом стоит neptun base и я подумываю подключить этот esp к шине датчиков. Брать оттуда питание и ацп детектировать срабатывание датчиков. Так совсем базовый нептун превратится в весьма продвинутый)
Периодическая активация wifi это идея интересная но тоже иммет свои минусы. В моем случае телеграм бот станет не таким отзывчивым. Но над периодическим отключением wifi я полумаю. Спасибо за идею. Правда это меня больше интересует не с точки зрения энергопотребления, а с точки зрегия загруженности wifi в B диапазоне. Дело в том что fastbot который я использую, общается с сервером телеграм посредством полинга, раз в секуду он делает запросы чтобы проврить наличие новых сообщений.
В моем случае без wifi не обойтись. Ведь именно он обеспечивает нкжную мне автонлмность и связь устройства с внешним миром. А за качеством wifi в своем скворечнике я периодически посматриваю. У меня по работе и оборудование для этого есть и в целом базовын понимания принципов работы wifi. Школьник с глушилкой конечно всегда возможен) но ведь и этому школьнику самому рано или поздно вайфаем захочется воспользоваться) вот и выключит.
Исправлю. Но там я просто arduino ide использую
Да, электричество мне тоже интересно. У меня счетчик стоит совсем умный, у него и оптопорт и PLC модем внутри есть. Он на очереди). Вот тут интересная идея, https://habr.com/ru/companies/samsung/articles/768864 но к сожалению ребята не поделились как сделали дешевый оптопорт ((.
Расскажите пожалуйста подробнее, как вы сделали оптопорт из датчика линии?
Я старался максимально избавиться от любой обвески.
В данном случае можно и проще, счетчики могут только увеличиваться, значит можно писать в кольцевой буфер или даже в случайную позицию из N а при рестарте просто искать максимум.
Пока эксплуатирую пару месяцев с текущим алгроитмом подсчета импульсов и отклонения пока не выявлены. +- 10л на десятки кубов. Электричесиво за этот период отключали пару раз. Меня такая точность устраивает. За гды эксплуатации погрешность накопится в единицы кубов.
Ошибка. Исправил
Спасибо за аргументированную критику. Статью доработаю.
Не сразу разобрался с комментариями здесь на хабре, и ответы на ваши технически замечания оказались в комментариях чуть выше.
Согласен с Вами. У проекта с распознаванием картинки есть и очевидный плюс - работает с любым счетчиком, но и минусы тоже есть, изготовление крепежа в первую очередь.
В отношении ошибки в своем проекте я вставил защиту в виде лимита на разницу показаний в 30 единиц. Перед подачей показаний esp ходит на сайт поставщика, считывает последние учтенные там показания и сравнивает с теми которые собирается передать.