web-dev-qa-db-ja.com

IceFloorを使用したOSX上のPFファイアウォール

サーバー3.0.2を実行しているOSX10.9システムでIceFloorを使用してpfをセットアップしました。 DNS名またはローカルホストからのパブリックIPを使用してシステムに接続できないことを除いて、すべて問題ないようです。例えば。インターネットからhttp/port 80に接続できますが、パブリックIPを使用してマシン自体からは接続できません。マシンからlocalhost/127.0.0.1への接続は機能します。取得したログは次のとおりです（x.x.x.xはホストのパブリックIPです）。

_rule 7/0(match): block in on en0: x.x.x.x.80 > x.x.x.x.64460: Flags [R.], seq 1, ack 1, win 65535, length 0
_

そしてここにルールのリストがあります

_$ Sudo pfctl -s rules
[Sudo] password for paul: 
No ALTQ support in kernel
ALTQ related functions disabled
scrub-anchor "icefloor.nat" all fragment reassemble
anchor "icefloor.nat" all
block drop in quick from <emergingthreats> to any
block drop out quick from any to <emergingthreats>
block drop in log quick from <_blacklist> to any
block drop out log quick from any to <_blacklist>
block drop in quick from no-route to any
block drop in quick from urpf-failed to any label "uRPF"
block drop log inet all label "Generic_blocks_(IPv4)"
block drop log inet6 all label "Generic_blocks_(IPv6)"
anchor "icefloor.groupblocks" all label "Blocks"
anchor "inspector.blocks" all label "Temp_blocks"
anchor "icefloor.exceptions" all label "Logs_exceptions"
anchor "icefloor.portknocking" all label "Hidden_services"
anchor "icefloor.genericipv6" all
anchor "icefloor.inbound" all label "Local_services"
anchor "icefloor.outbound" all label "All_traffic"
anchor "icefloor.outbound_nat" all label "NAT_clients_traffic"
anchor "icefloor.custom_rules" all
_

rule 7/0(match)がどれであるか教えていただけますか？また、ローカルホストから公開鍵（開いているポート）への接続が許可されないのはなぜですか？ _no-route_ fルールと関係がありますか？または2つの_Generic_blocks__-ルール？

前もって感謝します、

ポール

firewallmac-osxpf
4
lluuaapp

私もこの問題に直面していて、それをすべて理解するのに少しのテストとtcpdumpが必要でした。

最初の質問に答えるには、rule 7/0(match)は次のとおりです。これは、IceFloorによって自動的に追加される「Generic_blocks_（IPv4）」ルールであり、明示的に許可されていないすべてのトラフィックをブロックしてログに記録します。 rootとしてpfctl -gsrを実行すると、そのルールの番号を確認できます。

それがブロックされている理由について。インバウンド接続がブロックされます。これは、ルートなしやvisibleルールセットの内容とは何の関係もありません。それはあなたのDNS名がローカルでどのように扱われるかに関係しています。マシンのルーティングテーブル（netstat -r）には、lo0インターフェイスのlocalhostを指すDNS名のエントリがあります。

ログエントリには、いくつかの不可解な情報、特にblock in on en0が含まれています。これにより、インターフェイスen0で何かが起こっていると思われるようになります。ただし、tcpdump -nvvvi en0 tcp and port 80を実行すると、実際にはen0上をパケットが移動していないことがわかりました。ただし、パケットはtcpdump -nvvvi lo0 tcp and port 80で検出されたため、トラフィックが（予想どおり）lo0で発生していることが確認されました。

デフォルトのIceFloor構成（/Library/IceFloor/icefloor.conf）は、set skip on lo0を持つ行で生成されます。最初は、これは非常に標準的な歓迎された行のように見えます（ http://www.openbsd.org/faq/pf/options.html を参照）。 lo0の他のすべての部分は、pfルールによって妨げられていないように見えました。思い切って、その行をコメントアウトして、新しいルールを追加することにしました（テーブルに含まれる直後）：pass quick on lo0。この変更された構成でリロードした後、DNS名を介してWebサーバーに正常にアクセスできました（問題は解決しました）。したがって、set skip on lo0行にいくつかの問題があるようです。

icefloor.confファイルを手動で変更することの欠点は、IceFloorインターフェイスの[ファイアウォール]タブを使用できなくなることです。新しい構成を保存すると、手動編集が上書きされるためです。

1
KAbel