Расшифровка нсп: НСП | это… Что такое НСП?

Взлом Sonoff NSPanel | Blakadder’s Smarthome Shenanigans

Сводка

• Резервное копирование оригинальной прошивки
  • Узнайте, как ESP32 взаимодействует с Nextion
  • Анализ последовательной связи
• Расшифровка структуры сообщения
• Посмотреть оригинальную прошивку
• Структура протокола NSPanel
  • Тип
  • Длина полезной нагрузки
  • Полезная нагрузка JSON
  • CRC
• Начальный тест Тасмота
• Прошивка Тасмота
• Проверка всего
• Режим Nextion
• Бег Тасмота

Хроника декодирования коммуникационного протокола NSPanel и установления контроля над экраном Nextion с кастомной прошивкой.

Sonoff NSPanel можно приобрести в магазине Itead.

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

Резервное копирование оригинальной прошивки

Создайте резервную копию исходной прошивки, а затем еще раз для надежности. Модуль ESP32 диктует использование esptool.py, и в этой статье подробно объясняется процедура идентификации флэш-памяти и резервного копирования.

Узнайте, как ESP32 взаимодействует с Nextion

Я часто бываю на неофициальном сайте Nextion Discord, потому что он также является центром разработки openHASP. Поскольку у них действительно есть опыт работы с экранами Nextion, я спросил и получил информацию о стандартном протоколе, который Nextion использует со своими автономными экранами, и прочитал больше об этом на веб-сайте Nextion.

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

Анализ последовательной связи

Для этого я использовал дешевый логический анализатор 24 МГц (AliExpress) и PulseView.

Подключил контакты D0 и D1 анализатора к контактным площадкам TF_RX и TF_TX и запустил PulseView. Я установил частоту дискретизации на 24 МГц, так как это максимальное значение, на которое способен мой анализатор, и максимальный размер выборки. Декодер настроен на UART, потому что используется последовательная связь. Я использую два декодера, один для отображения шестнадцатеричного значения, а другой для отображения ascii-9.0003

Я нажал «Выполнить» в PulseView, подал питание 5 В через разъемы и дождался окончания выборки. Данные передаются, но почти все они совсем не похожи на протокол Nextion, который заканчивает каждое сообщение 0xFFFFF или ÿÿÿ, и вместо этого я вижу полезные данные JSON с некоторыми дополнительными байтами до и после. Поскольку Itead любезно опубликовал распиновку и протокол загрузки Nextion на Kickstarted, я попросил у них документацию по протоколу. Ответ был немного странным:

.

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

Слишком сложно!?!? Вызов принят!!!

Расшифровка структуры сообщения

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

Каждое сообщение на экран и с экрана начинается с 0x55AA, что очень напоминает протокол Tuya. Следующий байт всегда представляет собой 80-е шестнадцатеричное число.

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

Посмотреть оригинальную прошивку

Чтобы не оставить камня на камне, я взял резервную копию исходного бинарного файла прошивки и прогнал его через строки , чтобы извлечь как можно больше данных. А данные были… Среди стандартных сообщений об ошибках ESP IDF и моего пароля от Wi-Fi были строки, подтверждающие мои выводы с помощью логического анализатора и довольно много новой информации:

Найдена команда {"queryInfo":"factory" } для входа в заводской режим и режим проверки экрана. Не то чтобы полезное, но это забавное открытие.

{"HMI_outdoorTemp":{"current":34,"range":"26,36"},"HMI_weather":7} — это команда для установки прогноза погоды и значка, который не поворачивался на анализаторе.

Найдены строки, относящиеся к состоянию Wi-Fi, такие как подключение , отключение , сопряжение и отсутствие сети

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

 {"id": "%s","переключатели":[{"розетка":%d,"переключатель":"выкл"}]}
устройство
группа
{"HMI_resources":[{"index":%d,"ctype":"%s","id":"%s","uiid":%d}]}
сцена
{"HMI_resources":[{"index":%d,"ctype":"%s","id":"%s"}]}
{"HMI_weather":%d,"HMI_outdoorTemp":{"текущий":%d,"диапазон":"%s"}}
режим ATCM
{"params":{"ATCMode":%d,"ATCExpect0":%0. 2f}}
{"температура":%d,"влажность":%d,"tempUnit":%d}
tempUnit
{"tempUnit":0}
{"tempUnit":1}
{"ATCExpect0":%d}
{"ATCExpect1":%d}
{"ctype":"%s","id":"%s","params":"%s"}
{"ctype":"%s","id":"%s"}
{"ctype":"устройство","id":"%s","params":"переключатель|переключатели"}
{[{"индекс":%d,"тип":"удалить"}]}
 

Это почти так же хорошо, как документация из источника.

Существуют также некоторые команды, связанные с обновлением с помощью API-ключей, сертификатов и URL-адресов серверов ewelink и обновлений прошивки, к которым нельзя получить доступ только с помощью браузера.

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

Структура протокола NSPanel

Пример сообщения от NSPanel к Nextion выглядит так:

 55AA8017007B227175657279496E666F223A2276657273696F6E227D846C
 

При преобразовании в ascii полезная нагрузка JSON очевидна. Не знаете, что такое JSON? Прочтите «JSON: что это такое, как это работает и как его использовать»

 U[AA][80][17][00]{"queryInfo":"version"}[84]l
 

Итак, мы рассмотрим все, кроме полезной нагрузки JSON в шестнадцатеричном формате.

Поскольку мне было непонятно, что означают неизвестные байты, я отправил несколько строк в неофициальный дискорд Nextion. Люди прыгали и давали предложения и идеи о том, что они могли бы быть. Крики MaxZ для выяснения последних двух байтов — это CRC16 MODBUS. Я проверил сделанные нами предположения о структуре протокола. #работа в команде

Представляю протокол NSPanel:

 55 AA [тип] [длина полезной нагрузки] [00] [полезная нагрузка JSON] [CRC] [CRC]
CRC-16 (MODBUS) с обратным порядком байтов
 

Тип

В соответствии с образцами сообщений тип байта классифицируется следующим образом:

• 80 = общая информация об устройстве
• 81 = прогноз погоды
• 82 = дата и время
• 83 = датчик температуры
• 84 = связанный с термостатом
• 85 = Wi-Fi и сеть
• 86 = отрисовка и параметры виджета и объекта
• 87 = затемнение экрана

Если «тип» не соответствует полезной нагрузке JSON, Nextion вернет ошибку.

Длина полезной нагрузки

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

Полезные нагрузки варьируются от простого {"tempUnit":0} до {"relation":[{"ctype":"device","id":"1000f71b01","name":"Bulb S.. ","онлайн":true,"params":{"переключатель":"вкл","ltype":"белый","белый":{"br":100,"ct":255}}}]} .

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

CRC

CRC вычисляется из всех предыдущих байтов с использованием CRC-16 MODBUS. Еще раз спасибо MaxZ за то, что заметили это! Я использовал онлайн-калькулятор контрольной суммы Scadacore и прогнал через него несколько полезных нагрузок, чтобы убедиться в этом.

Я создал репозиторий документов на своем GitHub с подробной разбивкой протокола и вспомогательным скриптом, а также информацией, которая может быть обновлена ​​в будущем.

Начальный тест Tasmota

Для простого теста с Tasmota я подключил NodeMCU GPIO к контактной площадке TF_TX и, естественно, к GND. Я настроил этот GPIO как Serial Rx, чтобы увидеть, может ли Tasmota правильно читать сообщения с экрана Nextion. Сначала это выглядело как ерунда, так как сообщения были короткими и просто тарабарщиной, но по предыдущему опыту я знал, что нужно попробовать шестнадцатеричное форматирование, отправив SerialSend5 00 , и это было успешно. Я получил «55AA870B007B226572726F72223A307D550100», что равно 9.0253 {«ошибка»:0} .

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

Прошивка Tasmota

Прошивка Tasmota была простой. Используйте заголовки со всеми выбитыми контактами и прошейте tasmota32.bin с помощью руководства.

Поскольку на переднюю панель подается напряжение 5 В, отключите 3,3 В от адаптера последовательного порта на USB и снова подключите питание 5 В к разъемам.

Устройство успешно загружается в Tasmota, но экран пуст. Ну нужно решить это в первую очередь. Sonoff действительно выпустил распиновку для NSPanel, и в списке был сброс экрана, который мог быть ответственным за это. Я настроил его как Relay1, и после сброса меня встретила загрузочная анимация. Переключение реле в положение ON выключает экран и наоборот.

Next I set GPIO16 and GPIO17 as SerBr TX and SerBr Rx , set SBaudRate to 115200 and issue:

 SSerialSend5 55AA8017007B227175657279496E666F223A2276657273696F6E227D846C
 

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

Тестирование всего

Теперь мне нужно выяснить, что я могу удалить из команд, чтобы они оставались действительными. Для этого мне нужно было сгенерировать свои собственные шестнадцатеричные команды. Хотя это можно сделать вручную с помощью онлайн-конвертеров ascii в hex и калькулятора CRC, я знал, что было бы проще, если бы был какой-то скрипт. Проблема во всем этом в том, что я не знаю, как программировать, поэтому лучше сначала выучить это. Через пару дней и множество вопросов и советов от опытных программистов у меня был скрипт Python, который преобразует ввод JSON в полную команду NSPanel в шестнадцатеричном формате.

Далее следует утомительный процесс перебора множества комбинаций, чтобы выяснить, какие значения работают, а какие нет. Таким образом я узнал все возможные иконки погоды и некоторые баги или фичи. Например, если задать для rssiLevel число выше 4, вместо значка Wi-Fi будет использоваться какой-либо другой элемент изображения, который будет отображаться на его месте. Вы можете сложить довольно много из них и сделать настоящий беспорядок.

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

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

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

Режим Nextion

Пока всем доволен, пришло время попробовать стандартный набор инструкций Nextion. Ссылаясь на протокол загрузки HMI, я преобразовал сообщение инициализации DRAKJHSUYDGBNCJHGJKSHBDNÿÿÿconnectÿÿÿÿÿconnectÿÿÿÿ в шестнадцатеричный формат и запустил его.

Экран вернул comok 2,30614-0,NX4832F035_011C,48,61744,16643401829EF850,16777216 и пользователи Nextion Discord сказали мне, что это хороший знак. Это строка, идентифицирующая тип экрана и готовность к приему файлов проекта HMI.

Я попробовал несколько команд Nextion из набора инструкций и обнаружил интересные результаты.

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

Экран поддерживает весь набор Nextion и можно рисовать все изображения и менять все значения, нужно только правильно угадать какое из них какое. К счастью, MaxZ из неофициального Nextion Discord адаптировал один из своих скриптов Python для извлечения большого количества информации обо всех страницах и объектах.

Сначала мне пришлось отключить ESP32, заземлив GPIO0, а затем сохранить высокий уровень на выводе FSP RST, подключив его к 3,3 В. Подключил мой серийный номер Ch440G к USB-адаптеру к TX и RX и запустил скрипт. Весь вывод доступен на GitHub.

Sonoff NSPanel можно приобрести в магазине Itead.

В общем, с этим устройством множество вариантов и возможностей. Теперь, чтобы закодировать все это в драйвер Tasmota…

Запуск Tasmota

Посетите страницу конфигурации Tasmota для получения инструкций по установке и запуску Tasmota на NSPanel

Я летаю в Америку: Магия работает

Джеймс Уильямс
Перепечатано с разрешения Брифинга по безопасности FAA

Я с гордостью признаюсь, что я технофил. Я пользуюсь компьютерами с тех пор, как себя помню, и, судя по фотографиям, возможно, даже дольше. У меня дома как минимум шесть компьютеров, а также смартфоны, медиаконсоли, телеприставки, GPS, iPod и т. д. Но, несмотря на мой технический опыт, я все еще регулярно сбиваюсь с толку из-за автоматизации. Я знаю, что я не одинок, когда думаю: «Почему это только что сделало это?!» Поскольку более совершенные системы и высокий уровень автоматизации быстро внедряются в самолеты авиации общего назначения (GA), настало время определить ваши стратегии управления автоматизацией. Итак, вот несколько советов, которые я нашел полезными.

В какой-то момент своей авиационной карьеры, летали ли вы для жизни или для удовольствия, вы, вероятно, слышали о рейсе 401 Eastern Airlines. Поздно ночью 29 декабря 1972 года рейс пропустил заход на посадку в международном аэропорту Майами после выход из строя индикатора положения передней стойки шасси. Пытаясь решить проблему, экипаж не заметил, как самолет медленно снижался в Эверглейдс. Национальный совет по безопасности на транспорте (NTSB) пришел к выводу, что летный экипаж не смог контролировать полетные приборы и вовремя обнаружить неожиданное снижение, чтобы предотвратить аварию.

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

