Согласен.
Тоже благодарю за аргументацию :-)

Проблемы с DROP и REJECT обычно возникают при неправильной настройке фильтров. Да и в статье, рассматривается сторона сканеров, а не сторона сервера.
По простому REJECT, это DROP + ответ (мы тебя дропнули, иди лесом). Если юзается сканер, то нагрузка при REJECT на ЦПУ возрастает (генерация ответа). Конечно, было бы хорошо юзать интелектуальную систему фаервола, например, если кто-то стучится на порт, мы отвечаем ему раза 3 с помощью REJECT, а дальше просто - DROP, раз ему не доходит... Но чем проще система, там она надежнее.

> Относится, но не является серебрянной пулей, решающей все проблемы безопасности.

Да я и не спорю) совершенно верно) Как писали Брюс Шнайер и Нильс Фергюсон: "Система безопасна на столько, на сколько безопасно ее самое слабое звено"

> Если хотите более глубокого анализа, вот хорошая статья, с шикарным анекдотом в
> конце:

Ну так хоть усложним задачу :-)
по поводу ссылки на вики...
> В качестве стандартной модели безопасности часто приводят модель из трёх категорий:
> конфиденциальность — состояние информации, при котором доступ к ней осуществляют только субъекты, имеющие на неё право;
> целостность — избежание несанкционированной модификации информации;
> доступность — избежание временного или постоянного сокрытия информации от пользователей, получивших права доступа.

Тем, кому у кого нет и не будет прав - DROP :-) и это не идет в разрез со статьей на вики. Т.к. я не палю порты которые доступны пользователям, у которых есть на это право - повышение конфиденциальности их полномочий.
Считаю, что REJECT хорошо применять для случаев, когда ты из доверенной сети (политика drop не актуальна), но не прошел аутентификацию, при прохождении которой порт толжен открыться - accept :-) Логично? Логично.