Исходное сообщение
"Исследование показало плачевное состояние защищённости SOHO-..." Отправлено Аноним, 20-Апр-13 15:52
>[оверквотинг удален] >> и поведений и т.д. Но у нас есть злоумышленики, и раз >> в 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. А корректных пользователей (доверенные сети) - пропустит без замедления.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>[оверквотинг удален] >>> и поведений и т.д. Но у нас есть злоумышленики, и раз >>> в RFC про это не учтено, или есть проблема в архитектуре, >>> которой пользуются злоумышленики, то изменение поведение компонента - очень часто меняет >>> его поведение с тем, что описано в RFC. И при таком >>> подходе, к примеру, злоумышленику который полагается на RFC, ВНЕЗАПНО, делается ДРОП. >> И еще раз, DROP никак вам не поможет. Одной из сторон безопасности >> является доступность, DROP с этой точки зрения хуже. http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D1%8C >> Если хотите более глубокого анализа, вот хорошая статья, с шикарным анекдотом в >> конце: >> http://www.zencoder.pro/%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0-firewall-drop-vs-reject > Сначала, хочу сказать спасибо, за грамотную аргументацию, что все реже встречается в > интернете вообще и на опеннете в частности. > Статью прочел. Есть возражения. К примеру, вы запретили ssh-сервис для всего интернета, > оставив только доверенные подсети (оставим за рамками дискуссии разумность этого подхода, > т.к. это просто пример). Точнее, вы установили дефолтную политику в DROP > для всей таблицы INPUT (говоря о линуксах). На этом хосте работает > 2 службы: sshd и httpd, соответственно, порты 22 и 80. Далее, > вы разрешаете для всех службу на 80 порту, а службу на > 22 порту - только для доверенных сетей. Соответственно, при политике DROP > для атакующего 22 порт будет выглядеть так же, как и все > остальные (за исключением 80-го) - закрытым. Но если его настроить в > REJECT, в отличие от остальных (как рекомендует в частности статья), то > становится понятно, что он filtered. Т.е. такой настройкой мы даем злоумышленнику > некоторые сведения о нашем узле сети. > Большая часть имеющихся сканеров не самостоятельно формирует пакеты, а использует стэк > OS для этого. Такие сканеры политика DROP существенно замедлит, в отличие > от REJECT. А корректных пользователей (доверенные сети) - пропустит без замедления.
	Введите код, изображенный на картинке: