The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Исследование показало плачевное состояние защищённости SOHO-..., opennews (??), 20-Апр-13, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


25. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от Аноним (-), 20-Апр-13, 10:25 
NAT не firewall чего тут обсуждать? если администратор вместо firewall использует nat надо подумать о квалификации такого сотрудника и сделать оргвыводы


Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

26. "Исследование показало плачевное состояние защищённости SOHO-..."  +3 +/
Сообщение от Аноним (-), 20-Апр-13, 10:37 
> NAT не firewall чего тут обсуждать? если администратор вместо firewall использует nat
> надо подумать о квалификации такого сотрудника и сделать оргвыводы

Файрволл не защита. А всего лишь средство фильтрации. И X-mas scan никто тащемта не отменял.

Ответить | Правка | Наверх | Cообщить модератору

41. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от anonymous (??), 20-Апр-13, 12:23 
>> NAT не firewall чего тут обсуждать? если администратор вместо firewall использует nat
>> надо подумать о квалификации такого сотрудника и сделать оргвыводы
> Файрволл не защита. А всего лишь средство фильтрации. И X-mas scan никто
> тащемта не отменял.

Политики в DROP не пробовали назначать? Нормально настроенный файрволл не станет отвечать RST-пакетом на некорректное соединение, а просто сбросит его.

Ответить | Правка | Наверх | Cообщить модератору

45. "Исследование показало плачевное состояние защищённости..."  +/
Сообщение от arisu (ok), 20-Апр-13, 12:48 
и это, конечно, очень поможет по самую маковку забитому каналу, например.
Ответить | Правка | Наверх | Cообщить модератору

48. "Исследование показало плачевное состояние защищённости..."  +/
Сообщение от anonymous (??), 20-Апр-13, 12:55 
Речь про x-mas скан, а не ddos.
Ответить | Правка | Наверх | Cообщить модератору

46. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от Аноним. (?), 20-Апр-13, 12:52 
> Политики в DROP не пробовали назначать?

Причем DROP тут?

>Нормально настроенный файрволл не станет отвечать
> RST-пакетом на некорректное соединение, а просто сбросит его.

То есть не нормально настроенный, забивший на RFC.

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

50. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от anonymous (??), 20-Апр-13, 13:00 
>> Политики в DROP не пробовали назначать?
> Причем DROP тут?
>>Нормально настроенный файрволл не станет отвечать
>> RST-пакетом на некорректное соединение, а просто сбросит его.
> То есть не нормально настроенный, забивший на RFC.

Файрволл на то и файрволл, чтобы менять дефолтное поведение системы. По RFC реализовано оно в самом стэке протоколов tcp/ip (в ряде OS, не во всех); файрволл позволяет изменить это поведение в целях безопасности узла сети. Т.е. забивать или не не забивать на RFC решает уже конкретный администратор, и на самом деле, назовите какую-нибудь отрицательную "отдачу" от подобной настройки.

Ответить | Правка | Наверх | Cообщить модератору

53. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от Аноним. (?), 20-Апр-13, 13:07 
> Файрволл на то и файрволл, чтобы менять дефолтное поведение системы. По RFC
> реализовано оно в самом стэке протоколов tcp/ip (в ряде OS, не
> во всех); файрволл позволяет изменить это поведение в целях безопасности узла
> сети. Т.е. забивать или не не забивать на RFC решает уже
> конкретный администратор, и на самом деле, назовите какую-нибудь отрицательную "отдачу"
> от подобной настройки.

RFC792, если коротко,  тормозит нормальную работу, повешивает сессии и генерит сообщения о недоступности узла.

Ответить | Правка | Наверх | Cообщить модератору

60. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от anonymous (??), 20-Апр-13, 13:34 
>> Файрволл на то и файрволл, чтобы менять дефолтное поведение системы. По RFC
>> реализовано оно в самом стэке протоколов tcp/ip (в ряде OS, не
>> во всех); файрволл позволяет изменить это поведение в целях безопасности узла
>> сети. Т.е. забивать или не не забивать на RFC решает уже
>> конкретный администратор, и на самом деле, назовите какую-нибудь отрицательную "отдачу"
>> от подобной настройки.
> RFC792, если коротко,  тормозит нормальную работу, повешивает сессии и генерит сообщения
> о недоступности узла.

В случае корректного обращения с разрешенного узла такого не произойдет. В случае скана - да. Но это уже проблемы сканирующего.

Ответить | Правка | Наверх | Cообщить модератору

64. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от Аноним. (?), 20-Апр-13, 13:48 
> В случае корректного обращения с разрешенного узла такого не произойдет.

Вы уверены?

> В случае
> скана - да. Но это уже проблемы сканирующего.

В том то и дело, что от скана не поможет, только несколько замедлит его: всесто отлупа по ICMP будет соединение отваливаться по таймауту.


Ответить | Правка | Наверх | Cообщить модератору

273. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от Аноним (-), 22-Апр-13, 01:48 
> В том то и дело, что от скана не поможет, только несколько
> замедлит его: всесто отлупа по ICMP будет соединение отваливаться по таймауту.

И то хорошо. Плюс не забивается исходящий канал. А если использовать TARPIT, то еще и атакующему проблемы создаются :)

Ответить | Правка | Наверх | Cообщить модератору

315. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от Аноним (-), 22-Апр-13, 15:10 
>> В том то и дело, что от скана не поможет, только несколько
>> замедлит его: всесто отлупа по ICMP будет соединение отваливаться по таймауту.
> И то хорошо. Плюс не забивается исходящий канал. А если использовать TARPIT,
> то еще и атакующему проблемы создаются :)

Про обычных реальных пользователей, у которых могут быть проблемы вы как-то забыли. Ну и атаки в результате которых забивается канал, т.е. DOS и DDOS блокируются по другому.

Ответить | Правка | Наверх | Cообщить модератору

335. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от Аноним (-), 22-Апр-13, 19:49 
> то еще и атакующему проблемы создаются :)

А это весьма зависит от. Если атакующий например шлет пакеты с RAW сокета - ему вообще все до балды.

Ответить | Правка | К родителю #273 | Наверх | Cообщить модератору

101. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от Аноним (-), 20-Апр-13, 16:07 
> RST-пакетом на некорректное соединение, а просто сбросит его.

А я всегда думал что RST это и есть сброс :). То что можно и просто убить пакет - можно. И именно это выдает файрвол :)

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

202. "Исследование показало плачевное состояние защищённости SOHO-..."  +1 +/
Сообщение от anonymous (??), 21-Апр-13, 10:41 
>> RST-пакетом на некорректное соединение, а просто сбросит его.
> А я всегда думал что RST это и есть сброс :). То
> что можно и просто убить пакет - можно. И именно это
> выдает файрвол :)

RST-пакетом я сокращенно назвал установленный в заголовке TCP пакета флаг RST.
В общем и целом, файрволл может либо "тихо" сбросить пакет (т.е. сброс без ответной реакции), либо сгенерировать что-то вроде "icmp (admin prohibited|port unreachable)" и отослать инициатору.
В случае, когда вас ддосят, генерировать ответные пакеты может быть очень плохой затеей, т.к. вы сами себе забьете исходящий канал - особенно в случае ассиметричного канала (что часто встречается в радиосвязи).

Ответить | Правка | Наверх | Cообщить модератору

75. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от KT315 (ok), 20-Апр-13, 14:16 
Уважаемый! Обьясните мне тогда, что есть средство защиты?
Разве фильтрация не защищает меня от того что я отфильтровал, не? Т.е. фильтрация не относится к средствам защиты?
Поясню школоте, у которых проблемы с понятиями....
Защита - общее понятие средств повышающих уровень безопасности, в ее группу, так сказать входят средства защиты. Так вот фильтрация - одна из средств защиты.
Конечно, если ПО имеет бэкдор или попросту дырявое, то фильтрация его не спасет, т.к. врядли кто-то будет проводить анализ всех пакетов, в том числе и опасных, что бы на основе этого содержимого писать фильтр.

RFC - не панацея. Мир не идеален, и RFC описывают стандарты работы и поведений и т.д. Но у нас есть злоумышленики, и раз в RFC про это не учтено, или есть проблема в архитектуре, которой пользуются злоумышленики, то изменение поведение компонента - очень часто меняет его поведение с тем, что описано в RFC. И при таком подходе, к примеру, злоумышленику который полагается на RFC, ВНЕЗАПНО, делается ДРОП.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

81. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от Аноним. (?), 20-Апр-13, 14:27 
> Уважаемый! Обьясните мне тогда, что есть средство защиты?
> Разве фильтрация не защищает меня от того что я отфильтровал, не? Т.е.
> фильтрация не относится к средствам защиты?

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

> RFC - не панацея. Мир не идеален, и RFC описывают стандарты работы
> и поведений и т.д. Но у нас есть злоумышленики, и раз
> в RFC про это не учтено, или есть проблема в архитектуре,
> которой пользуются злоумышленики, то изменение поведение компонента - очень часто меняет
> его поведение с тем, что описано в RFC. И при таком
> подходе, к примеру, злоумышленику который полагается на RFC, ВНЕЗАПНО, делается ДРОП.

И еще раз, DROP никак вам не поможет. Одной из сторон безопасности является доступность, DROP с этой точки зрения хуже.  http://ru.wikipedia.org/wiki/%D0%98%D0%B...

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

http://www.zencoder.pro/%D0%BD%D0%B0...

Ответить | Правка | Наверх | Cообщить модератору

98. "Исследование показало плачевное состояние защищённости 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. А корректных пользователей (доверенные сети) - пропустит без замедления.

Ответить | Правка | Наверх | Cообщить модератору

108. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от KT315 (ok), 20-Апр-13, 16:47 
Согласен.
Тоже благодарю за аргументацию :-)

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

204. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от Аноним (-), 21-Апр-13, 10:54 
>Тем, кому у кого нет и не будет прав - DROP :-) и это не идет в разрез со статьей на вики.

Ну представьте что у вас публичный ftp в сети или еще какие-нибудь сервисы с динамическими портами, вы знаете что дропать?

Представьте что вы администруете не один сервер, а десяток другой, а то и сотню, вы готовы тратить на возможные проблемы, которые обязтельно возникнут, свое время ?

Ответить | Правка | Наверх | Cообщить модератору

253. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от KT315 (ok), 21-Апр-13, 22:29 
Под разные задачи, свои решения ;-)
FTP - для пассивки нормальный сервер может настраивать диапазон портов. Все, что ниже 1024 - можно применять ДРОП по условию, которое привел выше.
PMP-NAT/uPNP - и что? все равно взаимодействует с фаером, т.к. ставит fwd по определенному порту.
Ну а если что-то еще есть специфическое и экзотическое - то нужно думать с чем его едят и как кормить. Следует понимать, что нет и не будет одного инструмента под все предметы.
В общем любой нормальный специалист и инженер понимает, где какой инструмент лучше всего применить.
Ответить | Правка | Наверх | Cообщить модератору

297. "Исследование показало плачевное состояние защищённости SOHO-..."  +1 +/
Сообщение от Аноним (-), 22-Апр-13, 11:13 
> Все, что ниже 1024 - можно применять ДРОП по условию, которое привел выше.

Можно, но зачем?

>PMP-NAT/uPNP - и что? все равно взаимодействует с фаером, т.к. ставит fwd по определенному порту.

Все хорошо будет пока несколько пакетов не потеряются и клиент не запросит у сервера по закрытому порту, в результате отлуп на пару минут, а когда связь неустойчивая это происходит постоянно. А в это время ваш клиент будет напрягать вашу техподдержку, а техподдержка вас.

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

Беда в том что тут на форуме нет нормальных специалистов.

Ответить | Правка | Наверх | Cообщить модератору

301. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от KT315 (ok), 22-Апр-13, 11:21 
> Все хорошо будет пока несколько пакетов не потеряются и клиент не запросит
> у сервера по закрытому порту, в результате отлуп на пару минут,
> а когда связь неустойчивая это происходит постоянно. А в это время
> ваш клиент будет напрягать вашу техподдержку, а техподдержка вас.

Таки да, то что пакеты теряются... я что-то упустил этот момент, особенно по беспроводным сетям.
В общем, пошел пересматривать политику правил :-)

Ответить | Правка | Наверх | Cообщить модератору

203. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от Аноним (-), 21-Апр-13, 10:50 
> то становится понятно, что он filtered.

Если вас это лично смущает, то подскажу что у REJECT есть возоможность подставить тип ответа.

Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

279. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от Аноним (-), 22-Апр-13, 02:00 
>> то становится понятно, что он filtered.
> Если вас это лично смущает, то подскажу что у REJECT есть возоможность
> подставить тип ответа.

Что даже ACK,SYN можно, как в DELUDE?

Ответить | Правка | Наверх | Cообщить модератору

299. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от Аноним (-), 22-Апр-13, 11:15 
>>> то становится понятно, что он filtered.
>> Если вас это лично смущает, то подскажу что у REJECT есть возоможность
>> подставить тип ответа.
> Что даже ACK,SYN можно, как в DELUDE?

Может вам проще мануал открыть?

Ответить | Правка | Наверх | Cообщить модератору

314. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от Аноним (-), 22-Апр-13, 14:59 
>>> то становится понятно, что он filtered.
>> Если вас это лично смущает, то подскажу что у REJECT есть возоможность
>> подставить тип ответа.
> Что даже ACK,SYN можно, как в DELUDE?

Просто наводка ACK,SYN это флаги протокола TCP, REJECT отвечает по протоколу ICMP.

Ответить | Правка | К родителю #279 | Наверх | Cообщить модератору

205. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от Аноним (-), 21-Апр-13, 10:57 
> Большая часть имеющихся сканеров не самостоятельно формирует пакеты, а использует стэк
> OS для этого.

Да ладно вам, у обычного nmap задержка будет исчисляться милисекундами, максимум секундами.

Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

268. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от Аноним (-), 22-Апр-13, 01:33 
> Файрволл не защита. А всего лишь средство фильтрации.

А средство фильтрации - это, по-вашему, не защита?

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

298. "Исследование показало плачевное состояние защищённости SOHO-..."  +/
Сообщение от Аноним (-), 22-Апр-13, 11:14 
>> Файрволл не защита. А всего лишь средство фильтрации.
> А средство фильтрации - это, по-вашему, не защита?

Нет. Это составная часть защиты.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру