>>[оверквотинг удален] Ваш подход "запретить все исход кроме исключений", конечно, похвальный. И понятно непонимание. ИМХО, большинство примеров - по построению пограничного маршрутизатора. И поскольку обычно строят его в гражданской конторе, смысла нет настолько жёстко контролировать исходящий трафик, не с гостайной работаем.
На самой системе, отправляющей данные, как-то можно ограничить потоки данных от разных программ, но если на маршрутизатор пришёл пакет с запросом на 80 порт - всё равно его нужно отправлять. И 53 нужно отправлять. И 443. Вот, собственно, даже этого хватит, чтобы вынести любую информацию с внутренней сети. (первые пол-года, когда домашний ПК подключили к выделенке на постоянку, под рукой всегда жил скрипт, удаляющий дефолтный маршрут. Перестраховка от вирусов такая - типа - замечу левую активность - отрублю. Теперь прошло.) Ну а кроме того, есть протоколы, которым нужны целые диапазоны (FTP, например, skype тот же), и заниматься мазохизмом, настраивая маршрутизатор для всего этого счасться, желающих среди админов-сетевиков очень мало.
Лисяра как источник информации - очень неоднозначен. Как начальная точка - неплохо, но в основе - всё равно нужно читать man-ы.
Поясню по NAT и фильтрам.
Мне кажется, вы в уме никак не делите трафик самого шлюза и его транзитный трафик. И ещё ICMP тут радует.
>icmp запросы по подозрительным пингам
ICMP - управляющий протокол, ping - только два из его кодов. Там нет "подозрительных" пингов. Есть echo request, echo reply, есть другие коды. В моём примере отфильтрованы коды, ведущие к проблемам с безопасностью.
Вы можете отфильтровать echo request и reply, но это снижает качество диагностики сетевых проблем. И кроме того, echo request никогда не придёт извне с получателем - внутренним адресом (тем, который за NAT-ом), только с адресом самого шлюза. Вот собственно поэтому его обычно в NAT и не передают - смысла нет. Вместо ната его либо разрешили, либо запретили.
С echo reply уже другая ситуация - он может придти на запрос из внутренней сети, его уже надо NAT-ить.
Ещё NAT-у приходится отслеживать входящий ICMP типа destanation unreacable, так как клиент вообще то просил соединение по другому протоколу, а ему прибежал оттуда облом в виде ICMP. А в таблице NAT-а нет потока на ICMP, есть на другой протокол. Вот в NAT-е и необходимо дополнительно обрабатывать все ICMP, кроме запроса входящего эха, чтобы своему клиенту их оттранслировать, иначе тормозааааа.
>Опять таки заруливание в нат всего входящего трафика отдельным правилом, правило deny_in в свойствах нат, которое отрубает все входящие пакеты не имеющие записей в динамических таблицах.
Не во всех случаях deny_in нужен. Просто он один из вариантов. Например, один мой маршрутизатор работал одним интерфейсом на белую, а на другим - на серую подсети. Вот там deny_in был совсем не нужен. Поэтому у меня в условном 3500 было
$fwcmd 3500 deny all from any to me // inet in to this gate
>в бсд в отличие от вин многое приходится искать самому по манам, народ не очень охотно делится.
Вот тут сложно. Маны предполагают размышления и более глубокое понимание предмета, GUI-интерфейс частенько этому не способствует. По прочтении манов у каждого рождается своё видение процесса, и, чего уж тут скрывать, частенько маны тоже пишутся в стиле "у нас есть молоток, гвозди, сварка и пассатижи. А вот так выглядит синхрофазотрон". Надо сказать, man ipfw тоже не идеален, но большинство моментов всё же описано отлично. Вот только чтобы понимать его, нужно ещё man ip, man icmp, man osi, man как-это-всё-связно-вместе :) Мы делимся, но самые простые вещи всё-же разжёвывать не любим.
С днём связи вас!
