Когда что правильно применять?Вот, уже какую неделю пытаюсь разобраться с фаерволом ipfw, прогресс, конечно, есть но не такой внушительный, как хотелось бы.
Вопрос возник после прочтения мана по ipfw,из мана понял что эти управляющие функции позволяют управлять инициализацией соединения, но в каких случая что следует применять так и не разобрался :(
Уважаемые гуру, подскажите, пожайлуста!!
Для конкретикм:
как правильно прописать правило для разрешения установления соединения от пользователя внутренней сети к внешнней по протоколу http, и разрешение получения ответа именно на этот запрос, а не просто входящие соединения по http. И аналогично по другим распространённым протоколам, таким как ftp, https, smpt, pop3, ssh, и т.д.С уважением, Alex123.
>Когда что правильно применять?
>
>Вот, уже какую неделю пытаюсь разобраться с фаерволом ipfw, прогресс, конечно, есть
>но не такой внушительный, как хотелось бы.
>
>Вопрос возник после прочтения мана по ipfw,из мана понял что эти управляющие
>функции позволяют управлять инициализацией соединения, но в каких случая что следует
>применять так и не разобрался :(
>
>Уважаемые гуру, подскажите, пожайлуста!!Смотрите rc.firewall на тему конфигурации simple
>к внешнней по протоколу http, и разрешение получения ответа именно на
>этот запрос, а не просто входящие соединения по http. И
>аналогично по другим распространённым протоколам, таким как ftp, https, smpt, pop3,
>ssh, и т.д.
>
>С уважением, Alex123.как я понимаю вы пользователей в интренет пробрасываете
скорее ipnat или natd
вам нужно блокировать пользователей
все оч простоrc.firewall
#!/bin/shipfw="/sbin/ipfw -q"
${ipfw} -f flush
${ipfw} add 100 check-state# icmp
${ipfw} add 220 deny icmp from any to any in icmptype 5,9,13,14,15,16,17
${ipfw} add 230 pass icmp from any to any
# udp
${ipfw} add 240 pass udp from any 53 to any
${ipfw} add 250 pass udp from any to any 53
# loopback
${ipfw} add 300 pass ip from any to any via lo0
${ipfw} add 320 deny ip from 127.0.0.0/8 to any
# output
${ipfw} add 510 pass tcp from any to me established
${ipfw} add 520 pass udp from me to any
${ipfw} add 530 pass ip from me to any#deny
${ipfw} add 600 deny ip from 192.168.0.1/32 to any
#close
${ipfw} add 65500 deny ip from any to any
примерно так
>[оверквотинг удален]
>>аналогично по другим распространённым протоколам, таким как ftp, https, smpt, pop3,
>>ssh, и т.д.
>>
>>С уважением, Alex123.
>
>как я понимаю вы пользователей в интренет пробрасываете
>скорее ipnat или natd
>вам нужно блокировать пользователей
>все оч просто
>Да нет, всё куда проще, уменя дмашняя сетка (разветвление инета по квартире)
шлюзик на 7 фре с ядерным натом, но хочится обойтись фаерволом на шлюзе, чтоб непариться с защитой компов в лок. сети.по этому хотелось разобратьсяс правилами, которые не дают пользователям вне локалки инициализировать соединения
># icmp
> ${ipfw} add 220 deny icmp from any to any in icmptype
>5,9,13,14,15,16,17Не боитесь в случае диагностики сети - облажаться?
>># icmp
>> ${ipfw} add 220 deny icmp from any to any in icmptype
>>5,9,13,14,15,16,17
>
>Не боитесь в случае диагностики сети - облажаться?ДА сеть то на 4-7 компов -- чё её диагностировать :)
>Когда что правильно применять?keep-state создает динамическое правило, в котором сохраняются ип получателя/отправителя, порты, протокол и т.п. Если при проверке ответного пакета встречается правило check-state, то происходит поиск по атрибутам среди всех динамических правил. При этом считается что ответный пакет проходит через правило с keep-state, которое создало динамическую запись и таким образом счетчики в нем увеличатся. Пример
add 100 check-state
add 110 permit udp from 10.0.0.0/24 to any 53 out via ext-intf keep-stateИсходящие запросы ДНС будут матчиться по 110-му правилу и пропускаться наружу, одновременно будет создаваться динамическая запись о пропущенном пакете.
Когда прийдет ответ, при проверке check-state будет найдена динамическая запись с соотв. ип/портами и пакет будет пропущен внутрь.setup применяется только для протокола tcp и, фактически, идентифицирует первый пакет в устанавливаемом соединениии. Дальше все пакеты идут с флагом established. Пример - разрешить установку соединений наружу на порт 80, а входящие соединения запретить.
add 100 permit tcp from any to any established
add 110 permit tcp from any to any 80 setup out via ext-intf
add 120 deny tcp from any to any 80 setup in via ext-intfеще плюс established в том, что его можно расположить максимально вверху таблицы и сократить кол-во проверок по правилам.
>[оверквотинг удален]
>
>add 100 check-state
>add 110 permit udp from 10.0.0.0/24 to any 53 out via ext-intf
>keep-state
>
>Исходящие запросы ДНС будут матчиться по 110-му правилу и пропускаться наружу, одновременно
>будет создаваться динамическая запись о пропущенном пакете.
>Когда прийдет ответ, при проверке check-state будет найдена динамическая запись с соотв.
>ип/портами и пакет будет пропущен внутрь.
>СПАСИБО!!!
Т.е. правильно ли я понимаю, что правила для хттп можно записать так:add 100 check-state
add 110 allow tcp from 192.168.0.0/24 to any 80,8080 out via ext-intf keep-state
В общем-то да.
Несколько "но". Номера могут быть любые, как получится.
Для многих правил с keep-state надо только одно с check-state.
ext-intf - название вашего и-фа, смотрящего наружу.
Сеть 192.168.0.0/24 приватная, т.е. будет натится. Если нат в ppp то все ок. Если через диверт, то надо учитывать тот факт что после диверта пакет идет дальше по правилам с уже другим ип и динамика может не сработать. Не готов сказать на 100%, надо проверять, но думаю что keep-state и check-state надо ставить по разные стороны от диверта.
Для эксперимента добавляй log в тело правила и tail -f /var/log/security
>[оверквотинг удален]
>Несколько "но". Номера могут быть любые, как получится.
>Для многих правил с keep-state надо только одно с check-state.
>ext-intf - название вашего и-фа, смотрящего наружу.
>Сеть 192.168.0.0/24 приватная, т.е. будет натится. Если нат в ppp то все
>ок. Если через диверт, то надо учитывать тот факт что после
>диверта пакет идет дальше по правилам с уже другим ип и
>динамика может не сработать. Не готов сказать на 100%, надо проверять,
>но думаю что keep-state и check-state надо ставить по разные стороны
>от диверта.
>Для эксперимента добавляй log в тело правила и tail -f /var/log/securityа чем отличаются permit и allow, по словарю одно и тоже :(
натю через кернел нат, список правил в этой темеhttp://ua.opennet.ru/openforum/vsluhforumID10/4041.html
, но он не работает :(
allow | accept | pass | permit - синонимымужик, одно дело поставить на путь истинный, другое дело копаться в чужом хламе
читай доки, экпериментируй, только так можно научиться
>allow | accept | pass | permit - синонимы
>
>мужик, одно дело поставить на путь истинный, другое дело копаться в чужом
>хламе
>читай доки, экпериментируй, только так можно научитьсяСпасибо, а как насчёт логирования можно его поставить без пересборки ядра??, а то у меня ядро 27ч компилится -- проц оч. старый
во время загрузки ядра есть строка загрузки файервола, там написано логирование включено или нет, если нет - только пересобирать