Мы — долго запрягаем, быстро ездим, и сильно тормозим.

FreeBSD
Очумелые Ручки
OpenBSD
  Демоны
  Web
  Packet Filter
  простой конфиг PF
  конфиг для офисов
  Настройка
  Файловая система
Cisco


www.lissyara.su —> статьи —> OpenBSD —> Packet Filter —> конфиг для офисов

PF: разбираем конфиг для офисов

Автор: Grishun_U_S.


UPD от 24 августа 2010:
Как правильно заметил Azaks, (комментарий 2010-06-30 в 5:42:55):
"По поводу очередей, так как описано шейпить будет только исходящий трафик. Чтобы шейпил входящий надо шейпить на внутреннем интерфейсе." Т.е. пример в статье не совсем корректный. Переделаю если будет время.

PS: долго не мог понять почему у меня на шлюзе, на котором кроме раздачи трафика в локалку крутится rtorrent (для rtorrent выделена отдельная очередь) торрентовский трафик съедал всю полосу download, хотя имел более низкий приоритет по сравнению с остальными очередями. Потом дошло: его download трафик не проходит через внутренний интефейс и соответсвенно не может быть зашейплен. Upload пожалуйста, download нет. Хотя теоретически можно было бы для rtorrenta завести отдельный компьютер и расположить его внутри локальной сети, "за фаерволом".
--

   OpenBSD Packet Filter (PF) — это очень функциональный фаервол, который может практически все, что может потребоваться от фаервола и даже больше. Давайте посмотрим каким образом его можно использовать в нашем офисе и какие выгоды мы получим.

   Наша сеть состоит из 4х пользовательских компьютеров и шлюза с двумя интерфейсами. Имеется симметричный канал в интернет 1Мбит. На шлюзе поднят транспарентый прокси squid с системой управления SAMS*. Сервисы Интернет, к которым разрешено обращаться пользователям (кроме менеджера, он отрублен от инета) локальной сети следующие :
nntp, ntp, dns, www

--
*Примечание. При работе в тандеме со squid transparent, SAMS можно будет настроить на авторизацию только  по IP адресу(ncsa не будет работать).

