 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Serge 2:5020/400 24 Dec 2003 10:53:41 To : Aleksey Barabanov Subject : Re: так ли необходим сетевой экран? точнее где он необходим и какой? -------------------------------------------------------------------------------- Aleksey Barabanov wrote: > Serge wrote: > Hет. Я ж не китайских философ. Все гораздо проще. Вся эта дискуссия затеяно > с провокационной целью. Это как заговор молчания травматологов о порядке > движения через регулируемый перекресток. Hеобходимость следования правилам > как там так и там это аксиома, а не предмет веры или дискуссии. Ахха. Воот каак. :) >>>Есть еще немаловажная вещь предусмотреть состояния экрана. >>>1.Экран не установлен. >>>2.Экран заблокирован. >>>3.Экран в штатном состоянии. >>>4.Экран в состоянии администрирования. >>>5. ...еще что-то >> >>Oops.. >>В теории, по крайней мере, п.1 не должен отличаться от состояния >>"выкл" физической железки, выполняющей данную роль, потому и вопроса >>об установлении соединения в этой стадии не должно возникать... > Это состояние после старта до проведения всех настроек. Аналогично, все > цепочки очищены, полиси в акцепт, форфард запрещен. >>п.2 - это как? > Тоже что и 1, но полиси в дени. Или если это переходное состояние в > динамической настройке цепочек, то скорее -I 1 по актуальным цепочкам > рестрикты. Мммм.. Изначально, при включении железки, такая ситуация необходима, если, помимо пакетной фильтрации, на компьютере установлены дополнительные сетевые сервисы (что, в общем-то не есть правильно, но повсеместно почему-то практикуемо). Переходные состояния должны быть минимизированы, и, наверное, таки, да, это именно такое состояние... >>п.4 от п.3 не отдичаются (вроде), за тем исключением, что правим >>обычно конфиги, а потом посылаем сигнал на принятие изменений к > Имеется ввиду, что когда мы правим сервисы, то имеет смысл закрыть их извне. Как, оказывается, все пункты взаимосвязаны... И плавно перетекают один в другой. >>сведенью. Тогда попутно возникает другой вопрос... >>"А проводились ли какие изыскания на соответствие текущих реализаций >>сетевых экранов к устойчивости процесса фильтрации в момент перестройки >>внутренней таблицы правил?" >>В курсе кто-нибудь? > Это в том плане, что сначала все в дени, затем строим фильтровую цепочку, а > только потом добавляем переход на созданный фильтр ? Основная мысль вопроса в том, насколько адекватен экран (во всех его текущих реализациях разных версий на разных платформах) в процессе перестройки таблиц правил. В обсуждении чуть выше Vladimir V. Ivanov написал: VVI> Hасколько я помню, в iptables на уровне ядра, можно заменить VVI> атомарно целую таблицу, чем и пользуется iptables-restore. То есть VVI> в iptables при изменении конфигурации штатными утилитами VVI> таких сюрпризов быть не должно. Т.е., как я понимаю, разбирается конфиг, и, если нет ошибок синтаксиса, строится _альтернативная_ таблица, на которую минимально возможной операцией (а.к.а. атомарной) производится переход. Вот. малюсенькая часть ответа есть - iptables, вкомпилированный в ядро [из дальнейшего обсуждения: версия 1.2.9], ведет себя вышеописанным образом: VVI> Hе проверял для входного потока с несколькими COMMIT'ами (ну то VVI> есть с несколькими транзакциями), но в пределах одной транзакции VVI> iptables 1.2.9 распарсивает вход полностью и при обнаружении VVI> синтаксической ошибки отменит её целиком, что даёт ещё один VVI> плюс админу для случая (1). Соответственно очень интересует ответ на вопрос вот именно в таком понимании... -- wbr, Serge --- ifmail v.2.15dev5.1 * Origin: Magistral Telecom JV. (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор Архивное /ru.linux/118461dd3cde1.html, оценка из 5, голосов 10
|
|
|