Это классический случай отказа от контроля автоматики. Даже у самых лучших систем есть свои недостатки, и никогда не стоит полностью им доверять. На карту может быть поставлена ​​ваша жизнь, поэтому продолжайте сканирование, даже когда включен автопилот. Будьте бдительны в отношении того, какие режимы автоматизации используются (например, NAV/курс/VNAV и т. д.). Чтобы ваш мозг работал, используйте словесные подсказки каждый раз, когда вы меняете скорость полета, высоту, курс, частоту или режим автоматизации. Вы также можете подумать о том, чтобы делать выноски, когда вы пересекаете каждую путевую точку на своем маршруте.

В отчете NTSB отмечается, что в катастрофе Colgan 3407 со смертельным исходом в 2009 году сыграло роль множество факторов. Одним из таких факторов было то, что экипаж явно забыл об активации системы и о том, как эта система работала с другими системами самолета. В начале полета они включили системы защиты от обледенения, включая переключатель, который увеличивал исходные скорости. Это увеличивает запас по сравнению с сваливанием, чтобы дать экипажу некоторую компенсацию за любые потенциальные аэродинамические потери, вызванные потенциальным обледенением. Экипаж обсудил свой опыт борьбы с обледенением и отметил, что наблюдал обледенение планера, но не выразил серьезного беспокойства (NTSB согласился, сделав вывод, что обледенение не повлияло отрицательно на характеристики управляемости аварийного полета). Но когда первый помощник устанавливал данные о характеристиках для посадки, она не учла, что система повышения Vref активна. Эта ошибка создала противоречие между тем, как действовал самолет, и информацией, предоставленной системами относительно исходной скорости полета при заходе на посадку: система рекомендовала скорость 118 KIAS, когда при включенной системе увеличения Vref она должна была быть 138. КИАС. Другим решением было бы отключить систему, что устранило бы конфликт между системами самолета и ожиданиями экипажа.

Когда капитан замедлил скорость самолета для захода на посадку на скорости 118 уз/сек, на скорости 131 уз/сек активировался вибратор управления самолетом. Удивленный капитан оттянул штурвал, добавляя мощности. Это действие увеличило перегрузку, что, в свою очередь, увеличило скорость сваливания. При снижении воздушной скорости на 125 KIAS самолет превысил критический угол атаки (УА) и заглох. Даже после того, как толкатель палки дважды сработал в попытке сломать стойло, капитан в ответ продолжал отступать. Многократное неправильное понимание экипажем информации и системного взаимодействия сыграло свою роль в результате.

Хотя большинство систем самолетов АОН менее сложны, у нас все еще есть взаимозависимые системы. Более того, взаимозависимая авионика станет более распространенной. Радиоприемники привязаны к дисплеям, которые привязаны к индикаторам отклонения от курса (CDI) и движущимся картам. Дело в том, что вам нужно знать, как каждая из этих систем взаимодействует с другими и где могут быть потенциальные ловушки.

Хотя автоматизация может помочь снизить рабочую нагрузку, пилоты должны быть готовы на случай, если она внезапно исчезнет. В 2005 году Cirrus SR-22 разбился из-за явной дезориентации пилота. По данным NTSB, пилот имел допуск по приборам и налетал более 400 часов. Однако у него было всего 15 часов реального опыта игры на инструменте. Он потерял ориентацию после того, как его основной полетный дисплей (PFD) вышел из строя.

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

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

Какие у вас есть советы?

Джеймс Уильямс — помощник редактора FAA Safety Briefing и фоторедактор. Он также является пилотом и наземным инструктором .

Харлан Грей Воробей III

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

Как вы можете себе представить, кто-то в FAA должен решить, достаточно ли реалистичен симулятор, чтобы заменить реальный самолет и соответствовать требованиям обучения. Этот «кто-то» представляет собой группу людей, входящих в Национальную программу тренажеров (NSP), которая организационно является частью отдела воздушного транспорта Службы летных стандартов. Создан в штаб-квартире FAA в 1980, NSP начиналась с 12 сотрудников и отвечала за нормативный надзор за 92 тренажерами, как визуальными, так и невизуальными. С 1982 года NSP физически находится в Атланте, штат Джорджия.

На NSP возложена оценка и квалификация более 760 авиасимуляторов, многочисленных устройств для летной подготовки (FTD) и рекомендации их для утверждения для использования в утвержденных FAA учебных программах по летной подготовке. Благодаря усилиям NSP квалифицированные авиасимуляторы доступны для утверждения и последующего использования при обучении членов экипажей авиакомпаний, коммерческих и частных операторов и инспекторов FAA.

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

NSP также отвечает за установление критериев и стандартов (как определено в Разделе 14 Свода федеральных правил [14 CFR], часть 60) для первоначальной квалификации и периодических оценок для тренажеров самолетов и вертолетов, а также для FTD шестого и седьмого уровня. NSP обеспечивает первоначальную оценку справочных данных для FTD четвертого и пятого уровней, если это необходимо, и оказывает техническую помощь районному отделению летных стандартов (FSDO), отвечающему за утверждение FTD.

Кроме того, NSP назначает специалистов по оценке пилотных тренажеров в качестве оперативных членов и активных участников советов по стандартизации полетов (FSB) и советов по оценке полетов (FOEB) новых самолетов.

инспектора и инженеры NSP путешествуют по всему миру, оценивая одобренные FAA тренажеры и помогая иностранным странам, которые запросили техническую помощь через Государственный департамент США. Кроме того, NSP работает с международными организациями над улучшением стандартизации моделирования во всем мире. Мы действительно здесь, чтобы помочь.

Харлан Грей Воробей III является менеджером Национальной программы моделирования FAA. Для получения дополнительной информации посетите веб-сайт www.faa.gov/about/initiatives/nsp.

Программа обучения NSP – Институт искусств и дизайна Милуоки

Архив списка рассылки: Расшифровка DDOS-сообщений

jhealy at logn

18 марта 2020 г. , 06:46 (3377 просмотров)

Постоянная ссылка

Вопросы по «фичам» ddos-защиты. У нас qfx5100-48 под управлением 16.1. Я знаю, что люди из списка не всегда большие поклонники ddos-защиты; Я просто пытаюсь понять, что его вызывает, чтобы принимать решения о его настройке/отключении/игнорировании.

Мы не являемся поставщиком услуг; мы являемся конечным сайтом с плоской сетью L2 (LAN) с QFX в качестве нашего ядра L3 для IRB и маршрутизации к нашему интернет-провайдеру. Поскольку QFX видит весь трафик BUM, мне любопытно, срабатывает ли защита от ddos ​​в результате просмотра всех пакетов L2.

