forum.opennet.ru - "Настройка ipfw для NAT" (17)

форумы

помощь

поиск

регистрация

майллист

ВХОД

слежка

"Настройка ipfw для NAT"

Форумы Информационная безопасность (Public)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[Проследить за развитием треда]

"Настройка ipfw для NAT"
Сообщение от sva (ok) on 30-Июн-06, 21:15
Уж сколько статей было перечитано, но, опять же, нигде не описано одной детали... Если попытаться поднять NAT так (rl0 - локальный интерфейс в сеть 192.168.1.0/24, wi0 - внешний, смотрящий в сеть 10.0.0.0/24): # правила для NAT ${ipfw} add divert natd ip from 192.168.1.0/24 to any via wi0 ${ipfw} add divert natd ip from any to 10.0.0.66 ${ipfw} add allow ip from me to 10.0.0.0/24 via wi0 # разрешаем локальный траффик ${ipfw} add allow ip from 192.168.1.0/24 to any via rl0 ${ipfw} add allow ip from any to 192.168.1.0/24 то получаем дырку в безопасности в последнем правиле, так как из-за этого возможен спуффинг на внешнем интерфейсе. Если его изменить на: ${ipfw} add allow ip from any to 192.168.1.0/24 via rl0 то получаем непрохождение пакетов (здесь клиент 192.168.1.2 пытается пинговать хост 10.0.0.1): Deny ICMP:0.0 10.0.0.1 192.168.1.2 in via wi0 Как решить проблему? Что-то нужного правила не приходит в голову. Как настроить ipfw не только стандартными divert-правилами, которые уже любой нуб знает и про которые написано миллион статей, но и правилами, участвующими в дальнейшей судьбе пакета?
Правка \| Высказать мнение \| Ответить \| Cообщить модератору \| Наверх

Оглавление

Настройка ipfw для NAT, JavaScript, 01:32 , 01-Июл-06, (1)

Настройка ipfw для NAT, sva, 03:15 , 01-Июл-06, (2)

Настройка ipfw для NAT, JavaScript, 13:03 , 01-Июл-06, (3)

Настройка ipfw для NAT, sva, 14:21 , 02-Июл-06, (4)

Настройка ipfw для NAT, JavaScript, 16:52 , 02-Июл-06, (5)

Настройка ipfw для NAT, sva, 11:42 , 03-Июл-06, (6)

Настройка ipfw для NAT, JavaScript, 02:50 , 04-Июл-06, (7)

Настройка ipfw для NAT, sva, 09:31 , 04-Июл-06, (8)
Настройка ipfw для NAT, sva, 09:45 , 04-Июл-06, (9)

Настройка ipfw для NAT, JavaScript, 10:56 , 04-Июл-06, (10)

Настройка ipfw для NAT, sva, 11:38 , 06-Июл-06, (11)
Настройка ipfw для NAT, sva, 11:43 , 06-Июл-06, (12)

Настройка ipfw для NAT, JavaScript, 00:23 , 07-Июл-06, (13)

Настройка ipfw для NAT, sergei_vasilyev, 12:11 , 10-Июл-06, (14)

Настройка ipfw для NAT, sergei_vasilyev, 12:15 , 10-Июл-06, (15)

Настройка ipfw для NAT, AdVv, 23:29 , 13-Июл-06, (16)

И всё же а можно по подробнее.., mg, 20:39 , 16-Июл-06, (17)

Сообщения по теме [Сортировка по времени, UBB]

1. "Настройка ipfw для NAT"

Сообщение от JavaScript on 01-Июл-06, 01:32

${ipfw} add 1000 skipto 10000 ip from any to any in recv rl0
${ipfw} add 1100 skipto 20000 ip from any to any out xmit rl0
${ipfw} add 1200 skipto 30000 ip from any to any in recv wi0
${ipfw} add 1300 skipto 40000 ip from any to any out xmit wi0
${ipfw} add 2000 deny log ip from any to any
#internal-in
${ipfw} add 10000 count ip from any to any
#здесь можно ограничить лишний трафик из локалки
${ipfw} add 19000 allow ip from any to any
#internal-out
${ipfw} add 20000 count ip from any to any
#здесь можно ограничить лишний трафик в локалку
${ipfw} add 29000 allow ip from any to any
#external-in
${ipfw} add 30000 count ip from any to any
# тут запрещаем все лишнее на входе
${ipfw} add 38000 divert natd ip from any to any
${ipfw} add 39000 allow ip from any to any
#external-out
${ipfw} add 40000 count ip from any to any
# тут запрещаем все лишнее на выходе
${ipfw} add 48000 divert natd ip from any to any
${ipfw} add 49000 allow ip from any to any
${ipfw} add 65000 deny log ip from any to any

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

2. "Настройка ipfw для NAT"

Сообщение от sva (ok) on 01-Июл-06, 03:15

