> Покажи ipfw show. Так проще понять будет твою проблему.
fw# ipfw show
00010 0 0 check-state
00020 891 233 allow ip from .163 to any keep-state via rl1
00030 0 0 allow ip from .166 to any keep-state via rl1
00090 8144 27094 deny log logamount 100 ip from any to any via rl0
00100 304 4744 allow ip from any to any via lo0
00200 0 0 deny ip from any to 127.0.0.0/8
00300 0 0 deny ip from 127.0.0.0/8 to any
65535 0 0 allow ip from any to any
166 - firewall, 163 - защищаем. rl1 - ловит траффик от 163.
Данный вариант полностью работоспособен. НО! Меня беспокоит то, что я добился этого, НЕ ПОНИМАЯ как он работает - а это согласитесь не очень хорошо. А именно: почему в данном случае мне приходится работать с rl1, если закрывал я rl0? Я вообще не вкупаюсь ПРИЧЕМ ЗДЕСЬ rl1??? Роботоспособности я добился экспирементальным путем и знаю, что если вот так не открывать rl1, при том что закрывал я rl0, работать он не будет.
И второе, все, что нужно от этого файрвола - это максимум защиты для 163, но чтобы этот 163 мог использовать любые инет-сервисы.
Имеется локалка. Я взял один хост из этой локалки, поставил на нем BSD'ю, настроил бриджинг и файрвол. "за него" поставил другой хост из это же локалки. Айпишник на этом файрволе я прицепил на его внутренний(rl0) сетевой интерфейс (тот, что ловит траффик от защищаемого).
Пока я не начал воять свои правила - все работает. Но вот я начал их писать, причем работаю исключительно с "внешним"(rl1) интерфейсом, и все идет кувырком. Сначала я пишу
add 100 deny ip from any to any via rl1 - все закрывается как нужно, а затем пишу
add 90 allow ip from <ip нужых мне хостов> to any via rl1 keep-state и
add 1 chek-state ставлю.
По моей логике хосты, которые я указал должны свободно ходить за файрвол, а они не ходят до тех пор, пока я не начинаю махинации с rl0(а именно приходится и для rl0 писать 90-е правило).
Объясните мне механизм этого бриджинга, если знаете ;)
> add 100 deny ip from any to any via rl1 - все закрывается > как нужно, а затем пишу > add 90 allow ip from <ip нужых мне хостов> to any via > rl1 keep-state и > add 1 chek-state ставлю. > По моей логике хосты, которые я указал должны свободно > ходить за файрвол, а они не ходят до тех пор, пока я не > начинаю махинации с rl0(а именно приходится и для rl0 > писать 90-е правило). > Объясните мне механизм этого бриджинга, если знаете ;)
Все правильно! Без дополнительного правила для внутреннего интерфейса никакие коннекты на внешний интерфейс не пройдут, ведь твои внутренние клиенты посылают запросы во внешний мир именно через внутренний интерфейс, и пока ты ему (внутреннему интерфейсу) не скажешь "Можешь на внутренний интерфейс принимать входящие коннекты от хостов из локалки и отправлять их на внешний интерфейс" он этого делать не будет.
> > add 100 deny ip from any to any via rl1 - все > закрывается > > как нужно, а затем пишу > > add 90 allow ip from <ip нужых мне хостов> to > any via > > rl1 keep-state и > > add 1 chek-state ставлю. > > По моей логике хосты, которые я указал должны свободно > > ходить за файрвол, а они не ходят до тех пор, пока я > не > > начинаю махинации с rl0(а именно приходится и для rl0 > > писать 90-е правило). > > Объясните мне механизм этого бриджинга, если знаете ;) > > Все правильно! Без дополнительного правила для внутреннего > интерфейса никакие коннекты на внешний интерфейс не > пройдут, ведь твои внутренние клиенты посылают запросы во > внешний мир именно через внутренний интерфейс, и пока ты > ему (внутреннему интерфейсу) не скажешь "Можешь на > внутренний интерфейс принимать входящие коннекты от хостов > из локалки и отправлять их на внешний интерфейс" он этого > делать не будет. Так он же это делал до того, как я написал 100-е правило. Причем я как раз не понимаю почему я должен открывать еще и внутренний, если я его вообще не трогал? Бриджует-то он без помощи правил...
Кстати, закрыв внешний интерфейс, те хосты, что за файрволом свободно видят этот файрвол(ip'шник, как я говорил, висит на внутреннем интерфейсе), т.е. внутренний вроде и не закрывается, но блин не пропускает на внешний, хотя правило разрешающее есть...
> > > add 100 deny ip from any to any via rl1 - все > > закрывается
В этом месте ты внешнему интерфейсу ЗАПРЕТИЛ принимать коннекты ОТ ВСЕХ ко ВСЕМ, в т.ч. и от внутреннего интерфейса.
[поскипано]
> Так он же это делал до того, как я написал 100-е правило. > Причем я как раз не понимаю почему я должен открывать еще и > внутренний, если я его вообще не трогал? Бриджует-то он без > помощи правил... > Кстати, закрыв внешний интерфейс, те хосты, что за > файрволом свободно видят этот файрвол(ip'шник, как я > говорил, висит на внутреннем интерфейсе), т.е. внутренний > вроде и не закрывается, но блин не пропускает на внешний, > хотя правило разрешающее есть...
см. выше
А тогда, что делает вот это...14.08.02 19:55 Автор: beLIEve Статус: Незарегистрированный пользователь
> > > > add 100 deny ip from any to any via rl1 - > все > > > закрывается > > В этом месте ты внешнему интерфейсу ЗАПРЕТИЛ принимать > коннекты ОТ ВСЕХ ко ВСЕМ, в т.ч. и от внутреннего > интерфейса. Этого я и хотел! А еще хотел, чтобы файрвол и защищаемый хост могли инициировать любые соединения в мир. Для этого я написал:
add 90 allow ip from "внут. инт. и защищаемый хост" to any via rl1 keep-state
По моему, это правило как раз и разрешит внешнему интерфейсу принимать пакеты от внутреннего интерфейса и защищаемого хоста. Если это не так, то скажите как нужно написать, чтобы он принимал пакеты от кого нужно.
Что не так в 90-м правиле?
Для справки: правило 65535 стоит на allow, так как этого требовал бриджинг. Есть также все правила, которые устанавливаются по дефаулту, я их не убирал.
P.S. Типа сорри если я что-то очевидное не догоняю ;)
FreeBSD+ipfw+bridge14.08.02 12:57 Автор: Night Knight [HZTeam.msk] <George Fedosejev> Статус: Member
> > > > add 100 deny ip from any to any via rl1 - > все > > > закрывается > > В этом месте ты внешнему интерфейсу ЗАПРЕТИЛ принимать > коннекты ОТ ВСЕХ ко ВСЕМ, в т.ч. и от внутреннего > интерфейса.
IMHO не в этом дело, он же и перед этим правилом что-то вставлял.
По умолчанию политика для IPFW - deny all from any to any, так что надо явно указать для каких интерфейсов что разрешено. Минимум может быть таким:
add 10000 allow ip from any to any via lo0
add 10100 check-state
add 10200 allow ip from ${INNERIP} to any in via rl0 keep-state
add 10300 allow ip from ${INNERIP} to any out via rl1
строка "add 65535 deny all from any to any" добавится автоматически, если только в ядре не выставлено "options IPFIREWALL_DEFAULT_TO_ACCEPT"
> > > add 100 deny ip from any to any via rl1 - все > > закрывается > > > как нужно, а затем пишу > > > add 90 allow ip from <ip нужых мне хостов> > to > > any via > > > rl1 keep-state и > > > add 1 chek-state ставлю. > > > По моей логике хосты, которые я указал должны > свободно > > > ходить за файрвол, а они не ходят до тех пор, > пока я > > не > > > начинаю махинации с rl0(а именно приходится и для > rl0 > > > писать 90-е правило). > > > Объясните мне механизм этого бриджинга, если > знаете ;) > > > > Все правильно! Без дополнительного правила для > внутреннего > > интерфейса никакие коннекты на внешний интерфейс не > > пройдут, ведь твои внутренние клиенты посылают запросы > во > > внешний мир именно через внутренний интерфейс, и пока > ты > > ему (внутреннему интерфейсу) не скажешь "Можешь на > > внутренний интерфейс принимать входящие коннекты от > хостов > > из локалки и отправлять их на внешний интерфейс" он > этого > > делать не будет. > Так он же это делал до того, как я написал 100-е правило. > Причем я как раз не понимаю почему я должен открывать еще и > внутренний, если я его вообще не трогал? Бриджует-то он без > помощи правил... > Кстати, закрыв внешний интерфейс, те хосты, что за > файрволом свободно видят этот файрвол(ip'шник, как я > говорил, висит на внутреннем интерфейсе), т.е. внутренний > вроде и не закрывается, но блин не пропускает на внешний, > хотя правило разрешающее есть...
Может я чего не понял уж извините, но по моему ты сначала все запретил, а патом пытаешся разрешить доступ
> Может я чего не понял уж извините, но по моему ты сначала > все запретил, а патом пытаешся разрешить доступ Ну да, у меня политика такая - запретить все, а потом разрешать только то, что нужно. Просто в данном случае "нужно" - это любые соединения, но только в одну сторону - в мир, но так, чтобы из мир не доставал ;)
FreeBSD+ipfw+bridge15.08.02 11:04 Автор: Night Knight [HZTeam.msk] <George Fedosejev> Статус: Member
> Просто в данном случае > "нужно" - это любые соединения, но только в одну сторону - > в мир, но так, чтобы из мир не доставал ;)
Чтобы мир не доставал надо сделать
add xxx allow tcp from any to ${INNERIP} established in via rl1
т.е. снаружи будут пропускаться соединения, установленные из внутренней сети и не будут пропускаться запросы на установление соединения. Кстати, политика по умолчанию на разрешение совершенно не обязательна. Покажи ipfw show. Так проще понять будет твою проблему.
не побоюсь повториться15.08.02 22:36 Автор: beLIEve Статус: Незарегистрированный пользователь
> Покажи ipfw show. Так проще понять будет твою проблему.
fw# ipfw show
00010 0 0 check-state
00020 891 233 allow ip from .163 to any keep-state via rl1
00030 0 0 allow ip from .166 to any keep-state via rl1
00090 8144 27094 deny log logamount 100 ip from any to any via rl0
00100 304 4744 allow ip from any to any via lo0
00200 0 0 deny ip from any to 127.0.0.0/8
00300 0 0 deny ip from 127.0.0.0/8 to any
65535 0 0 allow ip from any to any
166 - firewall, 163 - защищаем. rl1 - ловит траффик от 163.
Данный вариант полностью работоспособен. НО! Меня беспокоит то, что я добился этого, НЕ ПОНИМАЯ как он работает - а это согласитесь не очень хорошо. А именно: почему в данном случае мне приходится работать с rl1, если закрывал я rl0? Я вообще не вкупаюсь ПРИЧЕМ ЗДЕСЬ rl1??? Роботоспособности я добился экспирементальным путем и знаю, что если вот так не открывать rl1, при том что закрывал я rl0, работать он не будет.
И второе, все, что нужно от этого файрвола - это максимум защиты для 163, но чтобы этот 163 мог использовать любые инет-сервисы.
не побоюсь повториться16.08.02 17:07 Автор: Night Knight [HZTeam.msk] <George Fedosejev> Статус: Member
Вот черт, такой ответ написал и все куда-то в трубу улетело :( Ну тогда еще раз.
Значит так, какой именно интерфейс ты будешь файерволить - монопенисуально. Более того, IP'шник на бридже ты можешь повесить на любой интерфейс, это нужно только для того, что бы ты мог приконнектится к бриджу, скажем, по ssh для удаленного администрирования. Если я правильно понял твою кофигурацию, то она выглядит так:
(comp .163) --- rl0 .166 (bridge) rl1 --- outer
Тебе нужно запретить все коннекты к 163-му извне. Это проще сделать на внешнем интерфейсе бриджа. Попробуй так:
add 10 allow ip from any to any via lo0
add 20 check-state
add 30 allow all from .163 to any keep-state via rl1
add 40 allow all from me to any keep-state via rl1
add 50 allow tcp from ${YOURHOST} to me 22 in via rl1
add 60 deny log logamount 100 all from any to any in via rl1
остальное по вкусу
Итого:
10 - разрешаем любые коннекты через интерфейс обратной петли;
20 - проверяем динамические правила;
30 - разрешаем любые коннекты с 163-го хоста наружу (я специально пишу "allow all", а не "allow ip", чтобы проходили (R)ARP);
40 - разрешаем любые коннекты с бриджа через внешний интерфейс;
50 - входящее ssh на бридж с твоего хоста;
60 - запрещаем любые входящие коннекты извне через внешний интерфейс бриджа.
По идее, этого достаточно.
А по твоим правилам получается, что разрешены все коннекты, входящие через rl1, что к бриджу, что к 163-му хосту.
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