все остальное запрещаем. Из разрешенного траффика www заворачиваем на прокси, остальное NAT'им.
Кроме того :

  • к одному из компьютеров требуется доступ извне, т.к. менеждер иногда работает из дома;
  • также и к SAMS нужно иметь доступ снаружи;
  • эффективно делим канал между пользователями;
  • есть доступ по ssh как изнутри так и снаружи;
  • защищаем все сервисы от атак dos, spoofing, а сервис ssh также и от bruteforce.

    Схема нашей сети :



    Пару слов о конфигурировании транспарентного прокси :

  • не забудьте собрать его с поддержкой SQUID_PF ;
  • к слушаемому порту добавьте параметр transparent;
    Например,
    http_port 8080 transparent
    

  • на клиентских компьютерах ставим 192.168.0.133 в качестве основного шлюза;

    Скажу сразу, что шифрованный трафик завернуть через прокси не получится (см. здесь и в [9])

    Конфиг буду разбирать "по-секциям", целиком файл скачать можно тут

    1) Макросы :
    (макросы в PF это что-то наподобие строковых переменных в классических языках программирования,
    в которые можно записывать несколько значений. Записать несколько значений можно путем добавления обрамляющих скобок {} в которых список значений указывается через пробел или через запятую)
    
    int_if="re0" # внутренний интерфейс, имеет адрес 192.168.0.133
    ext_if="tun0" # внешний интерфейс, \
    динамический белый адрес (подключение по pppoe)
    dns_serv="153.53.53.53" # адрес нашего DNS сервера
    proxy_if="lo0" # интерфейс, на котором слушает прокси
    proxy_port="8080" # порт прокси
    boss="192.168.0.168" # IP адрес компьютера босса
    buh="192.168.0.100" # IP адрес компьютера бухгалтера
    admin="192.168.0.25" # IP адрес компьютера администратора
    WinPeak="192.168.0.60" # IP адрес компьютера менеджера
    allowed_icmp_types="{ echoreq, unreach }" # разрешенные типы icmp сообщений.
    # Остались неизменными с прошлой статьи. Всякие icmp-редиректы ффтопку.
    #--
    # Cписок немаршрутизируемых адресов, с которых к нам
    # будут долбиться на внешний интерфейс, а мы их будем заботливо писать в лог.
    non_route_nets_inet="{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, \
    10.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, 0.0.0.0/8, 240.0.0.0/4 }" 
    

    Запись интерфейсов в виде
    int_if="re0"
    

    и
    ext_if="tun0"
    

    имеет значительное преимущество перед записью непосредственно IP адресов, как минимум в двух случаях :
    {a} выдается динамический адрес
    {b} есть необходимость получить маску, установленную на интерфейсе.

    Что и имеет место быть в нашем конфиге. В первом случае, при использовании в правилах макроса
    $ext_if
    

    в правила подставиться IP адрес, динамически выданный интерфейсу tun0.

    Во втором случае, мы будем использовать маску подсети интерфейса re0, для определения границ нашей локальной сети. Записывается это так
    $int_if:network
    

    Хотелось бы отметить, что физическому внешнему интерфейсу re1 в целях безопасности вообще не назначено IP адреса.

    Следующая секция  
    2) таблицы
    table <BRUTEFORCERS> persist
    

    Таблицы в PF реализуют динамические списки значений. У нас всего одна таблица, в этот список попадают IP адреса тех, кто превысил лимит подключений в единицу времени к сервису ssh.

    3) Опции

    
    # тем, кто лезет туда куда не нужно вежливо сообщаем что нельзя
    set block-policy return
    set skip on lo0 # не проверяем на lo0
    # изменяем время для состояния установленного tcp соединения,
    # которое по-умолчанию черезчур большое (24часа)
    set timeout { frag 10, tcp.established 3600 }
    # перед тем, как отправить фрагментированный пакет дальше
    # сначала дожидаемся всех его частей
    scrub in all
    

    Если Вас досят — есть смысл поставить вместо "return"
    set block-policy drop
    

    Но делайте это после того, как Ваш конфиг отлажен, потому что такая политика внешне напоминает отказ сетевого оборудования и трудно определить что происходит — то ли это сеть глючит, то ли фаервол блокирует трафик.

    4) Трафик-шейпинг или очереди

    # реальная полоса 1Мбит, а здесь нужно ставить на несколько % меньше
    # ЭТО *ОЧЕНЬ* ВАЖНО! Иначе шейпинг не будет работать!!
    altq on $ext_if cbq bandwidth 970Kb queue \
     { qboss, qbuh, qadmin, qWinPeak, qssh, qdns, qntp, qack }
        queue qboss bandwidth 38% priority 2 cbq ( borrow )
        queue qbuh bandwidth 18% priority 2 cbq ( borrow )
        queue qadmin bandwidth 15% priority 2 cbq ( borrow )
        queue qWinPeak bandwidth 12% priority 3 cbq ( default borrow )
        queue qssh bandwidth 8% priority 4 cbq ( borrow )
        queue qdns bandwidth 2% priority 5 cbq ( borrow )
        queue qntp bandwidth 2% priority 7 cbq ( borrow )
        queue qack bandwidth 5% priority 6 cbq ( borrow )
    

    Сколько % нужно минусовать от реальной полосы — зависит от канала. На асимметричных каналах (например, ADSL) рекомендуются значения до 10% меньше, чем реальная полоса. Лично у меня в локальной сети работало и с 2% .
    Боссу даем 38% ширины канала, бухгалтеру 18% и себе 15%. Приоритеты траффика у нас троих одинаковые (priority 2), когда есть свободная полоса, разрешаем занимать ее (borrow).
       Чем больше priority тем меньше время, которое пакеты будут пребывать в очереди.
    При использовании очередей cbq максимальный priority, который можно поставить равен 7. Если не указывать priority, то по умолчанию она принимается равной 1.
       Трафик к удаленному рабочему столу компьютера WinPeak имеет бОльший приоритет (priority 3). Кроме того, здесь я поставил метку default, согласно синтаксису очередей cbq (одна такая должна быть в любом случае).
    ssh траффик имеет еще больший приоритет (priority 4) и гарантированную ширину канала 8%.
    dns запросы идут нечасто, так что получают (priority 5) и ширину в 2%.
       Запросы синхронизации времени (NTP) пускаем по очереди с максимально возможным в очередях cbq приоритетом, ширина канала 2%.
       И последнее что хотелось бы отметить, это легковесные ACKnowledgement пакеты (еще назыаются квитанциями о получении), которые отправляются получателем для подтверждении принятых пакетов. Очень важно чтобы эти пакеты не застревали в очереди, потому что у отправителя может сработать тайм-аут и он повторно отправит пакеты, на которые не получил подтверждений о получении; priority 6 и ширина канала 5% (т.к. по этой категории пойдут пакеты от ВСЕХ пользователей и сервисов нашей сети).

    5) NAT

    # NAT всех разрешенных портов, кроме www
    nat on $ext_if from $int_if:network to \
    any port { ntp, nntp, domain } -> $ext_if
    # www завернем на прокси
    rdr on $int_if proto tcp from $int_if:network to any port www \
     -> $proxy_if port $proxy_port
    # пробросим порт RDP внутрь нашей сети, на комп WinPeak (комп менеджера)
    rdr on $ext_if proto tcp from any to $ext_if port rdp -> $WinPeak port rdp
    

    # Единственное на чем хотелось бы заострить Ваше внимание
    # - это логичность следования секций.
    # Правила NAT и rdr срабатывают до правил фильтрации,
    # поэтому они и распологаются выше по конфигу.
    # И именно поэтому трафик, который пойдет от клиента по 80
    # порту мы пропускаем по правилу
    # pass in on $int_if  proto tcp from { $boss, $buh, $admin } to \
    # $proxy_if port >>>> $proxy_port <<<< порт 8080!
    # потому что когда будет обрабатываться это правило
    # rdr уже сработает и подменит 80й порт 8080м
    # (а также подменит IP адрес получателя)

    6) Правила фильтрации

    # хорошее начало любых правил :-P
    # Правда! (см. [7])
    block all
    
    # блокируем всяких нехороших людей
    # стандартный антиспуфинг средствами pf
    antispoof log quick for { lo0, $int_if, $ext_if }
    # те, кто ломится на внешний интерфейс с левыми адресами
    block drop in log quick on $ext_if from $non_route_nets_inet to any
    # умников, которые лезут на внутренний интерфейс с любых сетей
    # отличных от 192.168.0.0/24
    block drop in log quick on $int_if from !$int_if:network to any
    # пишем тех, кто ломится к нам на 25 порт. Облегчает работу по
    # определению зараженных компов в локальной сети
    block drop in log quick on { $int_if, $ext_if } proto tcp \
    from any to any port smtp
    # агаааааа, а эти подбирали пароли к ssh
    block drop log quick from <BRUTEFORCERS>
    # всех пишем в лог
    # у меня набегает
    # 10 Мб логов за 5 дней (!), на сервере которому пытаются пролезть на порт smtp
    # и видимо подDoSивают. Главное не забыть настроить
    # ротацию логов man newsyslog.conf
    
    # ssh для локальных юзеров
    pass in on $int_if proto tcp from $int_if:network to $int_if port ssh \ 
     queue ( qssh, qack ) synproxy state ( max-src-conn-rate 1/60, \ 
      overload <BRUTEFORCERS> flush global )
    # и для пользователей с инета
    pass in on $ext_if  proto tcp from any to $ext_if port ssh \
     queue ( qssh, qack ) synproxy state ( max-src-conn-rate 1/60, \ 
      overload <BRUTEFORCERS> flush global )
    
    # synproxy защищает наш сервис ssh от DoS атак, благодаря тому, что
    # сначала САМ устанавливает соединение 
    # (не допуская полуоткрытых состояний),
    # а потом передает установленное соединение сервису.
    # Имеет немного бОльшие накладные расходы по сравнению с keep
    
    # max-src-conn-rate numer/time interval
    # позволяет применить определенные действия
    # к превысившим ограничение по количеству подключений
    # за единицу времени. Здесь я указал максимум 1 подключение 
    # за 60 секунд. Все превысившие это ограничение заносятся в таблицу
    # BRUTEFORCERS и с ними разрываются (flush) установленные 
    # соединения по всем (global) портам. Обратитие внимание, что
    # 1/60 -- очень агрессивная настройка. Не попадитесь под нее сами.
    # В Вашем случае 5/300 возможно будет более актуальным.
    
    
    # разрешаем входящий трафик www, который пойдет через прокси. 
    # Нет смысла в разделении этого трафика по очередям cbq, т.к. :
    # 1. Можем зашейпить его с помощью squid delay pools
    # 2. PF не сможет определить принадлежность трафика к
    # к конкретному пользователю, после того как траф будет
    # пропущен через squid (ведь шейпинг у нас работает на $ext_if).
    pass in on $int_if  proto tcp from { $boss, $buh, $admin } to \
     any port $proxy_port
    
    # пропустим запросы синхронизации времени поступающие на
    # $int_if . Помещаем такие пакеты в самую быструю очередь.
    # Т.к. подтверждение о получении в UDP не высылается
    # то и не указываем вторым параметром имя очереди qack.
    # --
    pass in on $int_if  proto udp from { $boss, $buh, $admin } to \
     any port ntp queue qntp keep state
    
    # Заметьте, что вторым параметром при указании очереди 
    # указывается имя очереди, по которой пойдут ACK пакеты
    # queue ( ИмяОчередиОсновныхПакетов, ИмяОчередиACK_Пакетов )
    #--
    # Для создания
    # состояний UDP пакетов имеет смысл указывать только
    # keep state. Остальные (modulate и synproxy) полезны
    # для tcp.
    
    # Новостные конференции USENET (nntp)
    # вот тут юзеры могут и покачать, шейпим однозначно!
    # от Босса
    pass in on $int_if proto tcp from $boss to any port nntp \
     queue ( qboss, qack ) modulate state
    # от Бухгалтера
    pass in on $int_if proto tcp from $buh to any port nntp \
     queue ( qbuh, qack ) modulate state
    # от -=Админа=-
    pass in on $int_if proto tcp from $admin to any port nntp \
     queue ( qadmin, qack ) modulate state
    
    # modulate -- это почти тот же keep с тем отличием, что
    # при установлении соединения будут сгенерированы
    # высококачественные Initial Sequence Number, которые
    # труднее угадать, соответственно труднее перехватить сессию.
    
    # DNS запросы идут по спец очереди qdns с высоким приоритетом
    # UDP не шлет ACK, qack не используем
    # от Босса
    pass in on $int_if proto udp from $boss to any port domain \
     queue qdns keep state
    # от Бухгалтера
    pass in on $int_if proto udp from $buh to any port domain \
     queue qdns keep state
    # от -=Админа=-
    pass in on $int_if proto udp from $admin to any port domain \
     queue qdns keep state
    
    # входящие соединения с компом WinPeak по порту rdp
    # защищаем с помощью synproxy 
    pass in on $ext_if proto tcp from any to $WinPeak port rdp \ 
     queue ( qWinPeak,  qack ) synproxy state
    # теоретически здесь synproxy уже не нужен
    pass out on $int_if proto tcp from any to $WinPeak port rdp \
     queue ( qWinPeak,  qack ) modulate state
    
    # выходящий через $ext_if ntp траффик
    # здесь пропишем очередь вручную для
    # пакетов, исходящих не из локальной сети, а 
    # непосредственно от сервера
    pass out on $ext_if proto udp from $ext_if to any port ntp \
     keep state queue qntp
    
    # выходящий через $ext_if nntp траффик (tcp)
    pass out on $ext_if proto tcp from $ext_if to any port nntp \
     modulate state
    
    # выходящий через $ext_if www траффик (tcp)
    pass out on $ext_if proto tcp from $ext_if to any port www \
     modulate state
    
    # выходящий через $ext_if dns траффик (udp)
    # здесь пропишем очередь вручную для
    # пакетов, исходящих не из локальной сети, а 
    # непосредственно от сервера
    pass out on $ext_if proto udp from $ext_if to \
     $dns_serv port domain keep state queue qdns
    
    # Возможность доступа к SAMS из внешней сети.
    # Логируем, 
    # защищаем с помощью synproxy .
    pass in log on $ext_if proto tcp from any to $ext_if \
     port www synproxy state
    
    # icmp
    pass log inet proto icmp all icmp-type $allowed_icmp_types
    

    Время от времени таблицу <BRUTEFORCERS> нужно очищать. Кто-то из тех, кто плохо себя вел (подбирая пароли к нашему серверу) сидит на динамическом IP, а кто-то одумался и больше так не будет.

    Очищаем таблицу раз в час, по крону :

    59 * * * * root/sbin/pfctl -t BRUTEFORCERS -T expire 86400
    

    эта команда уберет записи, старшие чем 1 сутки (86400 секунд)


    Обратите внимание, правила pass (in|out) для одного интерфейса указываются всего 1 раз. Например,
    pass in on $inf_if from $Vasya to any
    pass out on $ext_if from $Vasya to any
    

    а не
    pass in on $inf_if from $Vasya to any
    pass out on $inf_if from $Vasya to any
    pass in on $ext_if from $Vasya to any
    pass out on $ext_if from $Vasya to any
    

    Есть одна особенность при использовании очередей ALTQ совместно с NAT, а именно : у нас нет возможности привязать очереди к исходящим через $ext_if интерфейс пакетам, т.е. :
    pass out on $ext_if from $boss to any queue qboss
    

    НЕ будет направлять пакеты от босса в его очередь, потому что сначала сработает NAT и пакеты будут уходить с адресом отправителя $ext_if, а не $boss . Конечно же, остается возможность приоритезации трафика по портам или конкретным диапазонам IP адресов назначения, но это не всегда то, чего бы мы хотели.
    Специально для этого случая (ALTQ+NAT), есть возможность привязки к очередям на этапе, когда адрес отправителя еще можно различить, т.е. на внутреннем интерфейсе. Что и сделано в моем наборе правил :
    pass in on $int_if proto tcp from $buh to any port nntp \
     queue ( qbuh, qack ) modulate state
    

    несмотря на то, что очередь у нас "поднята" на другом интерфейсе
    altq on $ext_if cbq bandwidth 970Kb queue .....
    

    В этом случае PF сам определит, что такие-то пакеты , выходят через интерфейс $ext_if соответствуют
    pass in .... queue ( qbuh, qack )....
    

    и их нужно шейпить.

    in пишется когда инициатором соединения являемся НЕ мы (т.е. НЕ шлюз);
    out пишется когда соединение происходит по нашей инициативе (или по инициативе сети, которую мы представляем);

    Ну и напоследок несколько рецептов :

    1) При обновлении правил, чтобы каждый раз не набирать :
    сначала для проверки правил
    pfctl -nf <путь к конфигу>
    

    а потом для их применения
    pfctl -f <путь к конфигу>
    

    Воспользуйтесь вот этим :

    Скрипт sh (скачать можно тут), который обновляет правила фаервола, если в них нет ошибок
    #!/bin/sh
    
    pfctl -nf /usr/local/etc/pf-casual-rules.cfg
    if test $? = 0; then
        pfctl -f /usr/local/etc/pf-casual-rules.cfg
        echo "rules reloaded"
    else
        echo "there are some mistakes"
    fi
    

    только путь к Вашему конфигу не забудьте поменять.

    2) Бывает так что сервер давно сдан, но просят порт там пробросить или еще что-то открыть/закрыть.
    Это нужно на тот, случай, если Вы доспустили ошибку (но не синтаксическую, а смысловую), заблокировался доступ по ssh и кататься в другой город Вам не с руки.
    Если мне нужно менять правила на сильно удаленной машине поступаю следующим образом :
    2.1) завожу временный файл с правилами, над которыми буду работать, допустим /usr/local/etc/pf-temp-rules.cfg
    2.2) пишу к нему скрипт аналогичный скрипту из пункта 1)
    2.3) ставлю в cron перезагрузку через 10 минут
    делаю с помощью
    #shutdown -r HH:MM
    

    2.4) выполняю скрипт обновления временных правил и если что-то пойдет не так как хотелось бы, то через 10 минут комп перезагрузится и сработают старые правила. Если же с правилами все ОК — убиваю shutdown вручную.

    3) Всегда записывайте правило state там где оно должно быть.
    Т.е. если хотите, чтобы, например UDP пакеты создавали состояние так и пишите :
    pass .... proto udp... >>> keep state <<<
    

    если наоборот, состояния не нужны пишите no state
    pass .... proto udp... >>> no state <<<
    

    Это связано с тем, что в старых версиях PF
    keep state
    

    НЕ дописывается автоматически ко всем правилам фльтрации. Долго думал почему же не работает банальнейшее правило (конфиг состоял из одной строчки)

    pass all
    

    Пакеты уходили, но не возращались....
    Потом только догадался глянуть версию FreeBSD, она оказалась 6.3 . После записи
    pass all keep state
    

    естественно все заработало. Не попадитесь также.

    4) Если есть сомнения в работе очередей — можно посмотреть на их работу в реальном времени командой
    pfctl -vvsq
    

    единичный "снимок" очередей получается с помощью :
    pfctl -vsq
    

    Эти команды покажут сколько пакетов и с какой скоростью прошло по каждой очереди.
       Тоже самое можно посмотреть и для правил фильтрации. Если Вы хотите узнать по какой именно строчке правил проходят пакеты, просто наберите
    pfctl -vsr
    

    или
    pfctl -vvsr
    

    5) Виртуальные интерфейсы и PF.
    Может случиться так, что в момент загрузки правил PF некоторые (например, tun*, ng*) интерфейсы не имеют адреса, это вызовет ошибку и правила не будут загружены. Их следует обновлять в момент когда интерфейс будет иметь адрес либо записывать в конфиге не

    ext_if="tun0"
    

    а непосредственно IP адрес, если он заранее известен
    ext_if="88.77.66.55"
    

    Для ppp у меня работает скрипт :
    ppp привередлив к пробелам в этих конфигах, поэтому пишите именно так.
    ppp.linkup
    MYADDR:
     ! sh -c "/sbin/pfctl -f /etc/pf.basic.007"
    

    ppp.linkdown
    MYADDR:
     ! sh -c "/sbin/pfctl -F all"
    

    При разрыве соединения я поступаю радикально — сбрасываю все правила, потому что для меня актуально делать именно так. Для Вашей ситуации это может оказаться небезопасным и, возможно, загрузка каких-то других (промежуточных) правил Вам больше подойет.

    6) Отладка правил.
    Лично я отлаживаю правила следующим образом :

    сначала разбираюсь с внутренним интерфейсом, а для внешнего пишу временную заглушку
    block all
    pass in on $int_if from .....
    pass in on $int_if from .....
    # заглушка
    pass out on $ext_if from any to any
    

    после того, как разобрался с $int_if можно перейти и к $ext_if.

    Если не срабатывают конкретные строки правил — есть смысл расширить их область действия, а потом постепенно сужать и смотреть после какого изменения перестало работать, например, не работает правило
    pass in on $int_if proto udp from $admin to any port domain \
     queue qdns keep state
    

    пишем
    pass in on $int_if from $admin to any keep state
    

    а дальше добавляем порт, протокол и т.д.

    Рецепт от Peter N.M. Hansteen из "THE BOOK OF PF" :
    "Перед тем как окунуться с головой в Ваш набор правил, Вы можете легко определить а PF ли является источником проблем? Запрещение PF, с помощью команды pfctl -d , чтобы увидеть исчезнет ли проблема может оградить Вас от больших неприятностей." (стр.131, [2])


    Литература :

  • [1] OpenBSD PF FAQ
  • [2] THE BOOK OF PF by Peter N.M. Hansteen
  • [3] Статьи Айзятуллена Рамиля
  • [4] misdocumentos.net
  • [5] Группа товарищей, именующих себя calomel.org
  • [6] pfstat project
  • [7] Шесть самых глупых идей компьютерной безопасности
  • [8] Разбираем простой конфиг PF
  • [9] Linux: Setup a transparent proxy with Squid in three easy steps



    Ссылка на обсуждение: http://forum.lissyara.su/viewtopic.php?f=39&t=10564.

    размещено: 2009-01-10,
    последнее обновление: 2010-08-24,
    автор: Grishun_U_S

    оценить статью:

    Alexander Sheiko, 2009-01-11 в 18:59:51

    Заворачивать на прокси логичнее, не только 80 порт, но и 3128, 8000-8090. Так же неудобно держать прокси на localhost - для https его в броузере прописывают ручками. Что касается шейпинга - шейпят исходящий трафик. Который, в свою очередь, может быть как на внешнем, так и на внутреннем интерфейсе. Непонятно, почему не используется hfsc планировщик. Лучшее,что я видел на тему статьи.

    m0ps, 2009-01-11 в 19:29:14

    Alexander Sheiko, спасибо, оч интересный документик, почитаем'c

    Bobik, 2009-01-12 в 2:18:30

    Ну собственно как и многих чихарда с очередям, и не пониманием принципа работы и последовательности правил. Очереди работают не так, как описаны из-за непонимания. А также из-за непонимания логики работы фильтрация исходящих пакетов работает не так как описана. Союственно перечитай документацию и ман тогда всё поймёшь о чём я говорю. И кстати выходила недавно хороая книга по пф второго издания её прочтёшь и царём станешь. И нелепые ошибки и забляждения пройдут.

    Grishin_U_S, 2009-01-12 в 7:30:34

    Alexander Sheiko, большое спасибо за линк! Почитаем-с.

    grYps, 2009-01-12 в 8:27:13

    По пятому пункту - если имя сетевого интерфейса или группы, взять в круглые скобки, то данное правило будет автоматически меняться при смене адреса закреплённого за интерфейсом:

    pass in on $ext_if from any to ($ext_if) port ssh synproxy state

    Alexander Sheiko, 2009-01-12 в 20:07:38

    Есть ещё один неплохой конфиг для офисов, правда - без шейпинга. С указанием интерфейсов без привязки к адресу:

    http://www.openbsd.ru/files/etc/pf.conf
    http://www.openbsd.ru/files/etc/pf-dual.conf

    Al, 2009-01-13 в 10:43:28

    Если в фильтрующем правиле не указано,какую очеред использовать, то выбирается очередь default из списка очередей данного интерфейса.

    fr33man, 2009-01-13 в 14:13:06

    >Во втором случае, мы будем использовать маску подсети >интерфейса re0, для определения границ нашей >локальной сети. Записывается это так
    >$int_if:network

    Это не маска, а сеть с маской. Типа 192.168.1.0/24, а не просто /24.

    Arch, 2009-01-29 в 18:50:20

    Всегда хотел узнать: как быстро и просто рисовать диаграмки сетей?Чем?Крайне желательно - бесплатным и опенсорнцным, работающим под *nix'ами.

    stigory, 2009-02-10 в 8:34:03

    google+visio+GPL

    Первым в списке выдаст Dia
    Немного кривовата, но для простых задач вполне.

    User, 2009-02-25 в 16:21:03

    Было бы интересно почитать статью по конфигурированию
    пакетного фильтра для офиса с сетью DMZ. Т.е. с тремя сетевыми линками, где сеть DMZ должна быть всегда доступна из интернета, но только с доступом к определённым сервисам на разных серверах. Сейчас как раз настраиваю подобное, но так мало информации, что приходится многое делать по наитию, т.к. опыта в OpenBSD мало, в основном в Linux.

    Grishin_US, 2009-02-25 в 16:43:20

    Это же элементарно, Уотсон!
    Добавляете правила
    для внешнего интерфейса :
    pass in on $ext_if proto tcp from any to $coolserver port $niceport synproxy state
    pass in on $ext_if proto udp from any to $coolserver port $niceport keep state
    и для внутреннего интерфейса :
    pass out on $dmz_if proto { tcp, udp } from any to $coolserver port $niceport keep state

    User, 2009-02-26 в 13:18:40

    Видимо это всё-таки не совсем так ;)
    Вы забыли о локальной сети, ибо если везде drop,
    то они попросту не смогут попасть в DMZ.
    Возможно имеет смысл исключить из правил фильтрации
    LAN + DMZ интерфейсы, а всё отбрасывать на внешнем?
    Тогда будет проще на одном $ext_if разрешить входящий трафик к DMZ (к нужному серверу и нужному порту), а из локальной сети и так будет всё бегать.
    Или это неверно?

    Grishin_U_S, 2009-02-27 в 13:35:36

    Прежде чем "поправлять" научились бы сначала задачу ставить. А так, читайте [2].

    User, 2009-02-28 в 9:05:16

    Аналогично, Уотсон! :)
    Прежде, чем воскликнуть "элементарно" нужно подумать ;)
    Что было непонятно из задачи? Какие буквы неизвестны?
    Если следовать совету "читать пункт [2]", то зачем тогда вообще ваять статьи? Не нужно настолько близко принимать к сердцу, просто так и сказали бы - нет времени или желания писать расширенный вариант статьи. Мне вот было бы интересно прочесть, ибо сейчас не в диковинку такие разветвлённые сети, а внятной документации практически нет по таким примерам, увы. А новичкам очень просто упустить что-то существенное и не очевидное.

    Grishin_U_S, 2009-02-28 в 9:16:14

    Куда пойти сами знаете или подсказать?

    User, 2009-03-01 в 8:40:23

    Вам? Могу указать путь ;)

    User, 2009-03-01 в 8:41:03

    Вам? Могу указать и направить ;)

    Naigo, 2009-05-15 в 12:46:06

    В полном конфиге есть опечатка
    ##--nat & rdr
    nat on $ext_if from $ext_if:network to any port { ntp, nntp, domain } -> $ext_if
    необходимо заменить на
    ##--nat & rdr
    nat on $ext_if from $int_if:network to any port { ntp, nntp, domain } -> $ext_if

    Grishin_U_S, 2009-05-23 в 18:16:19

    Спасибо, исправлено.

    GRooVE, 2009-05-31 в 16:59:50

    Статья может быть и не полная (как я понял из комментов выше), однако написана она грамотно, просто и понятным языком.
    Спасибо автору!

    Konstantine, 2009-06-26 в 22:29:55

    Ндааа помню декабрь 2008, первый раз увидел PF и сразу влюбился.

    jamm, 2009-08-26 в 3:46:17

    Очень позновательная статья. Спасибо автору. Помогает разобраться в специфике синтаксиса и увидеть возможности pf. Непонятным осталось только то как pf должен определять ACK пакеты... Так от всех соединений может и очередь переполнится, и связь замедлится.

    netc, 2009-09-01 в 10:06:11

    Ребята у кого нибудь нормально работают правила с synproxy на интерфейсах tunX

    Например у меня вот такое не работает на ssh, ftp по логике если убрать synproxy

    pass in quick on $ext_if_ppp proto tcp from any to $ext_if_ppp port ssh synproxy state ( max-src-conn-rate 5/300, overload <BRUTESSH> flush global )

    или тоже правило, только для ftp

    вообщем, если не убрать synproxy state и все что после него, то сервис что ftp, что ssh реально не доступен становиться, т.е. с ним не вомозможно вообще установить соединение.

    Причем данная ситуация характерна только, если сервис слушает на tun интерфейсе. На ng работает нормально.

    Но почему-то mpd у меня вообще хреново держит связь - ну просто оченб очень плохо.

    Поэтому вопроса два:

    1. Как обойти все это, и использовать tun
    2. В чем чуть хорошей настройки mpd для соединения с провайдером по pppoe

    Grishin_U_S, 2009-09-03 в 12:11:56

    2jamm: для приоритезации ack используется второй параметр очереди, например ( qbuh, qack ).

    2netc: у меня тоже не работает synproxy на tun.
    Писал в лист рассылок freebsd-pf, а в ответ тишина.
    Решения как такового не нашел, вместо synproxy использую modulate. Второй вопрос не понял.

    netc, 2009-09-14 в 22:43:28

    >2netc: у меня тоже не работает synproxy на tun.

    суть в том, что ppp демон работает отсилы 2 недели потом в No buffer space on device

    советовали ставить mpd как pppoe демон, но увы ситцация с почти дефолтным конфигом еще хуже - вообще че то очень очень тяжко ему. короче совсем не вариант в виде дефолтного конфига mpd + свои логин/пароль

    есть подозрения, что no buffer space on device происходит из-за проблем с железом (паткорды, сетевая) тогда возникает вопрос как с этим бороться в автоматическом режиме?

    Tuxper, 2009-11-30 в 17:15:47

    pass all - и в 6.x будет срабатывать - направление же не указанно (in/out).

    Corebug, 2010-04-09 в 12:36:49

    Гм, а как насчет того, что при шейпинге с применением altq нельзя использовать keep state и иже с ними, иначе весь трафик будет отправлен в очередь по умолчанию? :)

    Corebug, 2010-04-09 в 12:40:30

    pfctl -vvs queue

    Azaks, 2010-06-30 в 5:42:55

    По поводу очередей, так как описано шейпить будет только исходящий трафик. Чтобы шейпил входящий надо шейпить на внутреннем интерфейсе. Сам наступил на грабли эти. По поводу очередей лучше почитать хотя бы здесь http://house.hcn-strela.ru/BSDCert/BSDA-course/apcs02.html#pf-queue

    Grishin_U_S, 2010-06-30 в 21:51:07

    Кстати очень может быть. Проверю — отпишусь как будет время...

    Vsaya, 2010-09-09 в 17:36:35

    Corebug,При keep state всё возвращается в ТУЖЕ ОЧЕРЕДЬ а не в дефолт как многие думают.

    METAJIJI, 2011-11-15 в 18:40:48

    добавьте еще информации про "хитрый" nat для Asterisk (когда Asterisk должен подключаться к sip провайдеру, но никак не подключается), а то в интернете куча статей как делать неправильно (это я про binat) :)

    я решил проблему, указав в конце правила nat для asterisk опцию static-port


    вот выдержка из моего pf.conf
    #Asterisk
    #binat on $ext_if inet from $sip_ip to any -> $ext_ip0 <- так неправильно делать!
    rdr on $ext_if inet proto udp from any to $ext_ip0 port $sip_udp -> $sip_ip
    #http://www.opennet.ru/openforum/vsluhforumID3/61413.html
    # Натим без изменения порта udp трафик на астера
    # Для каждого IP- телефона свое правило трансляции nat.
    # Параметр static-port нужен для сохранения временного порта UDP.
    # Это нужно чтобы удаленный SIP прокси знал к какой сессии привязан наш IP телефон.
    nat on $ext_if inet proto udp from $sip_ip to any -> $ext_ip0 static-port

    rogue, 2012-03-11 в 9:40:25

    Хех.. вспомнил щас как таращился недоумевающи в эту статью 2 года назад еще будучи студентом=)

    ..., 2012-03-31 в 1:50:53

    man at


    Оставьте свой комментарий:
    Ваше имя:   *
    e-mail:  
    жирный
    наклонный
    подчёркнутый
    ссылка
    цвет
    Нынешний год:   *
     


  • Хостинг HOST-FOOD

    2014-07-27, lissyara
    gmirror

    Удалённое создание софтверного зеркала средствами gmirror, на диске разбитом с использованием gpart. Использование меток дисков для монтирования разделов.
    2013-08-20, zentarim
    Scan+Print server FreeBSD 9

    Настройка сервера печати и сервера сканирования под управлением операционной системы FreebSD 9 для МФУ Canon PIXMA MP540
    2011-11-20, BlackCat
    Разъём на WiFi-карту

    Делаем съёмной несъёмную антену на WiFi-карте путём установки ВЧ-разъёма
    2011-09-14, manefesto
    Настройка git+gitosis

    Настройка системы контроля версия исходного кода в связке git+gitosis+ssh
    2011-08-14, zentarim
    Wi-FI роутер + DHCP + DNS

    Настройка Wi-Fi роутера на Freebsd 8 + DNS сервер + DHCP сервер: чтобы Wi-Fi клиенты были в одной подсети с проводными, проводные и беспроводные клиенты получали адреса автоматически по DHCP, кэширующ
    2011-06-15, -ZG-
    Охранная система на FreeBSD+LPT

    В этой статье описана попытка реализации простой охранной системы на базе FreeBSD с подключением к ней охранных устройтсв на LPT порт и видеорегистрацией.
    2011-03-13, terminus
    ng_nat

    Описание работы ng_nat, практическое использование, достоинства и недостатки в сравнении с ipfw nat
    2011-02-20, Капитан
    Nagios+Digitemp

    Статья описывает создание системы оповещения о превышении температуры в специальных помещениях на основе Nagios с использованием программы Digitemp.
    2011-02-17, Le1
    Zyxel Configuration

    Скрипт для массового изменения конфига свичей Zyxel. Берет из файла iplist список ip-шек, заходит последовательно на каждый и выполняет комманды из файла commands, записывая происходящее в лог файл.
    2011-02-16, fox
    hast carp zfs ucarp cluster

    HAST (Highly Available Storage), CARP, UCARP, ZFS, Cluster настройка и одаптация плюс личные размышления…
    2011-02-04, BlackCat
    Восстановление ZFS

    История о том, как был восстановлен развалившийся RAIDZ ZFS-пул (перешедший в FAULTED) с помощью скотча и подручных средств. Или о том, какие приключения ожидают тех, кто не делает резервных копий.
    2011-02-03, Капитан
    1-Wire

    Статья описывает самостоятельное изготовление контроллера DS9097 для съёма показаний с датчиков температуры DS1820 с помощью программы Digitemp.
    2011-01-28, Капитан
    Температура в серверной

    Статья описывает построение системы наблюдения за температурой в помещении серверной с использованием программы Digitemp и выводом графиков в MRTG
    2011-01-21, m4rkell
    Syslog server

    Как то буквально на днях, у нас завалилось, что то в еве) или не в еве не суть. Суть в том, что когда захотели снять логи с хостов esx обнаружили, что хранят эти негодяи логии только за последнии сутк
    2011-01-07, lissyara
    Canon/gphotofs

    Монтирование цифровых фотоаппаратов Canon (PTP) как файловой системы, автоматизация этого процесса через события devd и внешние скрипты.
    2010-12-13, Al
    IPSec

    Описание принципов работы IPSEC и способов аутентификации.
    2010-12-07, manefesto
    FreeBSD on flash

    Было принято решении переехать на USB Flash и установить минимальный джентельменский набор для работы своего роутера. Делаем =)
    2010-12-05, Fomalhaut
    root ZFS, GPT

    Инструкция по установке FreeBSD с использованием в качестве таблицы разделов GPT и в качестве основной файловой системы - ZFS
    2010-09-05, Cancer
    Настройка аудиоплеера на ximp3

    Цели: Простенький аудиоплеер, для того что бы тетя продавец в магазине утром пришла нажала на кнопку Power и заиграла в зале музыка, так же был доступ по сети, общая шара куда можно заливать музыку, к
    2010-08-31, Cancer
    Установка и настройка OpenVPN

    На днях появилась задача - объединить головной офис и 3 филиала в одну сеть через интернет посредством OpenVPN, чтобы люди могли подключаться через RDP к базам 1С на серверах.
    2010-08-25, manefesto
    freebsd lvm

    Использование linux_lvm для работы с LVM разделами из-под FreeBSD. Проблемы которые возники при монтирование lvm раздела
    2010-04-30, gonzo111
    proftpd file auth&quota

    Proftpd - квоты и авторизация из файлов, без использования базы данных и/или системных пользователей
    2010-04-22, lissyara
    tw_cli

    Пошаговая инструкция по восстановлению RAID на контроллере 3ware, из которого выпал один диск. Настройка мониторинга состояния рейда и отчётов о его состоянии на email.
    2010-04-14, fox
    MySQL Master+Master

    MySQL (Master Master) and (Master Slave) Как настроить репликацию…
    2010-03-09, terminus
    DNS zones

    Краткий ликбез про управление DNS зонами. Примеры проведения делегирования прямых и обратных DNS зон.
    2010-03-09, aspera
    Squid+AD (group access)

    Настройка прокси сервера SQUID с автроризацией пользователей в AD. Разделение пользователей на группы
    2010-03-02, BlackCat
    Шлюз: Часть 4

    Настройка дополнительных сервисов: синхронизация времени (OpenNTPD), клиент DynDNS.org.
    2010-03-01, BlackCat
    Шлюз: Часть 3

    Настройка DHCP и DNS серверов для работы внутри частной сети, c поддержкой внутренних (частных зон) DNS, а так же интеграция DHCP и DNS сервисов.
    2010-03-01, BlackCat
    Шлюз: Часть 2

    Конфигурация МСЭ pf для проброса портов с изменением порта назначения и без, а так же поддержки активного режима FTP и ограничения максимального размера сегмента
    2010-03-01, BlackCat
    Шлюз: Часть 1

    Быстрая настройка шлюза/маршрутизатора с установлением PPPoE-соединения, поддержкой NAT и DNS-forwarding.
    2010-02-23, Morty
    darkstat

    Простая считалка траффика, со встроенным веб-сервером. Очень маленькая, может делать отчеты трафика по хостам, портам, протоколам, а также строить графики
    2010-01-23, gonzo111
    squid+sams+sqstat

    Пилим squid и sams - примеры конфигов с объяснениями. Установка SqStat.
    2009-12-19, schizoid
    mpd5 + radius + ng_car + Abills

    Настройка pppoe-сервера с биллинговой системой Abills и шейпером ng_car
    2009-11-16, lissyara
    UFS->ZFS

    Удалённая миграция с UFS на ZFS. Загрузка с раздела zfs. Настройка для работы с малым количеством памяти под архитектурой i386.
    2009-11-13, gx_ua
    fusefs-ntfs

    Установка, настройка и использование fusefs-ntfs, драйвер NTFS, предназанченного для монтирования NTFS разделов под FreeBSD
    2009-11-12, Morty
    LiveCD

    Создание собственного LiveCD с необходимыми вам изменениями, автоматизирование данного процесса, а так же вариант скоростной сборки СД.
    2009-09-27, lissyara
    Samba как PDC

    Контроллер домена - аналог M$ NT4 домена под самбой, без использования LDAP и прочей хиромантии. Просто и быстро =)
    2009-08-30, terminus
    ipfw nat

    Подробное руководство по ipfw nat, сложные случаи конфигурации.
    2009-08-24, levantuev
    HotSpot

    Установка Hotspot системы в общественное заведение.
    2009-08-18, lissyara
    diskless

    Создание бездисковых терминалов под управлением FreeBSD - с загрузкой по сети. Используются для старта rdesktop и подключения к виндовому серверу терминалов.
    2009-07-29, BAV_Lug
    Видеонаблюдение

    Настройка бюджетного варианта видеонаблюдения на удаленном объекте
    2009-07-22, Cancer
    OpenLDAP адресная книга

    Настройка и создание адресной книги на базе OpenLDAP + phpLDAPadmin
    2009-06-30, SergeySL
    AimSniff

    Руководство по созданию системы мониторинга ICQ-переписки на базе AimSniff, использующей базу данных MySQL для хранения и Web-интерфейс WAS (Web Aim Sniff) для просмотра перехваченных сообщений
    2009-06-25, atrium
    Управление правами доступа

    Полномочия пользователей и файлов, принадлежащих им, формирует концепцию ОС UNIX.
    2009-06-16, DNK
    Exim+PgSQL

    Установка почтовой системы exim+pgsql на FreeBSD 7.1
    2009-05-30, mvalery
    HDD(mbr) -> HDD(gpt)

    Как разбить диск размером более 2TB на разделы, сделать загрузочным, а затем перенести на него информацию с рабочей системы — донора.
    подписка

        вверх      
    Статистика сайта
    Сейчас на сайте находится: 11 чел.
    За последние 30 мин было: 51 человек
    За сегодня было
    2856 показов,
    362 уникальных IP
     

      Этот информационный блок появился по той простой причине, что многие считают нормальным, брать чужую информацию не уведомляя автора (что не так страшно), и не оставляя линк на оригинал и автора — что более существенно. Я не против распространения информации — только за. Только условие простое — извольте подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой, незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
      Если соизволите поставить автора в известность — то вообще почёт вам и уважение.

    © lissyara 2006-10-24 08:47 MSK

    Время генерации страницы 0.0738 секунд
    Из них PHP: 51%; SQL: 49%; Число SQL-запросов: 62 шт.
    У Вас отключено GZIP-сжатие в браузере. Размер страницы 168324