>${ipfw} add 1200 skipto 30000 ip from any to any in recv wi0
>${ipfw} add 1300 skipto 40000 ip from any to any out xmit wi0
[...]
>#external-in
>${ipfw} add 30000 count ip from any to any
># тут запрещаем все лишнее на входе
>${ipfw} add 38000 divert natd ip from any to any
>${ipfw} add 39000 allow ip from any to any
[...]
По-моему, ответ на мой вопрос так и не дан. Повторюсь, на _внешнем_ интерфейсе появляется _входящий_ пакет, идущий с внешнего ip (10.0.0.1) на внутренний (192.168.1.2). Где это у тебя разрешается? "allow ip from any to any" - не подходит, конечно. ;)

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

3. "Настройка ipfw для NAT"

Сообщение от JavaScript on 01-Июл-06, 13:03

>>${ipfw} add 1200 skipto 30000 ip from any to any in recv wi0
>>${ipfw} add 1300 skipto 40000 ip from any to any out xmit wi0
>[...]
>>#external-in
>>${ipfw} add 30000 count ip from any to any
>># тут запрещаем все лишнее на входе
>>${ipfw} add 38000 divert natd ip from any to any
>>${ipfw} add 39000 allow ip from any to any
>[...]
>
>По-моему, ответ на мой вопрос так и не дан. Повторюсь, на _внешнем_
>интерфейсе появляется _входящий_ пакет, идущий с внешнего ip (10.0.0.1) на внутренний
>(192.168.1.2). Где это у тебя разрешается? "allow ip from any to
>any" - не подходит, конечно. ;)
я привел просто шаблон, которым сам пользуюсь, а его можно модифицировать по конкертные условия.
попробуй подробней обьяснить, что требуется?
- разрешить прохождение прохождение пакетов между сетями 192.168.1.0/24 и 10.0.0.0/24 без ната? если так - то просто выпускаем такие пакеты перед divert:
  add 35000 allow ip from 10.0.0.0/24 to 192.168.1.0/24
  ...
  add 45000 allow ip from 192.168.1.0/24 to 10.0.0.0/24
- + стоит запретить пакеты, которые нам не нужны:
  add 36000 deny ip from any to not 10.0.0.66 # кажется такой адрес на внешнем итнерфейсе

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

4. "Настройка ipfw для NAT"

Сообщение от sva (ok) on 02-Июл-06, 14:21

>я привел просто шаблон, которым сам пользуюсь, а его можно модифицировать по
>конкертные условия.
>попробуй подробней обьяснить, что требуется?
Хорошо. Объясню ещё раз. При работе NATа на внешнем интерфейсе, после обратного преобразования адресов (когда пакет последний раз изменяется согласно NAT-технологии для отправки его клиенту), на внешний интерфейс попадает пакет вида источник:10.0.0.1, приёмник:192.168.1.2; поэтому, чтобы NAT-клиент таки получил пакет, нужно разрешить приём на внешнем интерфейсе шлюза пакетов с приёмником из нашей локальной сети 192.168.1.0/24, но это открывает возможность спуффинга, так как шлюз начнёт принимать пакеты на внешнем интерфейсе для адресов сети 192.168.1.0/24.
>- разрешить прохождение прохождение пакетов между сетями 192.168.1.0/24 и 10.0.0.0/24 без ната?
Нужно с натом. Иначе название темы я поставил бы другое.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

5. "Настройка ipfw для NAT"

Сообщение от JavaScript (ok) on 02-Июл-06, 16:52

>
>Хорошо. Объясню ещё раз. При работе NATа на внешнем интерфейсе, после обратного
>преобразования адресов (когда пакет последний раз изменяется согласно NAT-технологии для отправки
>его клиенту), на внешний интерфейс попадает пакет вида источник:10.0.0.1, приёмник:192.168.1.2; поэтому,
>чтобы NAT-клиент таки получил пакет, нужно разрешить приём на внешнем интерфейсе
>шлюза пакетов с приёмником из нашей локальной сети 192.168.1.0/24, но это
>открывает возможность спуффинга, так как шлюз начнёт принимать пакеты на внешнем
>интерфейсе для адресов сети 192.168.1.0/24.
>
все дело в том, что когда 192.168.1.2 пошлет пакет на адрес 10.0.0.1, то после NAT комп с адресом 10.0.0.1 получит пакет с src адресом 10.0.0.66 и соответственно обратный пакет будет слать по этому адресу.
значит на входе перед divert-ом мы должны видеть только пакеты с dst адресом 10.0.0.66
например:
...
#external-in
${ipfw} add 30000 count ip from any to any
# тут запрещаем все лишнее на входе
${ipfw} add 36000 deny ip from any to not 10.0.0.66 # <-- это правило закроет возможность спуффинга
# --- здесь, между 36000 и 38000 пакеты вида 10.0.0.1 -> 10.0.0.66
${ipfw} add 38000 divert natd ip from any to any # <-- NAT !!!
# --- здесь, между 38000 и 39000 пакеты вида 10.0.0.1 -> 192.168.1.2
${ipfw} add 39000 allow ip from any to any
...

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

6. "Настройка ipfw для NAT"

Сообщение от sva (ok) on 03-Июл-06, 11:42

