Блок небольшой компании должен многоадресно передать в их сети?
Обычная проблема с заданиями 'крона' состоит в том, что у них есть нулевая среда - в отличие от этого, 'в' заданиях, которые действительно копируют Вашу среду. Когда что-то работает из командной строки а не из 'крона', мой опыт состоит в том, что 'среда' является одной из наиболее распространенных проблем. Иногда Вы сталкиваетесь с другой проблемой - задания 'крона' не выполняются с терминалом, и иногда программы получают stroppy об этом. Однако это находится в 1%-м диапазоне по сравнению с 99% для проблем среды.
Другая ключевая техника, которую я использую, состоит в том, чтобы всегда выполнять сценарий оболочки от 'крона'; сценарий оболочки гарантирует, что среда установлена правильно и затем запускает реальную программу. Если задание 'крона' дает мне проблемы, я могу затем настроить сценарий, чтобы сделать полезные вещи как это:
{
date
env | sort
set -x
...what was there before adding the debug...
} >/tmp/cron.jobname.$$ 2>&1
Это перенаправляет весь вывод - стандартный вывод и стандартную погрешность - к имени файла. Можно встроить метки времени в имя файла, если Вы предпочитаете это идентификатору процесса. Анализ файлов журнала часто показывает проблемы быстро.
Единственные многоадресные приложения, которые я когда-либо использовал, являются контрольным инструментом Ганглий и ntp при случае (и это не конфигурация NTP по умолчанию так или иначе). Мне не ужасно ясно, сколько многоадресно переданный действительно используется, эти дни в небольших сетях как Вы описывают, таким образом, я не уверен при блокировании, это имеет значение слишком много.
В то же время я не вижу оснований для блокирования его в сети без определенной угрозы. Я голосую за отъезд, он разблокировал в Вашей сети.
Я сказал бы, что блок это в краю Вашей сети только для сейфа, хотя многоадресной передачей по умолчанию не направляется так или иначе, если Вы не проходите дополнительные обручи.
Блокирование Многоадресной передачи на границе имеет некоторые хорошие вещи, идущие для него. При блокировании его внутренне я лично не соглашаюсь с. Это - мнение.
Вот статья SANS, которая могла бы пролить некоторый свет в Многоадресные проблемы безопасности. Кроме того, это могла бы быть хорошая идея осмотреть SF для прошлых вопросов о Многоадресной передаче и заметить шаблон проблем это, которое могло бы потенциально влиять на Вашу сеть.
Существует допустимый аргумент в пользу блокировки вниз всех типов трафика и только открытия, в чем Вы нуждаетесь. Я лично не расширил бы это до блокирования многоадресной передачи внутренне в небольшой сети, но возможно дело вкуса (как sysadmin1138 говорит), а не плоское право или неправильно.
Если кто-то заблокировал это как часть политики заблокировать все, и открывать только вещи им нужно затем, это кажется совершенно рациональным мне.
Если кто-то чувствует прямую угрозу или проблему от многоадресной передачи затем, они могут быть абсолютно корректными (например, у них были проблемы в прошлом, и это - фиксация), или они могут быть маленьким параноиком, который не является тем же как неправильно.
Если этот блок существует однако, потому что кто-то не знает то, что они делают и просто заблокировали все, что генеральный директор, которого считают, звучал "страшным" затем, это... не очень хорошо.