4. Подскажите в чем косяк PF

Подскажите в чем косяк PF

  • A

    Колеги
    Хочу заблокировать несколько сот адресов
    Создал для этого таблицу и правила, но пинги идут подскажите в чем я туплю (
    Адресв в таблицах есть

    pfctl -t ttt -T show
      223.25.242.107

    : pfctl -sr
    scrub in on em1 all fragment reassemble
    scrub in on em0 all fragment reassemble
    anchor "relayd/" all
    block drop in log all label "Default deny rule"
    block drop out log all label "Default deny rule"
    block drop in quick inet6 all
    block drop out quick inet6 all
    block drop quick proto tcp from any port = 0 to any
    block drop quick proto tcp from any to any port = 0
    block drop quick proto udp from any port = 0 to any
    block drop quick proto udp from any to any port = 0
    block drop quick from <snort2c>to any label "Block snort2c hosts"
    block drop quick from any to <snort2c>label "Block snort2c hosts"
    block drop quick from <pfsnortsamout>to any label "Block pfSnortSamOut hosts"
    block drop quick from any to <pfsnortsamin>label "Block pfSnortSamIn hosts"
    block drop in log quick proto tcp from <sshlockout>to any port = ssh label "sshlockout"
    block drop in log quick proto tcp from <webconfiguratorlockout>to any port = http label "webConfiguratorlockout"
    block drop in quick from <virusprot>to any label "virusprot overload table"
    block drop in on ! em1 inet from 85.142.127.32/27 to any
    block drop in inet from 85.142.127.61 to any
    block drop in on ! em0 inet from 192.168.0.0/24 to any
    block drop in inet from 192.168.0.1 to any
    block drop in on em1 inet6 from fe80::20c:29ff:fe00:b34d to any
    block drop in on em0 inet6 from fe80::20c:29ff:fe00:b343 to any
    pass in on lo0 all flags S/SA keep state label "pass loopback"
    pass out on lo0 all flags S/SA keep state label "pass loopback"
    pass out all flags S/SA keep state allow-opts label "let out anything from firewall host itself"
    pass out route-to (em1 85.142.127.33) inet from 85.142.127.61 to ! 85.142.127.32/27 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
    pass in quick on em0 proto tcp from any to (em0) port = http flags S/SA keep state label "anti-lockout rule"
    pass in quick on em0 proto tcp from any to (em0) port = ssh flags S/SA keep state label "anti-lockout rule"
    block drop in quick on em1 reply-to (em1 85.142.127.33) inet from <ttt>to any label "USER_RULE"
    pass in log quick on em1 reply-to (em1 85.142.127.33) inet proto tcp from any to any port = ssh flags S/SA keep state label "USER_RULE: ssh"
    pass in log quick on em1 reply-to (em1 85.142.127.33) inet proto tcp from <stop_allow>to any flags S/SA keep state label "USER_RULE: Stop"
    block drop in log quick on em1 reply-to (em1 85.142.127.33) inet proto icmp from <stop_block>to any label "USER_RULE: Stop"
    block drop in log quick on em1 reply-to (em1 85.142.127.33) inet proto icmp from any to <stop_block>label "USER_RULE: Stop"
    pass in quick on em0 inet from 192.168.0.0/24 to any flags S/SA keep state label "USER_RULE: Default allow LAN to any rule"
    anchor "tftp-proxy/    " all</stop_block></stop_block></stop_allow></ttt></virusprot></webconfiguratorlockout></sshlockout></pfsnortsamin></pfsnortsamout></snort2c></snort2c>

    0
  • A

    Я правильно понимаю это правило все разрешает?

    pass out route-to ( em1 85.142.127.33 ) from 85.142.127.61 to !85.142.127.32/27 keep state allow-opts label "let out anything from firewall host itself"

    0
  • E

    @ar2r:

    Я правильно понимаю это правило все разрешает?

    pass out route-to ( em1 85.142.127.33 ) from 85.142.127.61 to !85.142.127.32/27 keep state allow-opts label "let out anything from firewall host itself"

    Не всё, а только from 85.142.127.61 to !85.142.127.32/27

    0
  • A

    опции route-to
    используется для создания балансировки нагрузки как я прочитал
    зачем она в pfsense ?
    если я удаляю правило
    pass out route-to ( em1 85.142.127.33 ) from 85.142.127.61 to !85.142.127.32/27 keep state allow-opts label "let out anything from firewall host itself"
    То вообще все перестает работать

    И еще вопрос если я хочу заблокировать определенные адреса
    то должен ли я повесить блокирующие правила еще и на LAN?

    0
  • T

    @ar2r:

    И еще вопрос если я хочу заблокировать определенные адреса
    то должен ли я повесить блокирующие правила еще и на LAN?

    Нужно ставить.

    0
  • D

    @Tamriel:

    @ar2r:

    И еще вопрос если я хочу заблокировать определенные адреса
    то должен ли я повесить блокирующие правила еще и на LAN?

    Нужно ставить.

    Обычно блокируется на том интерфейсе, на котором они подключены физически. Исключение если бридж.

    0
  • A

    @dvserg:

    @Tamriel:

    @ar2r:

    И еще вопрос если я хочу заблокировать определенные адреса
    то должен ли я повесить блокирующие правила еще и на LAN?

    Нужно ставить.

    Обычно блокируется на том интерфейсе, на котором они подключены физически. Исключение если бридж.

    Спасибо.
    Но как быть с
    pass out route-to ( em1 85.142.127.33 ) from 85.142.127.61 to !85.142.127.32/27 keep state allow-opts label "let out anything from firewall host itself"
    не понял :(

    Скинул все правила на дефолтовые
    прописал только lan wan
    смотрю rules.debug опять эта строчка висит
    что за бред

    0
  • A

    Эта срока которая все открывает появляется если прописать гатвай.
    Чтотя я не чего не понимаю. В BSD гатвай был прописан в rc.conf
      route-to для работы в pf.conf не требовалось


    0
  • A

    В виртуалке поднял чистую систему
    Всеравно не блокирует  адреса из алиасаов(


    0
  • G

    не тот порядок.
    Применяется ПЕРВОЕ ПОДХОДЯЩЕЕ ПРАВИЛО.
    В твоем случае, на ЛАНе, сначало всем все разрешается, и все везде пускаются, соответственно.
    Нужно:оставить в покое ВАН. Можно там Все в обе стороны смело блокировать, если нет внешнего ИПа(или не нужен на него доступ)
    на ЛАНе:создать единственное правило * My_allow * * * * none
    И все. все остальные будут заблочены по умолчанию.


    0
  • N

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

    0
  • D

    Пусть сначала четко опишет задачу, я никак не вычитаю в топе кроме блокирования нескольких сот адресов. Какие адреса (клиенты или внешние узлы) ?

    0
  • A

    У меня есть список с адресами на которые я должен запретить доступ как наружи так и изнутри
    тоесть чтобы из локалки нельзя было попасть на эти адреса

    В разрешающем правиле другой список адресов которому все всегда разрешено.

    0
  • A

    Это роутер у которого есть внешний IP. За ним локалка.

    0
  • G

    правило на ЛАНе:
    allow * этим_парням_все_везде_можно * * * * none
    block * этим_парням_нельзя_кое-куда * а_именно_сюда * * none
    allow * этим_парням_нельзя_кое-куда * * * * none - означает,что кроме предыдущего правила им везде можно

    правило на ВАНе:
    allow TCP * * WAN_address 22 * - можно отовсюду коннектица на Внешний ИП на стандартный порт по ссш
    allow TCP * * WAN_address 80 * - можно отовсюду коннектица на Внешний ИП на стандартный порт http на веб-интефейс
    allow ICMP * * WAN address * * - выбираем ICMP type "echo" и все могут пинговать твой Внешний ИП(и он будет отвечать)
    block * * * * * * - ничего ломится на мой внешний ИП всем остальным

    0
  • A

    На Wan вообще ничего не прописывать?

    0
  • G

    @ar2r:

    На Wan вообще ничего не прописывать?

    То что будет на ВАНе касается только того, кто сидит за ВАНом, а не твою локалку. Т.е. если у тебя есть веб-сервак в локалке - то нужно настроить проброс портов на этот сервак, а потом разрешить правило на ване. стандарный функционал я уже описал в предыдущем сообщении. Если ничего дополнительного не стоит, то кроме пинга и вэб-морды, желательно на нестандартном(у меня вот на 65534м) https порту, тебе ничего больше не нужно

    0
  • D

    На LAN у меня последнее правило показано неактивным - нужно чтобы было активным чтобы остальные могли работать.
    По желанию перед DNS добавить разрешение для протокола ICMP, чтобы пинги ходили наружу.




    0
  • G

    красиво выглядит!
    только локалка не сможет пинговать интернет -)
    для Allow же просто можно разрешить по всем протоколам.

    0
  • D

    @goliy:

    красиво выглядит!
    только локалка не сможет пинговать интернет -)
    для Allow же просто можно разрешить по всем протоколам.

    По быстрому в виртуалке накидал.

    0
  • A

    @dvserg:

    @goliy:

    красиво выглядит!
    только локалка не сможет пинговать интернет -)
    для Allow же просто можно разрешить по всем протоколам.

    По быстрому в виртуалке накидал.

    Но с самого роутера пинг идет.
    В iptables делаешь denied на интерфейс с указанием ареса и все режется почему тут не так ?
    И там правила на внешнем интерфейсе применяются

    0
  • G

    @ar2r:

    Но с самого роутера пинг идет.
    В iptables делаешь denied на интерфейс с указанием ареса и все режется почему тут не так ?
    И там правила на внешнем интерфейсе применяются

    потому что это НЕ iptables. И правила работают тут Иначе. На мой взгляд гораздо более понятно интуитивно и выглядят и работают. Как? написано в куче манов как по pfsense так и по packet filter'y непосредственно.
    На вкус и цвет товарищей мало.

    0
  • D

    @ar2r:

    Но с самого роутера пинг идет.
    В iptables делаешь denied на интерфейс с указанием ареса и все режется почему тут не так ?
    И там правила на внешнем интерфейсе применяются

    Здесь все дело в конфигурации. В pfSense прописаны общие разрешающие правила на исходящие с интерфейса (из pfSense) пакеты и общие запрещающие правила на входящие в интерфейс пакеты. На месте pf с успехом мог бы оказаться iptables. Идеология такова, что управление трафиком происходит на том интерфейсе, на котором он входит в роутер.

    0
  • A

    Сделал как Вы предложили.
    К сожалению это не сработало  изнутри сети я все ровно
    вижу адреса из таблицы MY_block

    Еще вы писали:
    И еще вопрос если я хочу заблокировать определенные адреса
    то должен ли я повесить блокирующие правила еще и на LAN?

    Нужно ставить.
    Обычно блокируется на том интерфейсе, на котором они подключены физически. Исключение если бридж.


    0
  • A

    Сори все понял порядок правил
    LAN net вниз теперь работает.

    @ar2r:

    Сделал как Вы предложили.
    К сожалению это не сработало  изнутри сети я все ровно
    вижу адреса из таблицы MY_block

    Еще вы писали:
    И еще вопрос если я хочу заблокировать определенные адреса
    то должен ли я повесить блокирующие правила еще и на LAN?

    Нужно ставить.
    Обычно блокируется на том интерфейсе, на котором они подключены физически. Исключение если бридж.

    0
  • G

    Как ты не видишь чтоли, что твое 2ое правило разрешает ВСЕ!
    Поменяй местами последнее и предпоследнее

    0
  • A

    @dvserg:

    @Tamriel:

    @ar2r:

    И еще вопрос если я хочу заблокировать определенные адреса
    то должен ли я повесить блокирующие правила еще и на LAN?

    Нужно ставить.

    Обычно блокируется на том интерфейсе, на котором они подключены физически. Исключение если бридж.

    Я правильно понял если бридж то надо на обоих интерфейсах ?

    0
  • A

    Еще раз извиняюсь как только отправил так сам и увидел  :'(

    @goliy:

    Как ты не видишь чтоли, что твое 2ое правило разрешает ВСЕ!
    Поменяй местами последнее и предпоследнее

    0
  • A

    Я правильно понял если бридж то надо на обоих интерфейсах на LAN и WAN ?
    Или я опять не понял?

    0
  • D

    @ar2r:

    Я правильно понял если бридж то надо на обоих интерфейсах на LAN и WAN ?
    Или я опять не понял?

    Получается, что так. Сам ведь бридж у тебя как интерфейс не выведен?
    Можно еще Floating с опцией Quick.

    0
Log in to reply
 

Products

Services

Support

News

Resources

Company

Our Mission

We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive for past announcements.

© Copyright 2019 Rubicon Communications, LLC | Privacy Policy