>все дело в том, что когда 192.168.1.2 пошлет пакет на адрес 10.0.0.1,
>то после NAT комп с адресом 10.0.0.1 получит пакет с src
>адресом 10.0.0.66 и соответственно обратный пакет будет слать по этому адресу.
>значит на входе перед divert-ом мы должны видеть только пакеты с dst
>адресом 10.0.0.66
Всё верно. Так и есть. Я с этим не спорил. :)
Но логи я вручную не пишу, их пишет ПО... И в данном случае, в первом посте, я привёл строку из лога:
Deny ICMP:0.0 10.0.0.1 192.168.1.2 in via wi0
которая говорит о появлении на внешнем интерфейсе входящего пакета с приёмником из локальной сети. Приходиться открывать на фаерволле эту ситуацию, что открывает дыру в безопасности.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

7. "Настройка ipfw для NAT"

Сообщение от JavaScript (ok) on 04-Июл-06, 02:50

а у машины 10.0.0.1 прописан маршрут на сеть 192.168.1.0/24 ?
попробуй использовать мой шаблон - там все интуитивно понятно, как проходят пакеты
в твоем наборе правил ты правильно получаеш это сообщение - ведь после диверта пакет продолжает идти по правилах ... исходящий пакет выходит после диверта по правилу add allow ip from me to 10.0.0.0/24 via wi0
а входяший пакет после диверта, когда он уже принял форму 10.0.0.1 -> 192.168.1.2 тоже должен быть разрешен ... попробую наглядно на твоем наборе правил показать:
1 divert natd ip from 192.168.1.0/24 to any via wi0
2 divert natd ip from any to 10.0.0.66
3 allow ip from me to 10.0.0.0/24 via wi0
4 allow ip from 192.168.1.0/24 to any via rl0
5 allow ip from any to 192.168.1.0/24 via rl0
а) комп с адресом 192.168.1.2 шлет пакет по адресу 10.0.0.1
  - пакет вида 192.168.1.2 -> 10.0.0.1 попадает на вход rl0
    - 1-е правило не подходит изза via wi0
    - 2-е правило не подходит (dst не тот)
    - 3-е правило не подходит изза via wi0
    - 4-е правило подходит, пакет разрешен, поик по правилах закончен
  - все тот-же пакет вида 192.168.1.2 -> 10.0.0.1 попадает на выход wi0 (ведь пакет проходит дважды)
    - 1-е правило подходит, пакет идет на НАТ и меняется, теперь он 10.0.0.66 -> 10.0.0.1, продолжает идти по правилах
    - 2-е правило не подходит (dst не тот)
    - 3-е правило подходит , пакет разрешен, поик по правилах закончен
б) комп с адресом 10.0.0.1 шлет ответный пакет по адресу 192.168.1.2
  - пакет вида 10.0.0.1 -> 10.0.0.66 попадает на вход wi0
    - 1-е правило не подходит (src не тот)
    - 2-е правило подходит, пакет идет на НАТ и меняется, теперь он 10.0.0.1 -> 192.168.1.2 , продолжает идти по правилах
    - 3-е правило не подходит (dst не тот)
    - 4-е правило не подходит (не тот интерфейс)
    - 5-е правило (в варианте via rl0) не подходит (не тот интерфейс)
    - пакет запрещен, и мы видем в логе сообщение об этом

надеюсь понятно? на домашнее задание трасировка обратного пакета по правилах если в 5-том via rl0 нет :-)

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

8. "Настройка ipfw для NAT"

Сообщение от sva (ok) on 04-Июл-06, 09:31

-skip-

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

9. "Настройка ipfw для NAT"

Сообщение от sva (ok) on 04-Июл-06, 09:45

Мда... что тут ещё можно сказать? Изложенные тобой мысли в последнем сообщении крутились у меня в голове ещё с месяц назад... Поэтому, пожалуйста, перечитай первое сообщение и пойми, что проблемы того, что "нат не работает" или "не знаю, как оно работает" - НЕТУ. Есть только маленькая проблема в БЕЗОПАСНОСТИ, так как (уже в третий раз объясняю) при правиле "allow ip from any to 192.168.1.0/24" (без via rl0) получаем ДЫРКУ, которая заключается в возможности спуфинга на внешнем интерфейсе.
Тебе на домашнее задание - как можно на такой машине получить незапланированный доступ к машине из внешнего канала, к примеру, к web-серверу? Если web-сервер висит на локальном интерфейсе.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

10. "Настройка ipfw для NAT"

Сообщение от JavaScript (??) on 04-Июл-06, 10:56

Коллега! Позвольте поинтересоваться – какова цель нашего диалога?
Тоесть что бы ты хотел узнать?
Что если ты откроешь дыру в брандмауэре, то она там будет? – Абсолютно полностью с тобо согласен – она там будет!
Рабочее решение, чтобы не допустить такой "дыры" я предложил.
Все, аргументы у меня кончились…

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

11. "Настройка ipfw для NAT"

Сообщение от sva (ok) on 06-Июл-06, 11:38