За последний месяц мы наблюдали нарушения для следующих типов пакетов:

IPMCAST-miss (много таких!)
ARP
TTL
Redirect
L3MTU-fail
RESOLVE
L3NHOP

Я пытаюсь выяснить, являются ли эти нарушения нормальными в среде LAN. Например, у нас есть много устройств Apple, которые отправляют mDNS в течение всего дня; это может привести к срабатыванию счетчиков MCAST. Когда наши ученики меняют классы (все одновременно), это может вызвать всплеск ARP-трафика, поскольку все подключаются к сети, когда открывают свои ноутбуки.

У кого-нибудь есть ссылка на документацию по этим типам пакетов? В документации Juniper нет примеров; вы просто получаете такие описания:

arp: трафик ARP

Итак, это все ARP? ARP, за который должен отвечать коммутатор? Аналогично для других типов пакетов: это пороговые значения для пакетов, которые коммутатор обрабатывает (отправляет на RE), или только для любого трафика, видимого на любом интерфейсе? Если это просто проблема того, что в RE поступает слишком много информации, я могу отключить ее брандмауэром, если знаю, что это ложно.

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

Спасибо.

saku at ytti

18 марта 2020 г., 7:39

Сообщение № 2 из 18 (3377 просмотров)

Постоянная ссылка

Hey Jason,

> Вопросы о «функциях» защиты от ddos. У нас qfx5100-48 под управлением 16.1. Я знаю, что люди из списка не всегда большие поклонники ddos-защиты; Я просто пытаюсь понять, что его вызывает, чтобы принимать решения о его настройке/отключении/игнорировании.

Я большой поклонник, это отличная функция, которую должен запустить каждый и правильно настроить
. К сожалению, даже не сломанный lo0 фильтр
встречается крайне редко, даже в книге MX есть принципиально сломанный пример, как
— пример CYMRU. А с ddos-защитой может быть еще сложнее.

Я не очень хорошо знаком с тем, как это работает на QFX5k, я больше знаю о поведении MX
, где это действительно здорово.

> Мы не являемся поставщиком услуг; мы являемся конечным сайтом с плоской сетью L2 (LAN) с QFX в качестве нашего ядра L3 для IRB и маршрутизации к нашему интернет-провайдеру. Поскольку QFX видит весь трафик BUM, мне любопытно, срабатывает ли защита от ddos ​​в результате просмотра всех пакетов L2.

Ваш L2 должен находиться в экземпляре virtual-switch/vpls (не подразумевает VPLS)
с фильтром плоскости пересылки, контролирующим BUM. Но не имеет отношения к теме
.

> IPMCAST-мисс (много таких!)

Вероятно, пуанты для потока программирования, и последующее будет переключено на HW
. Вы можете захотеть, чтобы ACL отбрасывал весь трафик MCAST на границе.
Должно быть 0, если вы фактически не запускаете многоадресную рассылку.

> ARP

Не требует пояснений? Вы не должны хотеть, чтобы это превышалось, в идеале вы должны
должен контролировать это на уровне IFD, но я не уверен, что QFX5k может, MX
может.

> TTL

Сообщение о превышении TTL. Нормально бить этого полицейского в uloops.

> Перенаправление

Перенаправление IP, вы, вероятно, захотите отключить их на границе сети. Этот
должен быть равен 0.

> L3MTU-fail

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

> RESOLVE

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

> L3NHOP

Не уверен.

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

Это пакеты ARP дословно (см. RESOLVE, который не является пакетом ARP
, запускающим разрешение ARP). Первоначально, когда была реализована защита от ddos ​​
, разрешение не было реализовано, а пакет RESOLVE был тем, с чем когда-либо сталкивался классификатор
, поэтому, если вы отправляли пакеты BGP на неразборчивый DADDR
, он съедал PPS-полицейский BGP, поэтому вы могли легко получить цели ядра
iBGP. вниз, и они ничего не могли сделать, чтобы остановить вас.

> Извините, если я задаю неправильные вопросы… Я просто пытаюсь выяснить, действительно ли эти ошибки являются проблемами, которые мне нужно отследить, или отчеты по умолчанию слишком зашумлены.
>
> Спасибо,
>
> Джейсон
> ______________________________________________
> список рассылки juniper-nsp [email protected]
> https://puck.nether.net/mailman/listinfo/juniper-nsp

