>[оверквотинг удален]
>> и поведений и т.д. Но у нас есть злоумышленики, и раз
>> в RFC про это не учтено, или есть проблема в архитектуре,
>> которой пользуются злоумышленики, то изменение поведение компонента - очень часто меняет
>> его поведение с тем, что описано в RFC. И при таком
>> подходе, к примеру, злоумышленику который полагается на RFC, ВНЕЗАПНО, делается ДРОП.
> И еще раз, DROP никак вам не поможет. Одной из сторон безопасности
> является доступность, DROP с этой точки зрения хуже.  http://ru.wikipedia.org/wiki/%D0%98%D0%B...
> Если хотите более глубокого анализа, вот хорошая статья, с шикарным анекдотом в
> конце:
> http://www.zencoder.pro/%D0%BD%D0%B0...

Сначала, хочу сказать спасибо, за грамотную аргументацию, что все реже встречается в интернете вообще и на опеннете в частности.
Статью прочел. Есть возражения. К примеру, вы запретили ssh-сервис для всего интернета, оставив только доверенные подсети (оставим за рамками дискуссии разумность этого подхода, т.к. это просто пример). Точнее, вы установили дефолтную политику в DROP для всей таблицы INPUT (говоря о линуксах). На этом хосте работает 2 службы: sshd и httpd, соответственно, порты 22 и 80. Далее, вы разрешаете для всех службу на 80 порту, а службу на 22 порту - только для доверенных сетей. Соответственно, при политике DROP для атакующего 22 порт будет выглядеть так же, как и все остальные (за исключением 80-го) - закрытым. Но если его настроить в REJECT, в отличие от остальных (как рекомендует в частности статья), то становится понятно, что он filtered. Т.е. такой настройкой мы даем злоумышленнику некоторые сведения о нашем узле сети.
Большая часть имеющихся сканеров не самостоятельно формирует пакеты, а использует стэк OS для этого. Такие сканеры политика DROP существенно замедлит, в отличие от REJECT. А корректных пользователей (доверенные сети) - пропустит без замедления.