The OpenNET Project / Index page

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

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

"ipfw: точный перевод"
Сообщение от A Clockwork Orange Искать по авторуВ закладки on 15-Янв-04, 20:46  (MSK)
Вот фрагмент стандартного /etc/rc.firewall в том виде каком есть.
Кто может дать точный перевод и разъяснение фрагмента.
Вызывает сомнение порядок чтения фрагмента и выполнение проверки пакета.

....
        ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif}
        ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif}
        ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif}
        ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif}
        ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif}

# Network Address Translation.  This rule is placed here deliberately
# so that it does not interfere with the surrounding address-checking
# rules.  If for example one of your internal LAN machines had its IP
# address set to 192.0.2.1 then an incoming packet for it after being
# translated by natd(8) would match the `deny' rule above.  Similarly
# an outgoing packet originated from it before being translated would
# match the `deny' rule below.
        case ${natd_enable} in
        [Yy][Ee][Ss])
                if [ -n "${natd_interface}" ]; then
                        ${fwcmd} add divert natd all from any to any via ${natd_interface}
                fi
                ;;
        esac

        # Stop RFC1918 nets on the outside interface
        ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif}
        ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif}
        ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif}

......

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

 Оглавление

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

1. "ipfw: точный перевод"
Сообщение от A Clockwork Orange Искать по авторуВ закладки on 15-Янв-04, 21:20  (MSK)
Или вот это

A packet may not have a receive or transmit interface: packets
originating from the local host have no receive interface, while
packets destined for the local host have no transmit interface.


Пакет может не иметь принимающего или передающего интерфейса:
пакет создаваемый локальным хостом не имеет принимающего интерфейса (позвольте но интерфейса по прежнему два и какой из них какой? прим. aco), в то время как пакет направленный для локального хоста не имеет передающего интерфейса (аналогичноая исутация! прим. aco)

Как все это понимать?

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

3. "ipfw: точный перевод"
Сообщение от СергейКа emailИскать по авторуВ закладки on 16-Янв-04, 08:54  (MSK)
localhost

Наверно подразумевается, что правила типа in recv lo0 (и подобные) не имеют смысла.

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

8. "ipfw: точный перевод"
Сообщение от Cheeto_McMourrell Искать по авторуВ закладки on 16-Янв-04, 20:59  (MSK)
>Пакет может не иметь принимающего или передающего интерфейса:
>пакет создаваемый локальным хостом не имеет принимающего интерфейса (позвольте но интерфейса по
>прежнему два и какой из них какой? прим. aco), в то
>время как пакет направленный для локального хоста не имеет передающего интерфейса
>(аналогичноая исутация! прим. aco)
>
>Как все это понимать?

Неужели это не понятно? Вы хотя бы понимаете, что у пакета вообще нет интерфейсов. Свойство иметь интерфейсы приписывается ему только в этом контексте, применительно к проверке в правилах firewall. Если пересказать это другими словами, то
Пакет, передача которого инициирована локальным хостом НИОТКУДА НЕ ПРИНИМАЕТСЯ. Пакет, посланный локальному хосту НИКУДА БОЛЬШЕ НЕ ПЕРЕДАЕТСЯ. Именно в этом смысле нужно трактовать данный текст.

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

2. "ipfw: точный перевод"
Сообщение от СергейКа emailИскать по авторуВ закладки on 16-Янв-04, 08:52  (MSK)
># Network Address Translation.  This rule is placed here deliberately
># so that it does not interfere with the surrounding address-checking
># rules.  If for example one of your internal LAN machines
>had its IP
># address set to 192.0.2.1 then an incoming packet for it after
>being
># translated by natd(8) would match the `deny' rule above.  Similarly
>
># an outgoing packet originated from it before being translated would
># match the `deny' rule below.
>        case ${natd_enable} in
>        [Yy][Ee][Ss])
>            
>    if [ -n "${natd_interface}" ]; then
>            
>          
> ${fwcmd} add divert natd all from any to any via
>${natd_interface}
>            
>    fi
>            
>    ;;
>        esac
>
Трансляция Сетевых адресов (NAT). Это правило помещено сюда преднамеренно так, чтобы это не конфликтовало с окружающими правилами контроля адресов (если пороще - в другое место нельзя, потому что будет конфликтовать). Если например одной из ваших внутренних машин локальной сети установили адрес IP на 192.0.2.1, тогда входящий пакет для 192.0.2.1, оттранслированный natd (8) будет соответствовать 'запрещающему' правилу указанному выше. (но ведь это и логично. Пока нат не поработал с приходящими для внутренней сети пакетами они имеют формат типа ip_ЧейТоВнешний->ip_nat , а после NAT если в сети есть адрес 192.0.2.1 может возникнуть ситуация ip_nat->192.0.2.1) Также исходящий пакет прежде, чем будет оттранслирован, будет соответствовать 'отрицающему' правилу указанному ниже.

Вообщем тут все предельно понятно.

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

5. "ipfw: точный перевод"
Сообщение от A Clockwork Orange Искать по авторуВ закладки on 16-Янв-04, 09:18  (MSK)
>># Network Address Translation.  This rule is placed here deliberately
>># so that it does not interfere with the surrounding address-checking
>># rules.  If for example one of your internal LAN machines
>>had its IP
>># address set to 192.0.2.1 then an incoming packet for it after
>>being
>># translated by natd(8) would match the `deny' rule above.  Similarly
>>
>># an outgoing packet originated from it before being translated would
>># match the `deny' rule below.
>>        case ${natd_enable} in
>>        [Yy][Ee][Ss])
>>            
>>    if [ -n "${natd_interface}" ]; then
>>            
>>          
>> ${fwcmd} add divert natd all from any to any via
>>${natd_interface}
>>            
>>    fi
>>            
>>    ;;
>>        esac
>>
>Трансляция Сетевых адресов (NAT). Это правило помещено сюда преднамеренно так, чтобы это не конфликтовало с окружающими правилами контроля адресов (если пороще - в другое место нельзя, потому что будет конфликтовать). Если например одной из ваших внутренних машин локальной сети установили адрес IP на 192.0.2.1, тогда входящий пакет для 192.0.2.1, оттранслированный natd (8) будет соответствовать 'запрещающему' правилу указанному выше. (но ведь это и логично. Пока нат не поработал с приходящими для внутренней сети пакетами они имеют формат типа ip_ЧейТоВнешний->ip_nat , а после NAT если в сети есть адрес 192.0.2.1 может возникнуть ситуация ip_nat->192.0.2.1) Также исходящий пакет прежде, чем будет оттранслирован, будет соответствовать 'отрицающему' правилу указанному ниже.
>
>Вообщем тут все предельно понятно.

Исходя из этого пакет входящий пакет для узла 192.168.0.2 дойдет до хоста, так?
Так запрещение стоит до нат, так?
Так же и пакет от этого хоста пройдет так как запрещение стоит после нат, а после нат адрес изменится, так?
Именно так стоит понимать абзац?

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

6. "ipfw: точный перевод"
Сообщение от СергейКа emailИскать по авторуВ закладки on 16-Янв-04, 10:05  (MSK)
>Исходя из этого пакет входящий пакет для узла 192.168.0.2 дойдет до хоста,
>так?
да
>Так запрещение стоит до нат, так?
так пакет ЕЩЕ не имеет адреса 192.168.0.2 (он спрятан в таблице нат)
>Так же и пакет от этого хоста пройдет так как запрещение стоит
>после нат, а после нат адрес изменится, так?
да. Адрес 192.168.0.2 УЖЕ спрятан в таблице НАТ
>Именно так стоит понимать абзац?
да

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

4. "ipfw: точный перевод"
Сообщение от dex emailИскать по авторуВ закладки on 16-Янв-04, 09:11  (MSK)
Все нормально по моему
>        ${fwcmd} add deny all
>from any to 0.0.0.0/8 via ${oif}
>        ${fwcmd} add deny all
>from any to 169.254.0.0/16 via ${oif}
>        ${fwcmd} add deny all
>from any to 192.0.2.0/24 via ${oif}
>        ${fwcmd} add deny all
>from any to 224.0.0.0/4 via ${oif}
>        ${fwcmd} add deny all
>from any to 240.0.0.0/4 via ${oif}

Блокируется пакетики которые идут с адресов any на адреса RESERVED-1,
DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E)

Таких адресов не должно быть в интернете

>
># Network Address Translation.  This rule is placed here deliberately
># so that it does not interfere with the surrounding address-checking
># rules.  If for example one of your internal LAN machines
>had its IP
># address set to 192.0.2.1 then an incoming packet for it after
>being
># translated by natd(8) would match the `deny' rule above.  Similarly
>
># an outgoing packet originated from it before being translated would
># match the `deny' rule below.
>        case ${natd_enable} in
>        [Yy][Ee][Ss])
>            
>    if [ -n "${natd_interface}" ]; then
>            
>          
> ${fwcmd} add divert natd all from any to any via
>${natd_interface}
>            
>    fi
>            
>    ;;
>        esac
Проброс для nat
>
>        # Stop RFC1918 nets
>on the outside interface
>        ${fwcmd} add deny all
>from 10.0.0.0/8 to any via ${oif}
>        ${fwcmd} add deny all
>from 172.16.0.0/12 to any via ${oif}
>        ${fwcmd} add deny all
>from 192.168.0.0/16 to any via ${oif}
>
>......

Блокирование пакетиков, которые не пробросил nat

Примерно все так

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

7. "ipfw: точный перевод"
Сообщение от СергейКа emailИскать по авторуВ закладки on 16-Янв-04, 10:08  (MSK)
>Все нормально по моему

так ведь это из стандартного rc.firewall
можно в дополнение к ман использовать :)

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


Удалить

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




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

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