Уж сколько статей было перечитано, но, опять же, нигде не описано одной детали... Если попытаться поднять 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-правилами, которые уже любой нуб знает и про которые написано миллион статей, но и правилами, участвующими в дальнейшей судьбе пакета?
${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
>${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" - не подходит, конечно. ;)
>>${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 # кажется такой адрес на внешнем итнерфейсе
>я привел просто шаблон, которым сам пользуюсь, а его можно модифицировать по
>конкертные условия.
>попробуй подробней обьяснить, что требуется?Хорошо. Объясню ещё раз. При работе 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 без ната?
Нужно с натом. Иначе название темы я поставил бы другое.
>
>Хорошо. Объясню ещё раз. При работе 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
...
>все дело в том, что когда 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
которая говорит о появлении на внешнем интерфейсе входящего пакета с приёмником из локальной сети. Приходиться открывать на фаерволле эту ситуацию, что открывает дыру в безопасности.
а у машины 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 wi04 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 нет :-)
-skip-
Мда... что тут ещё можно сказать? Изложенные тобой мысли в последнем сообщении крутились у меня в голове ещё с месяц назад... Поэтому, пожалуйста, перечитай первое сообщение и пойми, что проблемы того, что "нат не работает" или "не знаю, как оно работает" - НЕТУ. Есть только маленькая проблема в БЕЗОПАСНОСТИ, так как (уже в третий раз объясняю) при правиле "allow ip from any to 192.168.1.0/24" (без via rl0) получаем ДЫРКУ, которая заключается в возможности спуфинга на внешнем интерфейсе.Тебе на домашнее задание - как можно на такой машине получить незапланированный доступ к машине из внешнего канала, к примеру, к web-серверу? Если web-сервер висит на локальном интерфейсе.
Коллега! Позвольте поинтересоваться – какова цель нашего диалога?
Тоесть что бы ты хотел узнать?
Что если ты откроешь дыру в брандмауэре, то она там будет? – Абсолютно полностью с тобо согласен – она там будет!
Рабочее решение, чтобы не допустить такой "дыры" я предложил.Все, аргументы у меня кончились…
>Коллега! Позвольте поинтересоваться – какова цель нашего диалога?Решение поставленного вопроса. Через конструктивную полемику.
>Рабочее решение, чтобы не допустить такой "дыры" я предложил.
Рабочее ли? При последнем варианте правил, на машине перестаёт работать НАТ. В других вариантах защиты от дырки я не увидел.
В общем, странно, что в дискуссии участвует только JavaScript, потому как в любой стандартной схеме реализации НАТ-а, появляется эта дырка. Которую хоть и сложно нащупать, но она есть.
Ну, что же... Спасибо моему единственному собеседнику в этом диалоге... Странно, что никто больше этой проблемой не заинтересовался. Видимо, мало кто замечает эту дырку, когда поднимает НАТ с помощью ipfw. :) Тем не менее, по-моему, решение найдено -
http://www.unixfaq.ru/index.pl?req=qs&id=286
> Рабочее ли? При последнем варианте правил, на машине перестаёт работать НАТ. В других вариантах защиты от дырки я не увидел.А рабочих вариантов море:
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итд - запрещать те пакеты из внешней сети, что тебя беспокоят надо ДО ДИВЕРТА иначе после их не отличить от нормальных - вот и все решение :-)
>маленькая проблема в БЕЗОПАСНОСТИ, так как (уже в третий раз объясняю)
>при правиле "allow ip from any to 192.168.1.0/24" (без via rl0)
>получаем ДЫРКУ, которая заключается в возможности спуфинга на внешнем интерфейсе.
>
>Тебе на домашнее задание - как можно на такой машине получить незапланированный
>доступ к машине из внешнего канала, к примеру, к web-серверу? Если
>web-сервер висит на локальном интерфейсе.К веб серверу доступ - это цветочки. А получив доступ к внутреннему прокси-серверу через внешний интерфейс, кул-хацкер будет пользоваться И-нетом за ваши денежки... и/или через мейл-сервер спам рассылать.
># разрешаем локальный траффик
>${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
в начале файервола.
Может я чегото не понимаю, у меня сложилось мнение что применение техники спуфинга в IP стеках современных OS крайне затруднительно. Тем более через NAT.
Каким образом правило
${ipfw} add allow ip from any to 192.168.1.0/24
добавляет "дырку" ?
Если я правильно понимаю спуфинг - это есть подмена адреса, так?
Вопрос на какой адрес должен поменть свой адрес кул-хацкер?
Если на 192.168.1.хх то как он сможет отправить что-то на внешний интерфейс?
Ведь для этого получается нужно искуственно генерить пакет с таким обратным адресом, при этом такой пакет будет выброшен на ближайшем же маршрутизаторе. Но даже если такой пакет будет каким-то образом собран и послан на WAN то куда пойдёт ответ на такой пакет? А ответ пойдёт во внутреннюю сеть, просто потому что гетвей указан для такого локального адреса с внутренним адресом. Затем так как сама машина является этим гетвеем то она направит этот пакет не на внешний интерфейс, а на внутренний в поисках машины с подделанным адресом... Таким образом можно бомбить локалку, засоряя её какими-то пакетами, но уж никак не использовать внутреннюю прокси.