The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Нужно ли от части повторно прописывать deny - правила"
Вариант для распечатки Архивированная нить - только для чтения! 
Пред. тема | След. тема 
Форумы Информационная безопасность (Public)
Изначальное сообщение [Проследить за развитием треда]

"Нужно ли от части повторно прописывать deny - правила"
Сообщение от deMan emailИскать по авторуВ закладки(??) on 07-Май-04, 11:39  (MSK)
Привет
Вот постала перед мной задача написать firewall на FreeBSD
Прописал deny по дефолту. Подскажите пожалуста нужно ли от части повторно прописывать deny - правила например для пакетов у которих прописано что они происходят от нашей сетки когда они пришли извне и.т.д.
На первый взгляд ето дубляж - много правил медленей работа, или ето токо на первый взгляд, я про дубляж.
Зарание благодарен.
  Рекомендовать в FAQ | Cообщить модератору | Наверх

 Оглавление

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

1. "Нужно ли от части повторно прописывать deny - правила"
Сообщение от dev emailИскать по авторуВ закладки(??) on 07-Май-04, 14:33  (MSK)
Срабатывает первое подошедшее правило. Поэтому если ты разрешаешь своей сетке чего-нибудь особенное (например, обращение к некоторому сервису), то ты обязан до этого убедиться, что это действительно твоя сетка. Самый надежный путь - поставить deny для пакетов с обратным адресом твоей сетки, но пришедших с внешнего интерфейса.
Вообще лучше первыми же правилами убить все заведомо вредные пакеты.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "Нужно ли от части повторно прописывать deny - правила"
Сообщение от deMan emailИскать по авторуВ закладки(??) on 07-Май-04, 18:09  (MSK)
>Срабатывает первое подошедшее правило. Поэтому если ты разрешаешь своей сетке чего-нибудь особенное
>(например, обращение к некоторому сервису), то ты обязан до этого убедиться,
>что это действительно твоя сетка. Самый надежный путь - поставить deny
>для пакетов с обратным адресом твоей сетки, но пришедших с внешнего
>интерфейса.
Это правило для примера я имел ввиду что пакет соответствуючий этому правилу соответствует и правилу по дефолту побиш дубль правил  
>Вообще лучше первыми же правилами убить все заведомо вредные пакеты.
А с такой позичыей я согласен.


  Рекомендовать в FAQ | Cообщить модератору | Наверх

3. "Нужно ли от части повторно прописывать deny - правила"
Сообщение от brahmann Искать по авторуВ закладки(ok) on 21-Май-04, 10:31  (MSK)
>Вообще лучше первыми же правилами убить все заведомо вредные пакеты.

Здраствуйте, позвольте не согласится, потому как на каждое правило есть его время на обработку... мое мнение - сначала разрешить все что можно(чтобы что надо не тормозилось на обработке), а потом убивать все то что вредное... хотя немогу не согласится, что при критичности к безопасности лутше будет сначала все убить лишнее и плохое, тут похоже выбор будет обусловлен скоростью канала, и требованием безопасности...
  ну сами посудите :) в банке же не будете все подряд пускать :) а для фирмы где только и работает что мускль да веб :) не будете на канале 64кбит/с обезопашивать так что скорость в половину погаснет :) думаю нет ...

  wbr, brahmann

  Рекомендовать в FAQ | Cообщить модератору | Наверх

4. "Нужно ли от части повторно прописывать deny - правила"
Сообщение от DENNN emailИскать по авторуВ закладки(??) on 21-Май-04, 10:40  (MSK)

>что надо не тормозилось на обработке), а потом убивать все то
> не будете на канале 64кбит/с обезопашивать так
>что скорость в половину погаснет :) думаю нет ...
Это как же надо извращенно написать правила, чтоб скорость в половину упала?

даже при канале в 10M/bit величина задержки будет незаметна по сравнению со скоростью прохождения пакета до "ближайшего" российского сайта.

  Рекомендовать в FAQ | Cообщить модератору | Наверх


Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.




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

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