>Коллега! Позвольте поинтересоваться – какова цель нашего диалога?
Решение поставленного вопроса. Через конструктивную полемику.
>Рабочее решение, чтобы не допустить такой "дыры" я предложил.
Рабочее ли? При последнем варианте правил, на машине перестаёт работать НАТ. В других вариантах защиты от дырки я не увидел.
В общем, странно, что в дискуссии участвует только JavaScript, потому как в любой стандартной схеме реализации НАТ-а, появляется эта дырка. Которую хоть и сложно нащупать, но она есть.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

12. "Настройка ipfw для NAT"

Сообщение от sva (ok) on 06-Июл-06, 11:43

Ну, что же... Спасибо моему единственному собеседнику в этом диалоге... Странно, что никто больше этой проблемой не заинтересовался. Видимо, мало кто замечает эту дырку, когда поднимает НАТ с помощью ipfw. :) Тем не менее, по-моему, решение найдено -
http://www.unixfaq.ru/index.pl?req=qs&id=286

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

13. "Настройка ipfw для NAT"

Сообщение от JavaScript (ok) on 07-Июл-06, 00:23

> Рабочее ли? При последнем варианте правил, на машине перестаёт работать НАТ. В других вариантах защиты от дырки я не увидел.
А рабочих вариантов море:
1. (мой шаблон, использую его на своих маршрутизаторах, модифицируя под конкретные условия)
${ipfw} add 1000 skipto 10000 ip from any to any in recv rl0
${ipfw} add 1100 skipto 20000 ip from any to any out xmit rl0
${ipfw} add 1200 skipto 30000 ip from any to any in recv wi0
${ipfw} add 1300 skipto 40000 ip from any to any out xmit wi0
${ipfw} add 2000 deny log ip from any to any
#internal-in
${ipfw} add 10000 count ip from any to any
${ipfw} add 19000 allow ip from any to any
#internal-out
${ipfw} add 20000 count ip from any to any
${ipfw} add 29000 allow ip from any to any
#external-in
${ipfw} add 30000 count ip from any to any
${ipfw} add 36000 deny ip from any to not 10.0.0.66
${ipfw} add 38000 divert natd ip from any to any
${ipfw} add 39000 allow ip from any to any
#external-out
${ipfw} add 40000 count ip from any to any
${ipfw} add 48000 divert natd ip from any to any
${ipfw} add 49000 allow ip from any to any
${ipfw} add 65000 deny log ip from any to any
2. (добавил второе правило в твой набор правил)
${ipfw} add divert natd ip from 192.168.1.0/24 to any via wi0
${ipfw} add deny ip from any to not 10.0.0.66 in recv wi0
${ipfw} add divert natd ip from any to 10.0.0.66
${ipfw} add allow ip from me to 10.0.0.0/24 via wi0
${ipfw} add allow ip from 192.168.1.0/24 to any via rl0
${ipfw} add allow ip from any to 192.168.1.0/24
итд - запрещать те пакеты из внешней сети, что тебя беспокоят надо ДО ДИВЕРТА иначе после их не отличить от нормальных - вот и все решение :-)

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

14. "Настройка ipfw для NAT"

Сообщение от sergei_vasilyev (??) on 10-Июл-06, 12:11

>маленькая проблема в БЕЗОПАСНОСТИ, так как (уже в третий раз объясняю)
>при правиле "allow ip from any to 192.168.1.0/24" (без via rl0)
>получаем ДЫРКУ, которая заключается в возможности спуфинга на внешнем интерфейсе.
>
>Тебе на домашнее задание - как можно на такой машине получить незапланированный
>доступ к машине из внешнего канала, к примеру, к web-серверу? Если
>web-сервер висит на локальном интерфейсе.
К веб серверу доступ - это цветочки. А получив доступ к внутреннему прокси-серверу через внешний интерфейс, кул-хацкер будет пользоваться И-нетом за ваши денежки... и/или через мейл-сервер спам рассылать.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

15. "Настройка ipfw для NAT"

Сообщение от sergei_vasilyev (??) on 10-Июл-06, 12:15

># разрешаем локальный траффик
>${ipfw} add allow ip from 192.168.1.0/24 to any via rl0
>${ipfw} add allow ip from any to 192.168.1.0/24
>
>то получаем дырку в безопасности в последнем правиле, так как из-за этого
>возможен спуффинг на внешнем интерфейсе.
Товарищ, посмотри _ВНИМАТЕЛЬНО_ правила в стандартном /etc/rc.firewall.
И\или юзай
add deny ip from any to any not verrevpath in
в начале файервола.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

16. "Настройка ipfw для NAT"

Сообщение от AdVv (??) on 13-Июл-06, 23:29

Может я чегото не понимаю, у меня сложилось мнение что применение техники спуфинга в IP стеках современных OS крайне затруднительно. Тем более через NAT.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

17. "И всё же а можно по подробнее.."

Сообщение от mg (??) on 16-Июл-06, 20:39

