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

Даже трафик изучать не нужно, все расписано в соответствующих RFC.

Фигня, от обновления Виндовс на АРМах и даже серверах жизнеспобность системы не зависит.

Согласен, что усложнит, но не сделает принципиально невозможным.
Причины:
1. Тот кто вешает разрешенные MAC, может ошибиться, забыть и т.д. (специально или нет - другой вопрос).
2. Возможные ошибки (специальные или нет - то же другой вопрос) в ПО самого коммутатора (иногда и такое случается, и не только в коммутаторах, но и в межсетевых экранах).

Ну, можно это сделать в автоматическом режиме при наладке системы.
Подключение любого неизвестного MAC вывести на сигнализацию.
Все неиспользуемые порты отключить.
Доступ к настройкам коммутатора запоролить.
Единственный способ будет - отключить какой-нибудь терминал от сети, и с его MACом включится на тот же порт. Но опять же отключение терминала приведет к срабатыванию сигнализации.

Я привел самый простой способ, а их на самом деле очень много.

И чего? Прервет, есть резервный АРМ ОП.

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

Если есть резервный, то да. Но не всегда они есть. Экономят некоторые деньги.
Вспомнилось. Два сервера системы управления, засинхронизированные между собой. Совершенные близнецы (из одной партии, разные только серийные номера на модулях). Число подключенных к системе управления устройств превысило 100. Один сервак работает нормально, другой через час работы слетает. Переставили все несколько раз. Результат не изменился. Чертовщина какая-то (одинаковое железо, софт поставлен то же одинаково, но один сервак отказывается нормально работать). Дернули из-за бугра представителя разработчика. Пару дней он переписывался и разговаривал с коллегами-разработчиками из-за бугра. Через несколько дней выдали обновление. Все заработало. И такие баги в софте бывают.
Я к чему. Из-за таких багов резервирование на некоторое время может исчезнуть.

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

Добавлено: 2015-07-27 19:54:45

Нет. Лицензия (лицензионный ключ) был на большее число подключаемых устройств. Иначе бы оснований выдернуть сюда разработчика из-за бугра просто не было бы.

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

Насмешливо-недоверчивое отношение к этой теме проистекает от незнания проблемы. Я почему-то уверен, что Ваше отношение изменится, если Вы прочитаете книгу "Уязвимости микропроцессорных реле защиты".

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

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