—
++ytti
______________________________________________
Список рассылки juniper-nsp [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

бичер и бичер

18 марта 2020 г., 7:51

Сообщение № 3 из 18 (3377 просмотров)

Постоянная ссылка

Это самый последний документ Juniper, который я добавил в закладки для QFX.

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/protocols-edit-ddos-qfx-series. html

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

В среду, 18 марта 2020 г., в 10:42 Саку Итти написал:

> Эй, Джейсон,
>
> > Вопросы о «функциях» защиты от ddos. У нас qfx5100-48
> с 16.1. Я знаю, что люди из списка не всегда являются большими поклонниками
> защиты от ddos; Я просто пытаюсь понять, что вызывает это, поэтому я
> может принимать решения о настройке/отключении/игнорировании.
>
> Я большой поклонник, это отличная функция, которую все должны запустить и
> правильно настроить. К сожалению, даже неповрежденный фильтр lo0
> встречается крайне редко, даже в книге MX есть принципиально сломанный пример, так как
> является примером CYMRU. А с ddos-защитой может быть еще сложнее.
>
> Я не очень хорошо знаком с тем, как это работает на QFX5k, я больше знаю о поведении MX
>, где это действительно здорово.
>
> > Мы не являемся поставщиком услуг; мы являемся конечным сайтом с плоской сетью L2
> (LAN) с QFX в качестве нашего ядра L3 для IRB и маршрутизации к нашему интернет-провайдеру.
> Поскольку QFX видит весь трафик BUM, мне любопытно, срабатывает ли защита от ddos ​​
> в результате просмотра всех пакетов L2.
>
> Ваш L2 должен находиться в своем экземпляре виртуального коммутатора/vpls (не подразумевает VPLS)
> с фильтром плоскости пересылки, контролирующим BUM. Но не имеет отношения к
> предмет.
>
> > IPMCAST-отсутствует (много таких!)
>
> Вероятно, пуанты для потока программирования, и последующее будет HW
> переключено. Вы можете захотеть, чтобы ACL отбрасывал весь трафик MCAST на границе.
> Это должно быть 0, если вы на самом деле не запускаете многоадресную рассылку.
>
> > ARP
>
> Не требует пояснений? Вы не должны хотеть, чтобы это значение было превышено, в идеале вы должны
> контролировать это на уровне IFD, но я не уверен, что QFX5k может, MX
> может.
>
> > TTL
>
> Сообщение о превышении TTL. Нормально бить этого полицейского в uloops.
>
> > Перенаправление
>
> Перенаправление IP, вы, вероятно, захотите отключить их на границе сети. Это
> должно быть 0.
>
> > L3MTU-fail
>
> Egress MTU слишком мал для пакета. Он предназначен для потенциального создания сообщений ICMP
>. В зависимости от ожидаемой или неожиданной конфигурации.
>
> > RESOLVE
>
> Трафик попадает в подключенный DADDR, которого нет в кеше ARP, нам нужно
> направить его для разрешения ARP. Нормально видеть, что есть постоянный фоновый трафик
> для каждого DADDR.
>
> > L3NHOP
>
> Не уверен.
>
> > Так это все ARP? ARP, за который должен отвечать коммутатор? Аналогично
> для других типов пакетов: это пороговые значения для пакетов, которые
> коммутатор обрабатывается (отправляется на RE) или просто для любого трафика, который виден
> на любом интерфейсе? Если дело только в том, что на RE
поступает слишком много информации, > я могу отключить его брандмауэром, если знаю, что это подделка.
>
> Это пакеты ARP дословно (см. RESOLVE, который не является пакетом ARP
> запуск разрешения ARP). Первоначально, когда ddos-защита была
> реализована, разрешение не было реализовано, а пакет RESOLVE был тем, что
> когда-либо попадал в классификатор, поэтому, если вы отправляли пакеты BGP на неразборчивый DADDR
> он потреблял PPS-ограничитель BGP, поэтому вы могли легко вывести из строя целевое ядро ​​
> iBGP, и они ничего не могли сделать, чтобы остановить вас.
>
> > Извините, если я задаю неправильные вопросы… Я просто пытаюсь понять
>, действительно ли эти ошибки являются проблемами, которые мне нужно отследить, или если
> отчет по умолчанию просто слишком шумно.
> >
> > Спасибо,
> >
> > Джейсон
> > _________________________________________________
> > список рассылки можжевельника-nsp [email protected]
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
> —
> + +ytti
> ______________________________________________
> список рассылки juniper-nsp juniper-nsp@puck. nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
список рассылки juniper-nsp можжевельник[email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

jtk at depaul

18 марта 2020 г., 8:01

Сообщение № 4 из 18 (3377 просмотров)

Постоянная ссылка

В среду, 18 марта 2020 г., 14:39:19 +0000
Саку Итти написал:

> К сожалению, даже не сломанный фильтр lo0 встречается крайне редко, даже
> Книга MX имеет принципиально неверный пример, так как пример CYMRU.

Team Cymru перечисляет только Cisco BGP, общий NTP (который включает
Пример Juniper), и общедоступный IP-шаблон Juniper IP:

Если вы имеете в виду один из них, прямо на
страница, чтобы связаться с ними, и вы должны, если есть ошибки и улучшения
. Они будут приветствовать вход. Я отредактировал шаблон NTP, и
помог упростить многоадресную IP-рассылку, которую сделал Ленни, поэтому, если есть проблема
с любым из них, мне было бы интересно узнать об этом, но я
больше не являюсь сотрудником Team Cymru, поэтому я не могу их исправить.

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

У меня есть несколько примеров шаблонов для более поздней работы, которую я сделал, но
в настоящее время не распространяется на случай этой темы и может быть менее
универсально применимым. Они наверное тоже не идеальны, но люди
могут отправить туда свой вопрос, и я сделаю все возможное, чтобы поддерживать их в рабочем состоянии @puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

saku at ytti

18 марта 2020 г. , 9:02

Сообщение № 5 из 18 (3376 просмотров)

Постоянная ссылка

В среду, 18 марта 2020 г., в 17:01, Джон Кристофф написал:

>

Он полностью сломан, вы используете «порт», поэтому вы открываете каждый порт в вашей системе.

—
++ytti
______________________________________________
Список рассылки juniper-nsp [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

jtk at depaul

18 марта 2020 г., 9:16

Сообщение № 6 из 18 (3376 просмотров)

Постоянная ссылка

В среду, 18 марта 2020 г., 16:02:09 +0000
Саку Итти написал:

> Он полностью сломан, вы используете «порт», поэтому вы открываете каждый порт в своей системе.

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

Джон
_________________________________________________
список рассылки juniper-nsp [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

saku at ytti

18 марта 2020 г., 9:18

Сообщение № 7 из 18 (3376 просмотров)

Постоянная ссылка

Я ваш спикер BGP.

Я установил SPORT на 179
Я получаю доступ к вашему SSH-порту

В среду, 18 марта 2020 г., в 18:16, Джон Кристофф написал:
>
> В среду, 18 марта 2020 г., 16:02:09 +0000
> Саку Итти написал:
>
> > Он полностью сломан, вы используете «порт», поэтому вы открываете каждый порт в своем система.
>
> Ха, хорошо, спасибо. Я думаю, что это потребует не такой простой подделки
>, если я что-то не упустил. Мы можем преобразовать любой оператор, который просто
> использует порт, в направленный, что, я думаю, потребует дополнительных правил
>, чтобы ужесточить его. Не стесняйтесь присылать примеры конфигураций.
>
> Джон

—
++ytti
_________________________________________________
список рассылки juniper-nsp [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

saku at ytti

18 марта 2020 г., 9:19

Сообщение № 8 из 18 (3376 просмотров)

Постоянная ссылка

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

В среду, 18 марта 2020 г., в 18:18, Саку Итти написал:
>
> Я ваш спикер BGP.
>
> Я установил SPORT на 179
> Я получаю доступ к вашему SSH-порту
>
> В среду, 18 марта 2020 г., в 18:16, Джон Кристофф написал:
> >
> > В среду , 18 марта 2020 г. 16:02:09 +0000
> > Саку Итти написал:
> >
> > > Он полностью сломан, вы используете «порт», чтобы открыть каждый порт в вашей системе.
> >
> > Ха, хорошо, спасибо. Я думаю, что это потребует не такой уж простой подделки
> > если я что-то не упустил. Мы можем преобразовать любой оператор, который просто
> > использует порт, в направленный, что, я думаю, потребует дополнительных правил
> >, чтобы ужесточить его. Не стесняйтесь присылать примеры конфигураций.
> >
> > Иоанна
>
>
>
> —
> ++ytti

—
++ytti
_________________________________________________
список рассылки juniper-nsp juniper-nsp@puck. nether.net
https://puck.nether. сеть/почтальон/listinfo/можжевельник-NSP

cra на WPI

18 марта 2020 г., 9:28

Сообщение № 9 из 18 (3376 просмотров)

Постоянная ссылка

В среду, 18 марта 2020 г., в 11:16:54 -05:00, Джон Кристофф написал:
> В среду, 18 марта 2020 г., 16:02:09+0000
> Саку Итти написал:
>
> > Он полностью сломан, вы используете «порт», поэтому вы открываете каждый порт в вашей системе.
>
> Ха, хорошо, спасибо. Я думаю, что это потребует не такой простой подделки
>, если я что-то не упустил. Мы можем преобразовать любой оператор, который просто
> использует порт, в направленный, что, я думаю, потребует дополнительных правил
>, чтобы ужесточить его. Не стесняйтесь присылать примеры конфигураций.

Чтобы обойти ваш фильтр, просто используйте SSH, используя порт источника 179 (bgp), порт назначения 22, и вы находитесь (если вы являетесь соседом BGP для этого конкретного термина):

filter loopback-v4 {
term bgp {
из {
исходный-префикс-список {
bgp-neighbours-v4;
}
протокол TCP;
порт bgp;
}
затем {
count bgp;
принять;
}
}

Исправление:

/* разрешить входящие соединения BGP */
term bgp-inbound {
from {
список-префиксов-источников {
bgp-neighbours-v4;
}
протокол TCP;
исходный порт 1024-65535;
порт назначения bgp;
}
затем {
count bgp;
принять;
}
}
/* разрешить пакеты ответов на исходящие соединения BGP */
term bgp-replies {
from {
source-prefix-list {
bgp-neighbours-v4;
}
протокол TCP;
исходный порт bgp;
порт назначения 1024-65535;
TCP-установлено;
}
then {
количество ответов bgp;
принять;
}
}
______________________________________________
Список рассылки juniper-nsp juniper-nsp@puck. nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

jtk at depaul

18 марта 2020 г., 9:30

Сообщение № 10 из 18 (3376 просмотров)

Постоянная ссылка

В среду, 18 марта 2020 г., 16:18:18 +0000
Саку Итти написал:

> Я установил SPORT на 179
> Я получаю доступ к вашему порту SSH

Да, я все понял. Я могу подтянуть это. Хотите показать нам, как вы
делаете петлевые фильтры?

Джон
_______________________________________________
список рассылки juniper-nsp [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

saku at ytti

18 марта 2020 г., 9:33

Сообщение № 11 из 18 (3376 просмотров)

Постоянная ссылка

В среду, 18 марта 2020 г., в 18:28, Чак Андерсон написал:

> термин bgp-inbound {
> from {
> source-prefix-list {
> bgp-neighbours-v4;
> }
> протокол TCP;
> исходный порт 1024-65535;
Это несущественно, вам все равно, что это за СПОРТ. Будьте либеральны.

> термин bgp-ответы {
> из {
> список-префиксов-источников {
> bgp-соседи-v4;
> }
> протокол TCP;
> исходный порт bgp;
> порт назначения 1024-65535;
Это вас очень волнует, и эфемерный диапазон в вашем устройстве
49125-65535, 1024-49124 может что-то подслушивать в них.

Если у вас есть только клиенты и RR, нет пиров
или что-то еще, где нет «владельца». Вы должны настроить BGP клиента
на пассивный, чтобы клиент _всегда_ запускал BGP,
никогда не пытайтесь его запустить. Точно так же вы должны установить для RR пассивный режим, чтобы клиенты
всегда подключались к RR, а RR — никогда.
Это позволит значительно упростить фильтры для BGP, намного безопаснее, чем
, а также тривиальным способом отдельно контролировать iBGP и eBGP во времена, когда
dddos-защита была недоступна.

—
++ytti
______________________________________________
Список рассылки juniper-nsp juniper-nsp@puck. nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

saku at ytti

18 марта 2020 г., 9:36

Сообщение № 12 из 18 (3376 просмотров)

Постоянная ссылка

В среду, 18 марта 2020 г., в 18:30, Джон Кристофф написал:

> Да, я все понял. Я могу подтянуть это. Хотите показать нам, как вы
> делаете петлевые фильтры?

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

Я не уверен, что в общедоступном шаблоне есть утилита. Но это
то, о чем я иногда думаю, не только о Junos или только о брандмауэре
, но и о BGP, чтобы показать, как нормализовать поведение BGP (никто
не знает точно, какова его политика BGP, так как почти в каждом случае
политика BGP такова). «что бы ни было поставщиком по умолчанию», и когда у вас есть сеть с несколькими поставщиками
, у вас есть разные политики на разных устройствах).

—
++ytti
______________________________________________
Список рассылки juniper-nsp [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

cra на WPI

18 марта 2020 г., 9:53

Сообщение № 13 из 18 (3376 просмотров)

Постоянная ссылка

В среду, 18 марта 2020 г., в 18:33:11 +0200, Саку Итти написал:
> В среду, 18 марта 2020 г. , 18:28, Чак Андерсон написал:
>
> > срок bgp-inbound {
> > from {
> > source-prefix-list {
> > bgp-neighbours-v4;
> > }
> > протокол TCP;
> > исходный порт 1024-65535;
> Это несущественно, вам все равно, что это за СПОРТ. Будьте либеральны.

Верно — узел контролирует его, так что не имеет значения, что это такое.

> > term bgp-replies {
> > from {
> > source-prefix-list {
> > bgp-neighbours-v4;
> > }
> > протокол TCP;
> > исходный порт bgp;
> > порт назначения 1024-65535;
> Это вас очень волнует, а эфемерный диапазон в вашем устройстве
> 49125-65535, 1024-49124 может в них что-то прослушивается.

Спасибо, это полезно. Из оболочки BSD это выглядит как 49160-65535:

% sysctl -a | grep -E ‘portrange.*(first|last)’
net.inet.ip.portrange.lowfirst: 1023
net.inet.ip.portrange.lowlast: 647
net.inet.ip.portrange.first: 49160
net. inet.ip.portrange.last: 65535
net.inet.ip.portrange.hifirst: 49160
net.inet.ip.portrange.hilast: 65535

> Если у вас есть только клиенты и RR, без пиров
> или что-то еще, где нет «владельца». Вы должны установить пассивный
> клиентский BGP, чтобы клиент _всегда_ запускал BGP,
> вы никогда не будете пытаться его запустить. Точно так же вы должны установить для RR пассивный режим, чтобы клиенты
> всегда подключались к RR, а RR — никогда.
> Это позволит значительно упростить фильтры для BGP, гораздо более безопасные, чем
> а также тривиальный способ отдельно контролировать iBGP и eBGP во времена, когда
> dddos-защита была недоступна.

Хорошая идея.
______________________________________________
список рассылки juniper-nsp [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

saku at ytti

18 марта 2020 г., 9:57

Сообщение № 14 из 18 (3376 просмотров)

Постоянная ссылка

В среду, 18 марта 2020 г. , в 18:53, Чак Андерсон написал:

> 49125-65535, 1024-49124, возможно, в них что-то прослушивается.
>
> Спасибо, полезно. Из оболочки BSD это выглядит как 49160-65535:

Вы правы. Я спорил между sysctl или стандартом, и я не уверен, что сделал правильный выбор, выбрав стандарт. В то время моим обоснованием
было то, что если это зависит от платформы, а я этого не делал.0009 хочет проделать работу, чтобы выяснить, всегда ли это 49160 на каждой платформе
и junos, и в итоге получил более либеральный стандартный эфемерный диапазон
.

—
++ytti
______________________________________________
Список рассылки juniper-nsp [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

cra на WPI

18 марта 2020 г., 11:08

Сообщение № 15 из 18 (3374 просмотра)

Постоянная ссылка

В среду, 18 марта 2020 г. , в 18:36:58 +0200, Саку Итти написал:
> В среду, 18 марта 2020 г., в 18:30, Джон Кристофф написал:
>
> > Ага, я все понял. Я могу подтянуть это. Хотите показать нам, как вы
> > делаете петлевые фильтры?
>
> Это ситуативно, универсального придумать сложно. Один
> подход был бы базовым скелетом, поверх которого люди затем расширяли бы
> то, что им нужно, что, вероятно, также затем было бы сломано. Другим вариантом
> было бы написать исчерпывающий, но исчерпывающий обязательно имеет
> компромиссы, так что люди, которым все не нужно, все равно берут эти
> компромиссы.
> На самом деле Juniper был бы в лучшем положении, чтобы автоматически генерировать фильтр
> lo0, когда он не предоставляется, что было бы действительно очень хорошо,
> не оптимально, но действительно хорошо. Немного похоже на сгенерированный LPTS.

Я не согласен с тем, что они были бы хороши в этом — вероятно, он был бы заполнен теми же дырами, которые мы видели здесь, учитывая плохую историю сетевых поставщиков в этой области (см. , и трафик NFS на коммутаторах EX4500, например). Как указывает этот поток, правильно настроить фильтры сложно. Если бы они были жестко запрограммированы Juniper, это просто сделало бы их непрозрачными и неизменяемыми. Мы все выиграли бы от гораздо большей прозрачности и обмена опытом.

> Я не уверен, есть ли утилита в общедоступном шаблоне. Но это
> то, о чем я иногда думаю, не только Junos или просто
> брандмауэр, но также и BGP, чтобы показать, как нормализовать поведение BGP (никто
> не знает, какова их политика BGP очень точно, как почти в каждом случае).
> case Политика BGP — это «то, что всегда является поставщиком по умолчанию», и когда у вас
> сеть с несколькими поставщиками, у вас разные политики на разных устройствах).

Полезность заключается в документировании передового опыта и концепций работы общедоступного шаблона, чтобы его можно было корректировать по мере необходимости. Задокументировать что-то, а затем заявить, что «это неправильно» без предоставления конкретных исправлений/предложений, бесполезно, особенно если все используют шаблоны CYMRU или книгу MX, потому что это лучшая доступная информация.
______________________________________________
Список рассылки juniper-nsp [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

saku at ytti

18 марта 2020 г., 11:24

Сообщение № 16 из 18 (3374 просмотра)

Постоянная ссылка

В среду, 18 марта 2020 г., в 20:09, Чак Андерсон написал:

> Я не согласен с тем, что у них это получится — скорее всего, там будут те же дыры, что и у нас. видно здесь, учитывая плохую историю сетевых поставщиков в этой области (см., например, плохие фильтры, удаляющие трафик IS-IS, IPv6 ND и NFS на коммутаторах EX4500). Как указывает этот поток, правильно настроить фильтры сложно. Если бы они были жестко запрограммированы Juniper, это просто сделало бы их непрозрачными и неизменяемыми. Мы все выиграли бы от гораздо большей прозрачности и обмена опытом.

У Juniper есть скрытая группа, которая применяется к вашей конфигурации, фильтр по умолчанию lo0
может исходить оттуда, если он не настроен. И он может развить
через JTAC. Он может потреблять информацию, которую не может потреблять внешний сайт.

—
++ytti
______________________________________________
Список рассылки juniper-nsp [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

jhealy at logn

18 марта 2020 г., 12:31

Пост №17 из 18 (3374 просмотра)

Постоянная ссылка

Саку,

Спасибо за ответы. Я пытаюсь узнать об этом на ходу…

18 марта 2020 г., в 10:39, Саку Итти написал:
>
> Ваш L2 должен быть в виртуальном -switch/vpls (не подразумевает VPLS)
> экземпляр с фильтром плоскости пересылки, контролирующим BUM. Но не относящийся к
> теме.

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

>> IPMCAST-отсутствует (много таких!)
>
> Вероятно, это ошибки для потока программирования, и последующее будет HW
> переключено. Вы можете захотеть, чтобы ACL отбрасывал весь трафик MCAST на границе.
> Это должно быть 0, если вы на самом деле не запускаете многоадресную рассылку.

Мы применяем фильтр l2 на уровне vlan, чтобы очистить этот коммутатор от всех, кроме хорошо известных многоадресных рассылок. Может ли он по-прежнему добраться до процессора, даже если он заблокирован таким образом? Или назначение потока выполняется до межсетевого экрана уровня 2?

>> ARP
>
> Не требует пояснений? Вы не должны хотеть, чтобы это значение было превышено, в идеале вы
> должны контролировать это на уровне IFD, но я не уверен, что QFX5k может, MX
> может.

Если предположить, что вредоносного трафика нет, не будет ли превышение этого значения счетчика означать, что значения по умолчанию настроены слишком низко? Мы небольшая школа с ~ 1500 устройств. Хотя мы можем получить всплески ARP-трафика в часы пик (например, когда ученики перемещаются между классами), я был бы удивлен, если бы он был настолько высоким, чтобы вызывать беспокойство.

>> TTL
>
> Сообщение о превышении TTL. Нормально бить этого полицейского в uloops.

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

>> Перенаправление
>
> IP-перенаправление, вы, вероятно, захотите отключить их на границе сети. Это
> должно быть 0.

Есть ли простой способ найти/обнаружить IP-перенаправления? Мне любопытно, получены ли они от нашего интернет-провайдера.

>> L3MTU-fail
>
> MTU исходящего трафика слишком мало для пакета. Он предназначен для потенциального создания сообщений ICMP
>. В зависимости от ожидаемой или неожиданной конфигурации.

Мы должны быть большими (9216) повсюду, включая восходящую связь с нашим провайдером. Есть ли способ сузить их?

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

Джейсон
_______________________________________________
Список рассылки juniper-nsp [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

adamv0025 в netconsultings

22 марта 2020 г., 21:57

Сообщение № 18 из 18 (3350 просмотров)

Постоянная ссылка

> Saku Ytti
> Отправлено: среда, 18 марта 2020 г., 16:37
>
> В среду, 18 марта 2020 г., в 18:30, Джон Кристофф написал:
>
> > Ага, я все понял. Я могу подтянуть это. Хотите показать нам, как вы
> > делаете петлевые фильтры?
>
> На самом деле Juniper был бы в лучшем положении для автоматического создания фильтра
> lo0, когда он не указан, что было бы действительно очень хорошо, не
> оптимально, но действительно хорошо. Немного похоже на сгенерированный LPTS.
>
Это, но, что наиболее важно, разделение уровня безопасности уровня управления и уровня управления
, как в XR.
Если бы это можно было сделать в Junos:
XR-пример: внутриполосный интерфейс плоскости управления плоскости управления xxxxxxx разрешить
SSH
-перечисление только моих основных и/или внешних портов управления.
Тогда не имеет значения, что фильтр iACL или lo0 оператора имеет дыры
(разрешающие ssh с исходного порта BGP).

Адам

_______________________________________________
Список рассылки juniper-nsp [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Эрк Субаси ^1* , Бенджамин Таунсенд ² и Ганс Шербергер ²

• ¹ Институт нейроинформатики, Компьютерные науки, Швейцария
• ² Институт нейроинформатики, Швейцария

Мы разрабатываем мозго-машинный интерфейс (ИМТ) для онлайн-декодирования формы хватки у макак. Нейронная активность оценивается с помощью хронически имплантированных электродов в переднюю интратеменную кору (AIP) и вентральную премоторную кору (F5), области, которые, как известно, участвуют в преобразовании визуальных сигналов в инструкции по захвату руки. Обезьян-макак обучали выполнению задачи с отсроченным хватанием, когда они сначала помещали свои руки в состояние покоя и фиксировали красный светодиод, прежде чем хватательная рукоятка была представлена ​​в одном из 5 различных направлений, а цвет светодиода инструктировал животных схватить рукоятку либо с силовым или прецизионным захватом соответственно. После небольшой задержки светодиод фиксации погас, давая указание обезьяне выполнить требуемый захват. Правильные испытания вознаграждались небольшим количеством сока. После успешного обучения 5 плавающих массивов микроэлектродов (FMA; MicroProbe Inc) были имплантированы в AIP (2) и F5 (3) 1 животного. Каждая решетка состояла из 16 платино-иридиевых электродов (длина 1,0-4,5 мм, шаг 0,5 мм). Эта конфигурация была выбрана для облегчения записи активности нейронов в корковых бороздах, а не на поверхности коры. Нейронные сигналы были отобраны с использованием процессора нейронных сигналов (NSP) Cerebus (Cyberkinetics Inc, Foxborough, MA) и переданы в потоковом режиме на выделенный компьютер для декодирования через UDP. Ранее мы сообщали о наших результатах, используя стандартный максимальный апостериорный классификатор (MAP), где мы получили 9Производительность 4% для декодирования типа захвата (точность в сравнении с мощностью), после средней точности 91% для типа захвата и 2 ориентаций захвата (цель наклонена влево или вправо) и, наконец, средняя точность 55% при декодировании полных 10 условий. (тип захвата и 5 ориентаций). Декодирование MAP является одним из стандартных методов в литературе по ИМТ, который, как показано ранее, дает надежные результаты декодирования в аналогичных экспериментах. Но мы делаем 3 общих сильных предположения относительно лежащих в основе вероятностных распределений в структуре MAP. Во-первых, мы предполагаем распределение вероятностей Пуассона для скорострельности каждой отдельной единицы. Во-вторых, чтобы упростить совместное вычисление распределения вероятностей, предполагается, что нейроны возбуждаются независимым образом. В-третьих, предполагается, что эти блоки имеют стационарные распределения вероятностей срабатывания. Важно отметить, что незначительное увеличение производительности декодирования нейронно-протезного устройства может обеспечить существенное улучшение воспринимаемого пользователем качества системы. Здесь мы представляем новый подход к расшифровке дискретных хватательных поз, который не должен полагаться ни на одно из этих предположений. Методы ансамбля приобрели популярность в сообществе машинного обучения за последнее десятилетие как благодаря их сильной теоретической базе, так и практическим результатам. В основном они пытаются оптимально использовать множество слабых учеников в тренировочном наборе для достижения лучшей производительности по сравнению с одним сильным классификатором, уменьшая при этом дисперсию классификатора, а в некоторых случаях также обеспечивая лучшее смещение. Здесь будет представлен сравнительный анализ декодирования с использованием методов адаптивной упаковки и бустинга.

Конференция: Нейроинформатика 2009, Пльзень, Чехия, 6–8 сентября 2009 г.

Тип презентации: Постерная презентация

Тема: Интерфейс мозговой машины

Цитата: Субаси Э, Таунсенд Группа Шербергер ЧАС (2019). Методы ансамбля для повышения производительности декодирования ИМТ, схватывающего руку. Фронт. Нейроинформ. Тезисы конференции: Нейроинформатика 2009. doi: 10.3389/conf.neuro.11.2009. 08.056

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

Авторские права на отдельные рефераты принадлежат автору каждого реферата или его/ее работодателю, если не указано иное.

Каждый реферат, а также коллекция рефератов публикуются под лицензией Creative Commons CC-BY 4.0 (с указанием авторства) (https://creativecommons.org/licenses/by/4.0/) и, таким образом, могут воспроизводиться, переводиться, адаптироваться и быть предметом производных работ при условии указания авторов и Frontiers.

Условия и положения Frontiers см. на странице https://www.frontiersin.org/legal/terms-and-conditions.