Каким образом правило
${ipfw} add allow ip from any to 192.168.1.0/24
добавляет "дырку" ?
Если я правильно понимаю спуфинг - это есть подмена адреса, так?
Вопрос на какой адрес должен поменть свой адрес кул-хацкер?
Если на 192.168.1.хх то как он сможет отправить что-то на внешний интерфейс?
Ведь для этого получается нужно искуственно генерить пакет с таким обратным адресом, при этом такой пакет будет выброшен на ближайшем же маршрутизаторе. Но даже если такой пакет будет каким-то образом собран и послан на WAN то куда пойдёт ответ на такой пакет? А ответ пойдёт во внутреннюю сеть, просто потому что гетвей указан для такого локального адреса с внутренним адресом. Затем так как сама машина является этим гетвеем то она направит этот пакет не на внешний интерфейс, а на внутренний в поисках машины с подделанным адресом... Таким образом можно бомбить локалку, засоряя её какими-то пакетами, но уж никак не использовать внутреннюю прокси.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Архив | Удалить

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

Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Настройка ipfw для NAT"
Сообщение от JavaScript on 01-Июл-06, 01:32
${ipfw} add 1000 skipto 10000 ip from any to any in recv rl0 ${ipfw} add 1100 skipto 20000 ip from any to any out xmit rl0 ${ipfw} add 1200 skipto 30000 ip from any to any in recv wi0 ${ipfw} add 1300 skipto 40000 ip from any to any out xmit wi0 ${ipfw} add 2000 deny log ip from any to any #internal-in ${ipfw} add 10000 count ip from any to any #здесь можно ограничить лишний трафик из локалки ${ipfw} add 19000 allow ip from any to any #internal-out ${ipfw} add 20000 count ip from any to any #здесь можно ограничить лишний трафик в локалку ${ipfw} add 29000 allow ip from any to any #external-in ${ipfw} add 30000 count ip from any to any # тут запрещаем все лишнее на входе ${ipfw} add 38000 divert natd ip from any to any ${ipfw} add 39000 allow ip from any to any #external-out ${ipfw} add 40000 count ip from any to any # тут запрещаем все лишнее на выходе ${ipfw} add 48000 divert natd ip from any to any ${ipfw} add 49000 allow ip from any to any ${ipfw} add 65000 deny log ip from any to any
Правка \| Высказать мнение \| Ответить \| Cообщить модератору \| Наверх


	2. "Настройка ipfw для NAT"
	Сообщение от sva (ok) on 01-Июл-06, 03:15
	>${ipfw} add 1200 skipto 30000 ip from any to any in recv wi0 >${ipfw} add 1300 skipto 40000 ip from any to any out xmit wi0 [...] >#external-in >${ipfw} add 30000 count ip from any to any ># тут запрещаем все лишнее на входе >${ipfw} add 38000 divert natd ip from any to any >${ipfw} add 39000 allow ip from any to any [...] По-моему, ответ на мой вопрос так и не дан. Повторюсь, на _внешнем_ интерфейсе появляется _входящий_ пакет, идущий с внешнего ip (10.0.0.1) на внутренний (192.168.1.2). Где это у тебя разрешается? "allow ip from any to any" - не подходит, конечно. ;)
	Правка \| Высказать мнение \| Ответить \| Cообщить модератору \| Наверх


	3. "Настройка ipfw для NAT"
	Сообщение от JavaScript on 01-Июл-06, 13:03
	>>${ipfw} add 1200 skipto 30000 ip from any to any in recv wi0 >>${ipfw} add 1300 skipto 40000 ip from any to any out xmit wi0 >[...] >>#external-in >>${ipfw} add 30000 count ip from any to any >># тут запрещаем все лишнее на входе >>${ipfw} add 38000 divert natd ip from any to any >>${ipfw} add 39000 allow ip from any to any >[...] > >По-моему, ответ на мой вопрос так и не дан. Повторюсь, на _внешнем_ >интерфейсе появляется _входящий_ пакет, идущий с внешнего ip (10.0.0.1) на внутренний >(192.168.1.2). Где это у тебя разрешается? "allow ip from any to >any" - не подходит, конечно. ;) я привел просто шаблон, которым сам пользуюсь, а его можно модифицировать по конкертные условия. попробуй подробней обьяснить, что требуется? - разрешить прохождение прохождение пакетов между сетями 192.168.1.0/24 и 10.0.0.0/24 без ната? если так - то просто выпускаем такие пакеты перед divert: add 35000 allow ip from 10.0.0.0/24 to 192.168.1.0/24 ... add 45000 allow ip from 192.168.1.0/24 to 10.0.0.0/24 - + стоит запретить пакеты, которые нам не нужны: add 36000 deny ip from any to not 10.0.0.66 # кажется такой адрес на внешнем итнерфейсе
	Правка \| Высказать мнение \| Ответить \| Cообщить модератору \| Наверх


	4. "Настройка ipfw для NAT"
	Сообщение от sva (ok) on 02-Июл-06, 14:21
	>я привел просто шаблон, которым сам пользуюсь, а его можно модифицировать по >конкертные условия. >попробуй подробней обьяснить, что требуется? Хорошо. Объясню ещё раз. При работе NATа на внешнем интерфейсе, после обратного преобразования адресов (когда пакет последний раз изменяется согласно NAT-технологии для отправки его клиенту), на внешний интерфейс попадает пакет вида источник:10.0.0.1, приёмник:192.168.1.2; поэтому, чтобы NAT-клиент таки получил пакет, нужно разрешить приём на внешнем интерфейсе шлюза пакетов с приёмником из нашей локальной сети 192.168.1.0/24, но это открывает возможность спуффинга, так как шлюз начнёт принимать пакеты на внешнем интерфейсе для адресов сети 192.168.1.0/24. >- разрешить прохождение прохождение пакетов между сетями 192.168.1.0/24 и 10.0.0.0/24 без ната? Нужно с натом. Иначе название темы я поставил бы другое.
	Правка \| Высказать мнение \| Ответить \| Cообщить модератору \| Наверх


	5. "Настройка ipfw для NAT"
	Сообщение от JavaScript (ok) on 02-Июл-06, 16:52
	> >Хорошо. Объясню ещё раз. При работе NATа на внешнем интерфейсе, после обратного >преобразования адресов (когда пакет последний раз изменяется согласно NAT-технологии для отправки >его клиенту), на внешний интерфейс попадает пакет вида источник:10.0.0.1, приёмник:192.168.1.2; поэтому, >чтобы NAT-клиент таки получил пакет, нужно разрешить приём на внешнем интерфейсе >шлюза пакетов с приёмником из нашей локальной сети 192.168.1.0/24, но это >открывает возможность спуффинга, так как шлюз начнёт принимать пакеты на внешнем >интерфейсе для адресов сети 192.168.1.0/24. > все дело в том, что когда 192.168.1.2 пошлет пакет на адрес 10.0.0.1, то после NAT комп с адресом 10.0.0.1 получит пакет с src адресом 10.0.0.66 и соответственно обратный пакет будет слать по этому адресу. значит на входе перед divert-ом мы должны видеть только пакеты с dst адресом 10.0.0.66 например: ... #external-in ${ipfw} add 30000 count ip from any to any # тут запрещаем все лишнее на входе ${ipfw} add 36000 deny ip from any to not 10.0.0.66 # <-- это правило закроет возможность спуффинга # --- здесь, между 36000 и 38000 пакеты вида 10.0.0.1 -> 10.0.0.66 ${ipfw} add 38000 divert natd ip from any to any # <-- NAT !!! # --- здесь, между 38000 и 39000 пакеты вида 10.0.0.1 -> 192.168.1.2 ${ipfw} add 39000 allow ip from any to any ...
	Правка \| Высказать мнение \| Ответить \| Cообщить модератору \| Наверх


	6. "Настройка ipfw для NAT"
	Сообщение от sva (ok) on 03-Июл-06, 11:42
	>все дело в том, что когда 192.168.1.2 пошлет пакет на адрес 10.0.0.1, >то после NAT комп с адресом 10.0.0.1 получит пакет с src >адресом 10.0.0.66 и соответственно обратный пакет будет слать по этому адресу. >значит на входе перед divert-ом мы должны видеть только пакеты с dst >адресом 10.0.0.66 Всё верно. Так и есть. Я с этим не спорил. :) Но логи я вручную не пишу, их пишет ПО... И в данном случае, в первом посте, я привёл строку из лога: Deny ICMP:0.0 10.0.0.1 192.168.1.2 in via wi0 которая говорит о появлении на внешнем интерфейсе входящего пакета с приёмником из локальной сети. Приходиться открывать на фаерволле эту ситуацию, что открывает дыру в безопасности.
	Правка \| Высказать мнение \| Ответить \| Cообщить модератору \| Наверх


	7. "Настройка ipfw для NAT"
	Сообщение от JavaScript (ok) on 04-Июл-06, 02:50
	а у машины 10.0.0.1 прописан маршрут на сеть 192.168.1.0/24 ? попробуй использовать мой шаблон - там все интуитивно понятно, как проходят пакеты в твоем наборе правил ты правильно получаеш это сообщение - ведь после диверта пакет продолжает идти по правилах ... исходящий пакет выходит после диверта по правилу add allow ip from me to 10.0.0.0/24 via wi0 а входяший пакет после диверта, когда он уже принял форму 10.0.0.1 -> 192.168.1.2 тоже должен быть разрешен ... попробую наглядно на твоем наборе правил показать: 1 divert natd ip from 192.168.1.0/24 to any via wi0 2 divert natd ip from any to 10.0.0.66 3 allow ip from me to 10.0.0.0/24 via wi0 4 allow ip from 192.168.1.0/24 to any via rl0 5 allow ip from any to 192.168.1.0/24 via rl0 а) комп с адресом 192.168.1.2 шлет пакет по адресу 10.0.0.1 - пакет вида 192.168.1.2 -> 10.0.0.1 попадает на вход rl0 - 1-е правило не подходит изза via wi0 - 2-е правило не подходит (dst не тот) - 3-е правило не подходит изза via wi0 - 4-е правило подходит, пакет разрешен, поик по правилах закончен - все тот-же пакет вида 192.168.1.2 -> 10.0.0.1 попадает на выход wi0 (ведь пакет проходит дважды) - 1-е правило подходит, пакет идет на НАТ и меняется, теперь он 10.0.0.66 -> 10.0.0.1, продолжает идти по правилах - 2-е правило не подходит (dst не тот) - 3-е правило подходит , пакет разрешен, поик по правилах закончен б) комп с адресом 10.0.0.1 шлет ответный пакет по адресу 192.168.1.2 - пакет вида 10.0.0.1 -> 10.0.0.66 попадает на вход wi0 - 1-е правило не подходит (src не тот) - 2-е правило подходит, пакет идет на НАТ и меняется, теперь он 10.0.0.1 -> 192.168.1.2 , продолжает идти по правилах - 3-е правило не подходит (dst не тот) - 4-е правило не подходит (не тот интерфейс) - 5-е правило (в варианте via rl0) не подходит (не тот интерфейс) - пакет запрещен, и мы видем в логе сообщение об этом надеюсь понятно? на домашнее задание трасировка обратного пакета по правилах если в 5-том via rl0 нет :-)
	Правка \| Высказать мнение \| Ответить \| Cообщить модератору \| Наверх


	8. "Настройка ipfw для NAT"
	Сообщение от sva (ok) on 04-Июл-06, 09:31
	-skip-
	Правка \| Высказать мнение \| Ответить \| Cообщить модератору \| Наверх


	9. "Настройка ipfw для NAT"
	Сообщение от sva (ok) on 04-Июл-06, 09:45
	Мда... что тут ещё можно сказать? Изложенные тобой мысли в последнем сообщении крутились у меня в голове ещё с месяц назад... Поэтому, пожалуйста, перечитай первое сообщение и пойми, что проблемы того, что "нат не работает" или "не знаю, как оно работает" - НЕТУ. Есть только маленькая проблема в БЕЗОПАСНОСТИ, так как (уже в третий раз объясняю) при правиле "allow ip from any to 192.168.1.0/24" (без via rl0) получаем ДЫРКУ, которая заключается в возможности спуфинга на внешнем интерфейсе. Тебе на домашнее задание - как можно на такой машине получить незапланированный доступ к машине из внешнего канала, к примеру, к web-серверу? Если web-сервер висит на локальном интерфейсе.
	Правка \| Высказать мнение \| Ответить \| Cообщить модератору \| Наверх


	10. "Настройка ipfw для NAT"
	Сообщение от JavaScript (??) on 04-Июл-06, 10:56
	Коллега! Позвольте поинтересоваться – какова цель нашего диалога? Тоесть что бы ты хотел узнать? Что если ты откроешь дыру в брандмауэре, то она там будет? – Абсолютно полностью с тобо согласен – она там будет! Рабочее решение, чтобы не допустить такой "дыры" я предложил. Все, аргументы у меня кончились…
	Правка \| Высказать мнение \| Ответить \| Cообщить модератору \| Наверх


	11. "Настройка ipfw для NAT"
	Сообщение от sva (ok) on 06-Июл-06, 11:38
	>Коллега! Позвольте поинтересоваться – какова цель нашего диалога? Решение поставленного вопроса. Через конструктивную полемику. >Рабочее решение, чтобы не допустить такой "дыры" я предложил. Рабочее ли? При последнем варианте правил, на машине перестаёт работать НАТ. В других вариантах защиты от дырки я не увидел. В общем, странно, что в дискуссии участвует только JavaScript, потому как в любой стандартной схеме реализации НАТ-а, появляется эта дырка. Которую хоть и сложно нащупать, но она есть.
	Правка \| Высказать мнение \| Ответить \| Cообщить модератору \| Наверх


	12. "Настройка ipfw для NAT"
	Сообщение от sva (ok) on 06-Июл-06, 11:43
	Ну, что же... Спасибо моему единственному собеседнику в этом диалоге... Странно, что никто больше этой проблемой не заинтересовался. Видимо, мало кто замечает эту дырку, когда поднимает НАТ с помощью ipfw. :) Тем не менее, по-моему, решение найдено - http://www.unixfaq.ru/index.pl?req=qs&id=286
	Правка \| Высказать мнение \| Ответить \| Cообщить модератору \| Наверх


	13. "Настройка ipfw для NAT"
	Сообщение от JavaScript (ok) on 07-Июл-06, 00:23
	> Рабочее ли? При последнем варианте правил, на машине перестаёт работать НАТ. В других вариантах защиты от дырки я не увидел. А рабочих вариантов море: 1. (мой шаблон, использую его на своих маршрутизаторах, модифицируя под конкретные условия) ${ipfw} add 1000 skipto 10000 ip from any to any in recv rl0 ${ipfw} add 1100 skipto 20000 ip from any to any out xmit rl0 ${ipfw} add 1200 skipto 30000 ip from any to any in recv wi0 ${ipfw} add 1300 skipto 40000 ip from any to any out xmit wi0 ${ipfw} add 2000 deny log ip from any to any #internal-in ${ipfw} add 10000 count ip from any to any ${ipfw} add 19000 allow ip from any to any #internal-out ${ipfw} add 20000 count ip from any to any ${ipfw} add 29000 allow ip from any to any #external-in ${ipfw} add 30000 count ip from any to any ${ipfw} add 36000 deny ip from any to not 10.0.0.66 ${ipfw} add 38000 divert natd ip from any to any ${ipfw} add 39000 allow ip from any to any #external-out ${ipfw} add 40000 count ip from any to any ${ipfw} add 48000 divert natd ip from any to any ${ipfw} add 49000 allow ip from any to any ${ipfw} add 65000 deny log ip from any to any 2. (добавил второе правило в твой набор правил) ${ipfw} add divert natd ip from 192.168.1.0/24 to any via wi0 ${ipfw} add deny ip from any to not 10.0.0.66 in recv wi0 ${ipfw} add divert natd ip from any to 10.0.0.66 ${ipfw} add allow ip from me to 10.0.0.0/24 via wi0 ${ipfw} add allow ip from 192.168.1.0/24 to any via rl0 ${ipfw} add allow ip from any to 192.168.1.0/24 итд - запрещать те пакеты из внешней сети, что тебя беспокоят надо ДО ДИВЕРТА иначе после их не отличить от нормальных - вот и все решение :-)
	Правка \| Высказать мнение \| Ответить \| Cообщить модератору \| Наверх


	14. "Настройка ipfw для NAT"
	Сообщение от sergei_vasilyev (??) on 10-Июл-06, 12:11
	>маленькая проблема в БЕЗОПАСНОСТИ, так как (уже в третий раз объясняю) >при правиле "allow ip from any to 192.168.1.0/24" (без via rl0) >получаем ДЫРКУ, которая заключается в возможности спуфинга на внешнем интерфейсе. > >Тебе на домашнее задание - как можно на такой машине получить незапланированный >доступ к машине из внешнего канала, к примеру, к web-серверу? Если >web-сервер висит на локальном интерфейсе. К веб серверу доступ - это цветочки. А получив доступ к внутреннему прокси-серверу через внешний интерфейс, кул-хацкер будет пользоваться И-нетом за ваши денежки... и/или через мейл-сервер спам рассылать.
	Правка \| Высказать мнение \| Ответить \| Cообщить модератору \| Наверх

