メモめも
・
ドメイン指定は出来ない
多少オーバーヘッドかかってもドメインで制限出来ると便利なのだが。
・
ホスト名で指定する場合は名前解決の順番に気をつける
通常は IP アドレスでの指定を行うが、サービス提供サーバのアドレス変更が予想されたり、バーチャルホストや CNAME を多様して一つのサーバで複数のサービス(ホスト名)を使用している場合は、ホスト名指定の方が管理上便利な場合もある。
ipfw では対象アドレスとしてホスト名での記述が可能だが、当然その名前解決が出来る必要がある。
その為、DNS サーバへの問い合わせを許可するルールより前にホスト名指定でのルールが存在すると名前解決出来ずにエラーとなる。最低限、DNS サーバ指定はホスト名ではなく IP アドレス指定でなくてはならない。
ipfw のルールをスクリプトで設定している場合は、スクリプトの先頭で DNS サーバのアドレスを宣言しておいたり、または /etc/hosts に静的設定しておくと良いだろう。
なおホスト名指定の場合は、そのルールが適用される時に一度だけ名前解決が行われる。そのルールを評価する度に名前解決が行われる訳ではないので、注意する必要がある。
・
man ipfw での記述に誤りがある?
not 演算子を使う場合、man にはブレーズを使った使用例が掲載されているが、FreeBSD6.0 / ipfw2 では使えないようだ。
同じ挙動として、not の次にそのまま対象リストを羅列する。(tcpdump 等とは違う)
X → not { piyo.hoge.net, 192.168.0.0/25 }
○ → not piyo.hoge.net, 192.168.0.0/25
ブレーズを使えるのは or 演算子の場合のみ?ちょっとまだ混乱中。ちなみに and 演算子は存在しない。
・
MS さんから出る udp 1900 のバケット
Win XP 以降では UPnP がデフォルトで有効となっており、起動時及び一定間隔で該当パケットをブンブン吐く。
src XP ホスト udp 1900 → dst 239.255.255.255 udp 1900
MS さん曰く、
「よくあることですが 2、3 時間停電したため、マイクの家では時計が全部 12:00 で点滅しています。家中の時計を直して回るのは面倒で、時間もかかります。
UPnP を入れましょう。マイクの Windows XP ベースの PC で~略」
どこの国だ、そこわっ!!
MS さん曰く、
「メアリーはベッドにいて寝るところで、明日は土曜です。いつも目覚し時計は朝 7 時に~略。そこで彼女は目覚しを朝 7 時でなく 9 時に設定しました。
メアリーの目覚し時計は UPnP 対応なので快適です。~略」
そんな時計、使っちゃいねぇ!!
MS さん曰く、
「ママはパパと二人で過ごす時間なのに、息子のジミーのラップトップがまだ実行中なのに気付きます。
ママはラップトップの所に来てムード制御ボタンを押します。明かりが暗くなってソフト ミュージックが流れ、ラップトップはシャットダウンします。」
電源切るのにムード必要なんかっ!!
と言う訳で、 deny all from any 1900 to any 1900。
これで幸せ^^
・
net.inet.ip.fw.one_pass=0 としても評価順は変わらず
帯域制御する場合には net.inet.ip.fw.one_pass=0 として、ipfw コマンドによってパケットフィルタ処理を終了させずに pipe 処理を継続させる。
このような場合でも ipfw のルールは即時評価のまま変わらない。あくまでルールを舐めるようになるだけ。
重複するルールがあったとしても、先にマッチしたルールが適用され、上書きやルールの上乗せをする訳ではない。
keep-state(動的ルール)と絡んでいて、ちょっと混乱と勘違いがあるかもしれないが一例を。
1. add tcp from any to HOST-A ssh setup
2. add tcp from HOST-B to any setup keep-state
1. で HOST-A に対する ssh ポートへの TCP 最初の接続(SYN,ACK のうち SYN のみが立っている)を許可している。
2. で HOST-B から全てへの TCP パケットを動的ルールとして許可している。(ようは TCP なら何でも)
HOST-B から HOST-A への ssh 接続は表面上 1. と 2. で重複する。さらに 2. で全てに対し許可している訳であるから、しっかり動作すると思ったがそうではない。
HOST-B が発する最初の SYN パケットは 1. にマッチするが、それ以降のパケットについては 1. にはマッチせずに 2. にマッチしてしまう。
1. のルールに keep-state 指定してあれば SYN パケットが 1. にマッチした時点でそれ以降のパケットに対するルールが動的に作成され、1. に関連付けられたまま適用される。(2. には該当しなくなる)
故に、上記ルールセットでは HOST-B から HOST-A に対する ssh 以外の TCP 接続は行えるが、ssh 接続は出来ない。
TCP スリーハンドシェイク、HOST-B からの syn に対する HOST-A からの ack を許可するルールが無いので、通信出来ないっていえば当然なのね。
よって上記例を正常に通すなら、1. に keep-state を加えるか、2. の様な無条件許可するルールを先に記述する。
(net.inet.ip.fw.one_pass=0 指定すると後方マッチ(ルール上乗せ)になると思っていた。)
・
tcp のルールでも setup 指定するなら keep-state も指定する
上記一例で述べているが、setup 指定すると最初の syn パケットのみマッチする事になるので、単純に指定するなら keep-state と組み合わせる。
・
check-state と keep-state の関係
未だよく掴めず。。
・
パケットのマッチ落ち
基本全て不許可にした場合、最終ルールとして deny ip from any to any が必ず入るが、
落したパケットのログを見る為にその直前に deny log ip from any to any としても何故かこのルールをすり抜けて最終ルールに到達するパケットが存在する。
何故この様になるかは原因不明。
・
意図してないマッチ
man ipfw では、
「 にせの TCP パケットを含む怒涛の攻撃 (flood attack) からサイトを保護するために、次の動的ルールを用いた方が安全です。」
ipfw add check-state
ipfw add deny tcp from any to any established
ipfw add allow tcp from my-net to any setup keep-state
と例題が挙げられている。
3行目に当たる部分はネットワーク指定ではなく別個に keep-state 指定しているが、何故か2行目のルールで落されているパケットがあるようだ。
FW が直接ネットに繋がっているなら判るが、実際には FW の前にルータが存在し、FW はプライベート空間に浮かんでいる。
これも意味不明。何かしら原因あるのだろうけど。
・
me 指定
「システムのインタフェースに設定された任意の IP アドレスがマッチします。アドレスのリストはパケットが解析されるときに評価されます。」
とあるがこれが曲者。
自身から出る外向きのパケットについては(多分)何も問題無く大変便利な指定なのだが、インターフェースが複数ある場合の内向きのパケットで使う場合には注意が必要である。
評価される時の実際のアドレスは、外から入ってくるパケットと直接通信するインターフェースアドレスが評価される。
例として、FW に 192.168.0.254 と 192.168.1.254 と振られている二つのインターフェースがあり、192.168.0.1 というアドレスの HOST-A が存在する場合を挙げる。
1. add allow udp from HOST-A to me ntp keep-state
このルールにマッチした時に評価されるインターフェースアドレスは 192.168.0.254(fxp0) となる。
me を指定した場合、FW 上のインターフェース全てが該当するが、実際に評価されるのは一つのアドレス(直接通信するアドレス)だけになる。
インターフェース全てが評価される訳ではないので、HOST-A から 192.168.1.254(fxp1) は評価されない。
言い換えれば HOST-A から 192.168.1.254(fxp1) への通信は出来ないという事になる。
何が問題になるかというと、FW の別名(CNAME)として ntp という名前を振られていてそのアドレスは 192.168.1.254(fxp1) であり、その名前を使って ntp サービスを受ける場合等である。
前述の様に、me 指定の場合は HOST-A から到達する ntp パケットは 192.168.0.254(fxp0) で評価されてしまう。しかしそのパケットは本来 192.168.1.254(fxp1) 宛てのパケットであり、ここで意図しない動作となってしまう。
この様な問題に対処するには、me 指定を使わないか、または HOST-A の ntp サーバ指定を me で評価されるアドレスにする。
me の代わりに宛先として ntp とホスト名指定をするならばこの様な混乱も起こらない。
いずれにしろ、ルール適用ポリシーと照らし合わせ矛盾や混乱が起きないように考える必要がある。
・
ICMP
ping を通すだけなら
add icmp from my-net to any icmptype 0,8 keepstate
と内部からの指定だけで済むが、traceroute 等を使用するならば、経路到達パケットはその経路上のノードと個々にやり取りする為に明示的に外からのも指定する必要がある。
add pass icmp from any to my-net icmptypes 3 keep-state
add pass icmp from my-net to any icmptypes 3 keep-state
メモのメモ
・IEの自動Proxy設定とセキュリティ・ゾーン
―― 自動構成ファイルにおける“DIRECT”の意味を理解する ――
http://www.atmarkit.co.jp/fwin2k/experiments/ieproxy/ieproxy_01.html
これ、面白い。こんなの知らなかった。IE というか MS さん、またですかって感じではあるけど、
実際これで苦労した人多いんだろうな。
・WebブラウザのProxy設定を行うための4つの方法 - WPADのススメ -
http://www.atmarkit.co.jp/fwin2k/win2ktips/031autoproxy/autoproxy.html
クライアントの proxy 指定をどうするか、未だに悩んでるけどこれでもいいかなぁと。
通信の ACL と どう設置するかとかも問題あるけど。
・DNS, DHCPなど
http://muffin.cias.osakafu-u.ac.jp/~matumoto/unix/rfc.html
ここで DHCP 周りを判りやすく掘り下げて解説してる。今度読もう。
・PART2 Skype、その通信の仕組み (1/4)
http://www.itmedia.co.jp/enterprise/articles/0505/30/news070.html
親父が密かに入れてた Skype。意味不明のパケットはこれだった。
これも今度じっくり読む。ACL どうすっかな。
ハテシナクツヅク