Мы — долго запрягаем, быстро ездим, и сильно тормозим.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
www.lissyara.su
—> документация
|
ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled |
Загружаемый модуль содержит встроенную возможность протоколирования. Для того что бы включить ведение логов и установить предел отчета, есть строки которые нужно установить в
“/etc/sysctl.conf
”, добавляя эти значения ведение логов будет включено при следующей перезагрузке:
|
28.6.2 Опции ядра
Не обязательным является требование включения IPFW следующих опций при компиляции ядра, до тех пор пока вам не понадобилась возможность NAT. Они представлены здесь как дополнительная информация.
|
Эта опция включает IPFW как часть ядра
|
Включается лог пакетов которые прошли через IPFW и имеют установленное ключевое слово "log" в наборе правил.
|
Ограничивает число входящих пакетов зарегестрированных через syslogd. Вы можете захотеть использовать эту опцию во враждебном окружении, в которой вам потребуется протоколировать активность брэндмауэра. Эта возможность закроет возможные denial of service атаки, через флудинг syslog'а.
|
Эта опция позволит всему проходить через файрволл по умолчанию, неплохая идея если вы только начинаете настроивать файрволл.
|
Эти опции точно такие же как и для IPv4, только они для IPv6. Если вы не используете IPv6 вы возможно захотите использовать IPv6FIREWALL без всяких правил для блокировки все IPv6.
|
Эта опция включает использование NAT
Примечание: если вы не включаете IPFIREWALL_DEFAULT_TO_ACCEPT или набор ваших правил позволяет входящие пакеты, вы блокируете все пакеты идущие к вам и от вашей машины.
28.6.3 Опции
“/etc/rc.conf
”
Включаем файрволл:
|
Для выбора одного из правил по умолчанию, идущих с FreeBSD, выберите одно прочитав файл
“/etc/rc.firewall
” и внесите в него следующее:
|
Возможные значения для этой установки следующие:
|
Возможно использование двух разных путей, для загрузки разных правил для файрволла
“[bjipfw[/b]
”. Первое - это установка переменной
“firewall_type
” в абсолютном пути к файлу, которая содержит правила для файрвола без всяких опций командной строки для самого ipfw. Простой пример набора правил следующий:
|
С другой стороны, можно установить переменную
“firewall_script
” в абсолютном пути запускаемого скрипта, который содержит ipfw команды которые запускаются во время загрузки системы. Правильный набор правил в скрипте, будет эквивалентен набору правил в файле, показанному выше, следующий:
|
Примечание: Если
“firewall_type
” установлен в
“client
” или в
“simple
”, правила по умолчанию находятся в
“/etc/rc.firewall
” должны быть рассмотрены для заполнения конфигурационного файла данной машины. Так же учтите, что примеры используемые в этой главе предусматривают что
“firewall_script
” установлен в
“/etc/ipfw.rules
”.
Включаем протоколирование:
|
Внимание: Единственная вещь, которую сделает переменная
“firewall_logging
”, это присвоит
“1
” значению переменной
“net.inet.ip.fw.verbose
” в
“sysctl
” (смотрите секцию 28.6.1). В
“rc.conf
” нет переменной которая устанавливает ограничение на файл логов, но значение может быть установлено через переменную
“sysctl
”, вручную или из файла
“/etc/sysctl.conf
”:
|
Если ваша машина работает как гейт, то есть, осуществляет трансляцию адресов (NAT) через natd, пожалуйста обратитесь к секции 29.8, для информации относительно опций в
“/etc/rc.conf
”.
28.6.4 Команды IPFW
Команды ipfw - обычное средство для создания одного правила, или добавления или удаления активного внутреннего правила файрвола, пока он загружен. Проблема использования данного метода состоит в том, что пока ваша система не выключится или зависнет, все правила которые были добавлены, или изменены, или удалены, потеряются. Запись всех правил в файл и использование этого файла для загрузки правил во время загрузки системы, или массовое замещения выполняемых в данный момент правил файрволла, изменениями которые вы записали в файл - рекомендованный метод, который здесь используется.
Комманда ipfw все еще очень полезна, для вывода используемых правил файрвола на консольный экран. Считывающее средство IPFW, динамически создает счетчик для каждого правила, которое считает каждый пакет, который совпадает с правилом. В течении процесса проверки правила, список правил с счетчиком является одним из способов определить функционирование правила.
Последовательный список всех правил:
|
Список всех правил, с пометкой времени, когда правило последний раз совпадало:
|
Список собранной информации, количество совпавших с правилами пакетов, наряду с самими правилами.
Первая колонка, номер правил, сопровождаемая количеством совпавших исходящих пакетов, следующее за
номером входящих совпавших пакетов и затем, само правило.
|
Список динамических правил добавленных к статическим:
|
Так же показывает список истекших динамических правил:
|
Сбрасывает счетчики:
|
Сбрасывает счетчики только для правила NUM:
|
28.6.5 Набор правил IPFW
Набор правил это группа правил ipfw написанных для пропускания или отбрасывания пакетов основанных на значениях содержащихся в самих пакетах. Двунаправленный обмен пакетов между хостами, включает диалог сессии. Набор правил устанавливает процесс пакета дважды: первый когда он пребывает из общего интернет хоста, и второй раз, когда он отправляется к общему хосту в интернете. Каждый сервис tcp/ip (т.е. telnet, www, mail, и так далее) предопределен в соответствии с протоколом и номером порта. Это основные критерии используемые при создании правил которые пропускают или отбрасывают сервисы.
Когда пакет входит в файрволл, он сопоставляется с первым правилом в наборе и увеличивается на единицу за количество перемещений сверху вниз в списке по возрастанию номера правила в порядке следования. Когда пакет совпадает с выбранными правилами, значение области действия правил выбрано, для этого пакета поиск правил заканчивается. В поиске это упоминается как "первое совпадение побеждает". Если пакет не совпадает ни с одним из правил, он ловится принудительно правилом по умолчанию в ipfw, с номером 65535 которое отбрасывает все пакеты без отправления назад по тому же пути.
Примечание: Поиск будет продолжен, после count, skipto и tee правил.
Инструкции содержащиеся здесь базируются на использовании правил, которые содержат состояния "keep state", "limit", "in"/"out", а так же через опции. Это основа написания правил и включаемых типов в набор правил файрволла.
Включаемый набор правил файрволла только позволяет проходить сервисам через совпадения с правилами. Таким образом, вы можете контролировать какие сервисы пройдут от вас в интернет, и какие сервисы получат доступ к вашей частной сети из интернета. Все остальное будет отброшено по умолчанию. Включаемые наборы правил намного более безопасны, чем исключающие наборы, и это единственный тип правил рассматриваемый здесь.
Внимание: Когда работаете с правилами файрволла будьте внимательны, вы можеть заблокировать себя.
28.6.5.1 Синатксис Правил
Синтаксис правил представленный тут, был упрощен потому, что необходимо создать стандарт правил файрволла включаемого типа. Для более полного описания синтаксиса правил смотрю5ю1справочную страницу ipfw.
Правила содержат ключевые значения: эти ключевые значения должны быть написаны в определенном порядке, слева направо в строчку. Ключевые слова выделены жирным. Некоторые ключевые слова имеют подопции, которые сами могут быть ключевыми словами и так же включать еще больше подопций.
# - используется для отметки начала комментария, и может следовать до конца строки правила или содержать собственные строки. Пустые строки игнорируются.
|
28.6.5.1.1 CMD
Каждое новое правило, должно предворяться
“add
”, для того что бы добавить правило во внутреннюю таблицу.
28.6.5.1.2 RULE_NUMBER
Каждое правило должно иметь номер правила, для работы с ним.
28.6.5.1.3 ACTION
Правило которое может быть ассоциировано с одним из следующих действий, которые будут запущены когда пакет совпадает с выбранным критерием правила.
|
Все это означает ту же самую вещь, которая позволяет пакетам, которые совпадают с правилом, выйти из обработки правил брэндмауэром. Поиск заканчивается на этом правиле.
|
Сравнивает пакет с динамической таблицей правил. Если найдено совпадение, выполняется действие, связанное с правилом которое создало это динамическое правило, иначе переходит к следующему правилу. Check-state не имеет критериев выбора. Если ни одно check-state состояние не найдено в наборе правил, динамическая таблица правил проверятся на первые keep-state или limit правила.
|
Оба слова значат тоже самое, что и отбрасывание пакетов которые совпадают с этим правилом. Поиск заканчивается на этом правиле.
28.6.5.1.4 Протоколирование
|
Когда пакет совпадает с правилом, с ключевым словом
“log
”, сообщение будет сохранено syslog'ом в логе с именем SECURITY. Протоколирование только произойдет если количество пакетов которые будут запротоколированы для определенного правила не превысит параметр logamount. Если logamount не определен, лимит берется из переменной в sysctl - net.inet.ip.fw.verbose_limit. В обоих случаях значение ноль удаляет лимит логов. Тогда когда лимит будет достигнут, протоколирование можно будет запустить заново, очистив счетчик протоколирования, или счетчик пакетов для этого правила. Смотрите команду сброса логов ipfw.
“
Примечание: Протоколирование завершается после того, как состояние всех других пакетов будет успешно подтверждено и перед выполнением заключительного действия (accept
”,
“deny
”) над пакетом. Вам решать какое правило вы хотите протоколировать.
28.6.5.1.5 Отбор
Ключевое слово описаное в данном разделе используется для описания атрибутов пакета, который будет опрошен при определении совпадает правило с пакетом или нет. Следующие признаки общего назначения, даны для соответствия и должны использоваться в таком порядке:
|
или любые имена протоколов, содержащиеся в
“/etc/protocols
”, распознаются и могут быть использованы. Значение определенное в протоколе должно быть сопоставимо. Это обязательное требование.
|
from и to используются для сопоставления с IP адресом. Правила должны быть определены для обоих параметров, источника и приемника. any специально ключевое слово, которое совпадает с IP адресом. me - специальное ключевое слово которое совпадает с любым IP адресом заданным на интерфейсе вашей FreeBSD для представления PC где запущен файрволл (то есть как коробки) как "от меня к любому" или от "от любого ко мне", или "от 0.0.0.0/0 к любому" или "от 0.0.0.0/0 ко мне", или "от 0.0.0.0 к любому" или "от 0.0.0.0 ко мне", IP адреса определены как адреса через точку, цифровая форма/длина маски или как один IP адрес без маски. Это обязательное требование. Смотрите эту ссылку для помощи по записям длины маски http://jodies.de/ipcalc.
|
Для протоколов которые поддерживают номера (такие как TCP или UDP). Обязательно нужно написать номер порта сервиса для совпадения. Имена сервисов (из
“/etc/services
”) могут использоваться вместо значений номеров портов.
|
Совпадения для входящих или исходящих пакетов соответственно. in и out - ключевые слова и обязательное написание одного или другого как часть критерия совпадения.
|
Совпадающие пакеты проходящие через определенное имя интерфейса интерфейс. via - ключевое слово которое означает интерфейс который будет всегда проверяться как часть процесса совпадения.
|
Обязательное ключевое слово, которое распознает запрос о начале сессии для TCP пакетов.
|
Обязательное ключевое слово. После совпадения файрволл создаст динамическое правило, чье поведение по умолчанию состоит в том, что бы было совпадение двунаправленного траффика между IP адресом или портом источника и приемника по тому же самому протоколу.
|
Файрволл будет позволять только N соединений с тем же набором параметров, какие определены в правилах. Один или больше исходных и приемных адрессов может быть определено. "limit" и "keep-state" не могут быть использованы в том же правиле. "limit" дает ту же самую функцию состояния как и "keep-state" плюс собственные функции.
28.6.5.2 Опция правил состояний
Фильтр состояний расценивает траффик, как двунаправленный обмен пакетами включая сессию. Он умеет определять установлена ли сессия между оригинальным отправителем и назначением следющим за правильной процедурой двунаправленного обмена. Любые пакеты, которые не соответствуют заголовкам сессии, автоматически отвергаются.
"check-state" используется для определения, в какой момент, в наборе правил IPFW, пакет должен быть проверен в таблице динамических правил. При совпадении, пакет покидает файрвол и продолжает свой путь, новое правило создается динамически для следующего ожидаемого пакета при обмене в течении этой двунаправленной сессии. При несовпадении, пакет продвигается к следующему правилу.
Динамические правила уязвимы для SYN-flood атак, которые открывают большое количество динамических правил. Для предотвращения подобного рода атак, во FreeBSD добавлена новая опция названная limit. Эта опция используется для ограничения числа одновременных сессий, путем опроса полей источника и полей назначения, указанных в опции limit и использования IP адресов пакетов найденых там же, в поиске открытых динамических правил подсчитывая количество правил и IP адресов, если количество больше, чем значение переменной limit, пакет отбрасывается.
28.6.5.3 Протоколирование сообщений файрволла
Выгоды протоколирования очевидны: предоставляется возможность посмотреть логи после активирования правила, которые содержат информацию, какой пакет был отброшен, из какого адреса он пришел и куда направлялся, предоставляя вам серьезную возможность выследить нападающих.
Даже если возможность ведения логов включена, IPFW не создаст правила протоколирования сам. Администратор файрволла решает сам, какое правило в наборе он хочет протоколировать, и добавляет к этому правилу протоколирование. Обычно протоколируются только запрещающие правила, как например, правило запрещающее входящие ICMP пинги. Таким образом, вы увидите все пакеты, которые не совпадают ни с одним правилом, в наборе правил. Протоколирование - это палка о двух концах, если вы не осторожны, то вы потеряетесь в обилии логов и быстро заполните дисковое пространство расширяющимися лог файлами. DoS атаки которые быстро заполняют дисковый массив, одни из самых старых нападений. Эти логи пишутся не только в syslogd, но еще и на выводяться на главную консоль и быстро раздражают.
Опция ядра IPFIREWALL_VERBOSE_LIMIT=5 ограничивает количество сообщений посланных syslogd, относительно совпадения данного пакета правилу. Когда эта опция включена в ядро, число сообщений относительно определенного правила, заключено в определенном числе. Ничего не будет получено от 200 сообщений, которые говорят об одной и той же вещи. Например, 5 сообщений, относительно специфического правила были получены syslogd, остальные идентичные сообщения будут подсчитаны и переданы syslogd следующей фразой:
|
Все сообщения о протоколируемых пакетах записываются по умолчанию в файл
“/var/log/security
”, который определен в файле
“/etc/syslog.conf
”.
28.6.5.4 Создаем скрипт с правилами
Большинство опытных пользователей IPFW создают файл содержащий правила и пишут его на манер запускаемого скрипта. Главная выгода от этого - правила файрволла могут быть обновлены разом без необходимости перезагрузки системы для активации новых правил. Этот метод очень удобен при тестировании новых правил, так как процедура запуска может быть выполнена столько раз, сколько это необходимо. В скрипте вы можете использовать символическую подмену, для написания частоиспользуемых значений и подмены их во многих правилах. Вы увидите это в следующих примерах.
Синтаксис скрипта, который используется здесь, совместим c 'sh', 'csh', 'tcsh' оболочками. Поля с символической подменой, указываются в виде префикса, долларового знака '$' . Символические поля не имеют долларового знака. Значение записываемое в символическое поле должно быть заключено в "двойные кавычки".
Начните ваш файл с правилами, так:
|
Вот, собственно и все. Правила не важны в этом примере, демонстрировалось как используются и заполняются поля символической подмены.
“
Пример выше содержится в файле /etc/ipfw.rules
”, вы можете загрузить эти правила, набрав в командной строке следующее:
|
Файл
“/etc/ipfw.rules
” может находится где угодно и именоваться как угодно.
Те же самое, могжет быть достигнуто загрузкой команд вручную:
|
28.6.5.5 Набор правил состояний
Следующее не NAT набор правил - пример, как написать очень защищеный "включаемый" тип файрвола. Включаемый тип файрвола позволяет пройти через него только совпавшим сервисам, остальное он блокирует по умолчанию. Все файрволлы должены иметь, как минимум, два интерфейса которые должны иметь правила позволяющие файрволлу функционировать.
Все UNIX® подобные операционные системы разработаны для использования интерфейса lo0 и IP адреса 127.0.0.1 для внутреннего взаимодействия с операционной системой. Правила файрволла должны содержать правила, которые позволяют беспрепятственному хождению этих специальных, внутренних пакетов.
Интерфейс, который смотрит в интернет, один из тех, для которого вы пишите правила разрешают и управляют доступом в глобальную сеть, а так же запросами доступа из интернета. Это может быть вашим ppp tun0 интерфейсом или вашим NIC подсоединенным к DSL или кабельному модему.
В случаях, когда один, или более одного NIC, подключены к частному LAN'у за файрволлом, эти интерфейсы должны содержать правила для беспрепятственного хождения пакетов из LAN.
Сперва правила должны быть организованы в три разные секции, все беспрепятственные интерфейсы, публичные исходящие интерфейсы и публичные входящие интерфейсы.
В порядке построения правил, в каждой секции с публичным интерфейсом порядок следования правил следующий: часто используемые идут сначала, затем используемые реже, заключающим правилом должно быть блокирование и протоколирование всего на этом интерфейсе во всех направлениях.
Исходящая секция, в следующем наборе правил, содержит только правило "allow" , которое содержит значения выбора, которые точно идентифицируют сервис для публичного доступа в Интернет. Все правила имеют написанные опции proto, port, in/out, via и keep state. Правила "proto tcp" имеют опцию "setup" для идентификации запроса о начале сессии как сигнальный пакет который будет помещен в таблицу состояний keep-state.
Секция входящих, содержит вначале правила, блокирующие нежелательные пакеты, по двум разным причинам. Первая - блокированные пакеты могут быть частью, наоборот, правильного пакета который может быть пропущен дальнейшими правилами. Вторая - при наличии правила которое явно блокирует выбранные пакеты которые я получаю не часто, и не хочу видеть их в логах, это не дает пакету быть пойманым последним правилом, которое блокирует и протоколирует все пакеты которые не прошли правила. Последнее правило в секции, которое блокирует и протоколирует все пакеты дает вам возможность создать легальные улики для преследования людей, которые атакуют вашу систему.
Другая вещь, которую вы должны принять во внимание - никакого ответа нежелательным пакетам не возвращается, эти пакеты отбрасываются и исчезают. Таким образом, атакующие не имеют понятия, достиг ли пакет вашей системы. Чем меньше атакующий может узнать о вашей системе, тем более она защищена. Когда вы протоколируете пакеты с неизвестными вам номерами портов, посмотрите их номера в /etc/services или посетите http://www.securitystats.com/tools/portsearch.php и поищите номер порта, что бы понять для чего нужен данный номер порта. Посетите эту ссылку, что бы узнать какие номера портов используются троянцами: http://www.simovits.com/trojans/trojans.html.
28.6.5.6 Пример включаемого набора правил
Следующее не NAT набор правил, является полным набором правил включаемого типа. Не будет неправильным, использование данных правил для собственных целей. Всего лишь закоментируйте пропускающие правила для сервисов, которые вам не нужны. Если вы видите сообщения в лог файле, которые вы видеть не хотите, всего лишь добавьте deny правило в секцию входящих пакетов. Вам придется изменить имя интерфейса dc0 в каждом правиле на имя сетевой карты в вашей системе, которая смотрит в интернет. Для пользователя ppp имя будет tun0.
Вы увидите образец использования правил:
Все состояния которые запрашивают начало сессии с интернетом используют keep-state
Все разрешенные сервисы которые приходят из интернета имеют опцию limit для предотвращения флуда
Все правила используют in или out для определения направления
Все правила используют via имя интерфейса, для определения интерфейса через который будет проходить пакет.
Следующие правила идут в
“/etc/ipfw.rules
”.
|
28.6.5.7 Пример NAT и набора правил состояний
Здесь приводятся дополнительные состояния конфигурации, для включения функции NAT в IPFW. В исходный код ядра должна быть добавлена опция 'option divert', к другим опциям IPFIREWALL, скомпилированым в произвольное ядро.
“
В дополнение к обычным опциям IPFW в файле /etc/rc.conf
”, должны быть добавлены следующие.
|
Использование правил состояния с правилами divert nat (Network Address Translation) сильно усложняет логику написания набора правил. Расположение правил 'check-state' и 'divert natd' в наборе правил становится критичным. Это уже не простая логика прохождения через поток. Используется новый тип действий называемый 'skipto'. Для использования команды 'skipto' обязательна нумерация каждого правила, исходя из этого, вы всегда знаете где номер правила "skipto" к которому вы переходите.
Cледующий, непрокоментированный пример, одного метода написания правил, выбранного для объяснения прохождения пакета через набор правил.
Процесс прохождения начинается с первого правила, в верхней строчки файла правил и увеличивается на одно правило за раз, ниже пока не достигнет конца, или пакет не будет проверен по критерию отбора на совпадение и пакет будет отпущен файрволлом. Важно заметить местоположение правил 100, 101, 450, 500, and 510. Эти правила управляют трансляцией исходящих и входящих пакетов и поэтому их keep-state записи в динамической таблице всегда регистрируют адрес частной локальной сети. Далее, обратите внимание на то, что все разрешающие и запрещающие правила определены в направлении движения пакета. Так же учтите, что исходящие запросы на начало сессии в правиле 500 для трансляции адресов.
Предположим, что пользователь локальной сети использует браузер для просмотра страниц. Web страницы используют 80 порт для соединений. Итак, пакет входит в файрволл, он не совпадает с правилом с номером 100, потому, что он выходит, а не входит. Он минует правило 101, потому что это первый пакет и у него нет keep-state записи в динамической таблице. Пакет наконец, добирается до правила 125, и совпадает с ним. Это исходящий пакет, идущий через интерфейс, смотрящий в интернет. Пакет все еще имеет адрес источника, который является адресом в частной локальной сети. При совпадении с правилом, производяться два действия. Опция keep-state запишет это правило в динамическую таблицу keep-state правил и выполнит указанное действие. Действие - это часть информации записаной в динамическую таблицу. В этом случае оно "skipto rule 500". Правило 500 транслирует сетевой IP адрес пакета и выпустит его. Запомните это, это очень важно. Этот пакет проделывает путь до пункта назначения и возвращается обратно, и попадает в начало набора правил. В этот раз, он совпадает с правилом 100 и IP адрес его пункта назначения транслируется обратно в его адрес в локальной сети. Затем он обрабатывается правилом check-state, он находится в таблице существующих сессий и выпускается в локальную сеть. Он идет к компьютеру в локальной сети, который посылал этот пакет и отправляет новый пакет запрашивая другой сегмент данных от удаленного сервера. В этот раз он проверяется правилом check-state, исходящая запись найдена, связанное действие выполняет "skipto 500". Пакет переходит к правилу 500, транслируется и выпускается наружу. С входящей стороны все что приходит, является частью существующей сессии и автоматически обрабатывается правилом check-state и должным образом помещается в правила divert natd. Все что мы должны сделать, это обратиться по адресу отбрасывающему пакеты и поддерживающему только авторизованные сервисы. Предположим, у нас есть сервер Apache работающий за файрволлом и мы хотим, что бы люди в интернете, могли получить доступ к веб сайту. Новый входящий пакет запроса совпадает с правилом 100, и его IP адрес в локальной сети транслируется для файрволла. Пакет проверяется на все гадкие штучки, на которые мы хотим его проверить и, наконец, совпадает с правилом 425. При совпадении, происходят две следующие вещи. Правило пакета записывается в динамическую таблицу keep-state, но на этот раз, все запросы о создании новой сессии, приходящие от исходного IP адреса, ограничены 2. Это защищает от DDoS атак на сервис работающий по определенному порту. Действие допускается, поэтому пакет отправляется в локальную сеть. По возвращению check-state правило расценивает пакет как принадлежащий существующей сессии и отправляет его на правило 500, для трансляции и последующего выпуска на выходной интерфейс.
Пример набора правил 1:
|
Написанное ниже, в значительной степени похоже, на написанное выше, но используется прокоментированный стиль написания правил, дабы помочь неопытным писателям правил IPFW, что правила делают.
Пример набора правил 2:
|
Garibaldi, 2007-06-09 в 13:36:26
Информация просто супер - впервый раз мне удалось найти подробное описание работы ipfw с натом. Огромное спасибо за проделанную работу.
MWNN, 2007-06-15 в 4:30:26
большое спасибо за данную статью
nobody, 2007-06-24 в 0:07:38
Хм.. А это только мне труууудно читать как будто в промте переводили?
L_ninyo, 2007-10-26 в 19:43:15
Спасибо за статью, очень позновательно.
yakuzzza, 2007-12-16 в 19:50:59
В блокирование нетбиоса я бы обязательно добавил 445/tcp, его необходимо фильтровать на внешних интерфейсах например.
Александр, 2008-01-25 в 4:43:34
Правила 20 там где запросы от сетки к днс серверу провайдера надо дописать навсякий случай еще правилами
add allow udp from ${inet} to x.x.x.x 53 keep-state.
Почему то у меня обмениваются udp пакетами. Да и вообще везде записано что DNS работает на udp.
Igor, 2008-01-28 в 16:05:37
Документация просто супер!!! Извините, не удержался, от восхищения. Долго искал, что-то похожее по IPFW. Не хотите ли эту статью передать ребятам пишущим документацию по FreeBSD (http://www.freebsd.org/ru/), а то у них русской версии описания перевода нет, но могли бы сыллку сюда указать, как альтернативу ПРЕКРАСНУЮ!!!
lissyara, 2008-01-28 в 18:51:08
Я писал тем кто занимается русской частью хандбука, и перевод приложил.
=======
Не ответили, скорей всего, потому что пеервод в тексте, а кроме ввыверки его надо тегами облепить...
Это такая же по величине работа как и перевод...
Dmitry Stremkouski, 2008-02-18 в 21:05:33
Несколько пугает применение двух дивертов. Может я не прав, но это несколько не похоже на философию ipfw.
Очень пугает правило:
801 allow ip from any to any
Правильно учить пользователей на основе SIMPLE.
Dark Smoke, 2008-03-27 в 0:29:54
Попробовал последний пример:
и у меня все пакеты ходят только через 2 правила:
00005 774 104843 allow ip from any to any via vr0
и
00801 808 107523 allow ip from any to any
все остальные правила не активны, не одного пакета не прошло.
CaesaR, 2008-04-23 в 22:03:02
Логично, товарисч:) Если вы сказали "Всем ходить везде" - то остальные правила не задействованы просто, + еще не забываемпро правильную нумерацию...
Sergey, 2008-04-28 в 14:26:09
Спасибо за статью!
Sergey, 2009-02-06 в 13:43:40
Спасибо за статью. Лучшего описания на русском я не встречал. Да и вообще очень познавательный и нужный ресурс!
Синати, 2009-03-06 в 15:47:37
28.6.5.1 Синатксис Правил
Подправьте =)
pr0x1ndei, 2009-03-09 в 7:12:37
И очепятку в англицкого
mobilesfinks, 2009-03-25 в 11:47:52
могу отредактировать статью и отослать на хэндбук, если интересует
adre, 2009-04-10 в 7:49:49
Отредактируй и отошли, в чем проблема?
eugene210682, 2009-04-21 в 15:39:13
Как альтернативный вариант предлагаю собственный перевод:
http://eugene210682.livejournal.com/1694.html
(это начало, остальные куски по соседству)
frosty, 2009-06-25 в 16:27:08
статья на 4.9999999 балов из 5ти, и то только потому что не нашол конкретного правила для своих нужд ))) ну я считаю можно изредка и самому подумать )
а вообще автор молодец, давно проглядывал разные статейки по IPFW, а тут нашол сразу все что нужно
автор, твои труды реально помогают людям, спс тебе
пс. копи паст статьи на свою приватную вики )
kerb, 2009-07-31 в 21:19:36
супер!
после прочтения статьи не осталось вопросов, по поводу непонятных мне ранее check-state, keep-state ))
Лучшая статья на русском языке :)
спасибо!
sirge, 2009-12-09 в 19:27:22
В последнем примере очень не хватает правила для разрешения DNS снаружи:
$cmd 399 allow udp from x.x.x.x 53 to any in via $pif
иначе все распознование рубится 400-м правилом.
Криворукий, 2010-01-07 в 23:46:24
Ниодин из приведенных примеров не заработал. Пробовал писать свое, убил месяц и всерано не ходят пакеты.
skul, 2010-01-20 в 21:28:25
И всё же правило
00801 808 107523 allow ip from any to any — настораживает.
У меня без него пакеты не идут в мир.
Что получается, с этим конфигом не действует правило, запрещено все что не разрешено?
skul, 2010-01-20 в 22:08:07
Извините что я опять пишу. Но я помоему перепутал. До правила #801 доходят только исходящие которые прыгают на правило #800 !
А все входящие отбрасываются на #400 и не доходят до 801.
=)
brandelf, 2010-06-22 в 13:58:20
Заметил опечатку:
limit {src-addr | src-port | dst-addr | dst-port} N
Файрволл будет позволять только N соединений с тем же набором параметров, какие определены в правилах. Один или больше исходных и приемных адрессов может быть определено. "limit" и "keep-state" не могут быть использованы в том же правиле. "limit" дает ту же самую функцию состояния как и "keep-state" плюс собственные функции.
Elena, 2011-04-04 в 19:06:41
Очень классная статья, очень помогло!!!
tehnikpc, 2011-12-06 в 10:28:19
"Вам не нужно включать поддержку IPFW в ядро, пока вам не потребуется включить функцию NAT."-это не правда. Модуль ipdivert для NAT можно подгружать при загрузке с помощью опции "ipdivert_load="YES" в /boot/loader.conf.
tehnikpc, 2011-12-06 в 10:40:31
Очень смешные набор правил "open" и "closed" интересно, кто ими пользуется.
Alex Keda, 2011-12-06 в 10:44:10
> Модуль ipdivert для NAT можно подгружать при загрузке ....
начиная с 6.x - если мне память не изменяет
tehnikpc, 2012-06-23 в 9:35:18
\"Перевод англицкого раздела handbook - касающийся IPFW.\"
В официальном руководстве уже тоже перевели http://www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/firewalls-ipfw.html
ano, 2014-08-10 в 23:11:28
...добавлена опция 'option divert', к другим опциям....
Вроде бы ´options IPDIVERT´.
Alex, 2019-03-21 в 13:38:10
оптимизация
deny log logamount 1000 ip from 224.0.0.0/4,240.0.0.0/4,169.254.0.0/16,127.0.0.0/8,0.0.0.0/8,10.0.0.0/8,172.16.0.0/12,100.64.0.0/10,169.254.0.0/16,192.0.2.0/24 to any out via bce0
deny log logamount 1000 ip from 224.0.0.0/4,240.0.0.0/4,169.254.0.0/16,127.0.0.0/8,0.0.0.0/8,10.0.0.0/8,172.16.0.0/12,10.8.0.0/24,100.64.0.0/10,192.168.0.0/16,169.254.0.0/16,192.0.2.0/24 to any in via bce0
или
deny log logamount 1000 ip from 224.0.0.0/4,240.0.0.0/4,169.254.0.0/16,127.0.0.0/8,0.0.0.0/8,10.0.0.0/8,172.16.0.0/12,10.8.0.0/24,100.64.0.0/10,192.168.0.0/16,169.254.0.0/16,192.0.2.0/24 to any in via bce0,em0
Этот информационный блок появился по той простой причине,
что многие считают нормальным, брать чужую информацию не уведомляя автора
(что не так страшно), и не оставляя линк на оригинал и автора — что более существенно.
Я не против распространения информации — только за. Только условие простое — извольте
подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой,
незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
Если соизволите поставить автора в известность — то вообще почёт вам и уважение.
© lissyara 2006-10-24 08:47 MSK
Комментарии пользователей [32 шт.]