15. "Настройка ipfw для NAT"
Сообщение от sergei_vasilyev (??) on 10-Июл-06, 12:15
># разрешаем локальный траффик >${ipfw} add allow ip from 192.168.1.0/24 to any via rl0 >${ipfw} add allow ip from any to 192.168.1.0/24 > >то получаем дырку в безопасности в последнем правиле, так как из-за этого >возможен спуффинг на внешнем интерфейсе. Товарищ, посмотри _ВНИМАТЕЛЬНО_ правила в стандартном /etc/rc.firewall. И\или юзай add deny ip from any to any not verrevpath in в начале файервола.
Правка \| Высказать мнение \| Ответить \| Cообщить модератору \| Наверх


	16. "Настройка ipfw для NAT"
	Сообщение от AdVv (??) on 13-Июл-06, 23:29
	Может я чегото не понимаю, у меня сложилось мнение что применение техники спуфинга в IP стеках современных OS крайне затруднительно. Тем более через NAT.
	Правка \| Высказать мнение \| Ответить \| Cообщить модератору \| Наверх

17. "И всё же а можно по подробнее.."
Сообщение от mg (??) on 16-Июл-06, 20:39
Каким образом правило ${ipfw} add allow ip from any to 192.168.1.0/24 добавляет "дырку" ? Если я правильно понимаю спуфинг - это есть подмена адреса, так? Вопрос на какой адрес должен поменть свой адрес кул-хацкер? Если на 192.168.1.хх то как он сможет отправить что-то на внешний интерфейс? Ведь для этого получается нужно искуственно генерить пакет с таким обратным адресом, при этом такой пакет будет выброшен на ближайшем же маршрутизаторе. Но даже если такой пакет будет каким-то образом собран и послан на WAN то куда пойдёт ответ на такой пакет? А ответ пойдёт во внутреннюю сеть, просто потому что гетвей указан для такого локального адреса с внутренним адресом. Затем так как сама машина является этим гетвеем то она направит этот пакет не на внешний интерфейс, а на внутренний в поисках машины с подделанным адресом... Таким образом можно бомбить локалку, засоряя её какими-то пакетами, но уж никак не использовать внутреннюю прокси.
Правка \| Высказать мнение \| Ответить \| Cообщить модератору \| Наверх

Архив \| Удалить	Индекс форумов \| Темы \| Пред. тема \| След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 \| 2 \| 3 \| 4 \| 5 ] [Рекомендовать для помещения в FAQ]