iptables による ポートのリダイレクト

あるポートから違うポートへリダイレクトさせたい時があります。

例えば、下記ページの例のように「8080 ポートで待ち受けをしている Tomcat に対して、http://anyhost.com:8080 ではなく http://anyhost.com でアクセスさせたい」などです。

Firewalls-local-port-redirection

色々な方法がありますが、その１つとして iptables の REDIRECT ターゲット を使用する方法があります。この場合、リダイレクトする対象として、以下のパターンが考えられます。

1. 外から入ってきたパケットをリダイレクトする
2. ローカルで生成したパケットをリダイレクトする

サーバーに設定するのであれば、1 のパターンがメインになりますね。2 のパターンはテストをする時などでしょうか。

1 のパターンの場合の設定は以下になります。
（-dst の値は環境にあわせて変更）

# iptables -t nat -I PREROUTING --src 0/0 --dst 127.0.0.1 \
-p tcp --dport 80 -j REDIRECT --to-ports 8080

設定の意味が理解しやすいルールですね。ただ、２のパターンのルールを見たとき、ピンときませんでした。

# iptables -t nat -I OUTPUT --src 0/0 --dst 127.0.0.1 \
-p tcp --dport 80 -j REDIRECT --to-ports 8080

理由は、OUTPUT チェインが外に出て行く時に適用されると勘違いしていたから。あらためて man の TABLES の部分を見てみると「ローカルで生成したパケットをルーティング前に変更する」とハッキリ書いてますね！

nat: This table is consulted when a packet that creates a 
new connection is encountered. 〜 OUTPUT (for altering 
locally-generated packets before routing)

下記のページの図も参考になります。
NAT（Network Address Translation） の概要

設定を削除する場合は以下。(テーブルを指定しない場合のデフォルトは "filter" なので、"nat" テーブルを削除する場合には、明示的に指定する必要がある)

# iptables -t nat -F

また、個別にルールを削除したい場合は、以下のようにします。

# iptables -t nat -n -L --line-numbers
-------------------------------------------------
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination      
1    REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1 ...

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination      


Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination      
1    REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1 ...
-------------------------------------------------

削除したいルールのチェインと行番号を指定する
# iptables -t nat -D PREROUTING 1

Apache 2.2.21 リリース

Apacheの脆弱性（CVE-2011-3192）に対応した 2.2.20 からまもなく 2.2.21 がリリースされています。 2.2.20 で行った修正に対する改善や、新たにMaxRangesディレクティブの追加などが含まれている模様。 

そもそも問題となっている Range ヘッダは、ブラウザでPDFの閲覧をしている時などにも使用されています。

GET /net/apache//httpd/docs/httpd-docs-2.2.14.en.pdf HTTP/1.1
Accept: */*
Range: bytes=3653554-3854257, 1077245-3603942, 3608039-3653553
...

このヘッダを使用して、なぜプロセスの肥大化が引き起こされるのかについては下記のページで丁寧に説明されていて、Range で細かい区間を要求されることにより、管理データを追加していくループ処理の増加が原因とのこと。

  CVE-2011-3192 Range header DoS vulnerability Apache 1.3/2.x の更に続き

追加された MaxRanges ディレクティブ では、制限値（デフォルト: 200）を超えた場合、要求されたコンテンツをそのまま返すようになっています。区間要求が無視されることにより、プロセスの肥大化を防ぐ仕組みですね。

# vi httpd.conf
----------------------
# MaxRanges: Maximum number of Ranges in a request before
# returning the entire resource, or 0 for unlimited
# Default setting is to accept 200 Ranges
MaxRanges 5
----------------------

// 制限内の数を指定した場合
GET / HTTP/1.1
Host: localhost
Range: bytes=0-1,1-2,2-3,3-4,4-5 <= 一度に複数の範囲を指定

HTTP/1.1 206 Partial Content <= 206 レスポンスが返る
...
Accept-Ranges: bytes
Content-Length: 412
Content-Type: multipart/byteranges; boundary=4ad1ca44eeaa22

// 制限を超過した場合
GET / HTTP/1.1
Host: localhost
Range: bytes=0-1,1-2,2-3,3-4,4-5,5-6

HTTP/1.1 200 OK <= 要求されたコンテンツをそのまま返している
...
Accept-Ranges: bytes
Content-Length: 44
Content-Type: text/html

curl がすごく便利

名前は聞いた事があるけれど、使った事がなかったコマンド。
（いまさらだけど）Webアプリケーションの脆弱性チェックなどで、すごく便利だと実感。

チェックしたいWebアプリケーションにPOSTリクエストを色々変えながら、レスポンスを確認したいときに Paros のようなProxyを使うけれど、curl だとコマンドラインで操作できるので、ターミナル上でも手軽に実行できるし、同じことを繰り返す場合も便利。

ログイン画面などで、テストする場合はこんな感じ。

$ curl http://foo.co.jp/login -c cookie.txt

セッションIDがCookieに保存される場合は、一度ログインページを表示してCookieの内容をファイルに保存。

$ curl -v http://foo.co.jp/login \
    -d username=guest -d password=guest \
    -b cookie.txt -L

そして、POSTを送ってログインを試みる。フォームの送信は -d オプションで指定。また、先ほど取得したCookieを -b オプションで一緒に送信。POSTが成功した場合、リダイレクトで別のページに遷移することが多いので、-L を指定しておくとブラウザの動作に近くなります。HTTPのリクエスト／レスポンスが見たい場合は -v も指定。

あとは、SSLのページでも Ubuntu などでパッケージから curl をインストールすると主要な証明書も一緒にインストールされているから問題なし。
これから、どんどん使っていこう。

Net-SNMP viewの設定

snmpd.conf の view 設定として、下記が "全て公開" になるというサンプルがありますが、なぜそうなるのか分からなかった（特にMASK部分）ので、調べてみました。

##           incl/excl  subtree                     mask
view all    included   .1                             80

まずは 'man snmpd.conf'。mask の指定は16進数ということは分かったけれど、まだハッキリしない。

view VNAME TYPE OID [MASK]
...
  MASK is a list of hex octets (optionally separated by '.' or ':') 
  with the set bits indicating which   subidentifiers in the view 
  OID to match against.

ここのメーリングリストの説明を見て、やっと分かった！

つまり、ビットが立っている部分は固定（指定したOIDそのまま）で、立っていない部分はワイルドカードの扱いになると。実際に確認してみよう。

たとえば、このようなインターフェース構成のサーバで、"全て公開"の設定にしていると、全てのインターフェースの情報が見える（当然ですね！）

# snmpwalk -v 2c -c private localhost .1.3.6.1.2.1.2.2.1.2
IF-MIB::ifDescr.1 = STRING: lo
IF-MIB::ifDescr.2 = STRING: eth0
IF-MIB::ifDescr.3 = STRING: eth1
IF-MIB::ifDescr.4 = STRING: eth2

（「受信した総バイト数」を表示）
# snmpwalk -v 2c -c private localhost .1.3.6.1.2.1.2.2.1.10
IF-MIB::ifInOctets.1 = Counter32: 1270274
IF-MIB::ifInOctets.2 = Counter32: 165686032
IF-MIB::ifInOctets.3 = Counter32: 9656051
IF-MIB::ifInOctets.4 = Counter32: 635738

（「送信した総バイト数」を表示）
# snmpwalk -v 2c -c private localhost .1.3.6.1.2.1.2.2.1.16
IF-MIB::ifOutOctets.1 = Counter32: 1270274
IF-MIB::ifOutOctets.2 = Counter32: 19914854
IF-MIB::ifOutOctets.3 = Counter32: 805032
IF-MIB::ifOutOctets.4 = Counter32: 8933886

ここで、このように設定を変更すると、

view ifRow4 included .1.3.6.1.2.1.2.2.1.0.4  0xff:a0

４番目のインターフェース（eth2)の情報しか見えなくなる。

# snmpwalk -v 2c -c private localhost .1.3.6.1.2.1.2.2.1.10
IF-MIB::ifInOctets.4 = Counter32: 635738

# snmpwalk -v 2c -c private localhost .1.3.6.1.2.1.2.2.1.16
IF-MIB::ifOutOctets.4 = Counter32: 8933886

公開する情報を、特定のインターフェースに制限しつつ、様々な IfEntry を取得したい時などに便利そうですね。

まとめると、下記の設定はMIBのオブジェクトツリーのトップ（'iso(1)'）にのみビットが立っているので、配下のオブジェクトは任意 = 全て公開 ということになるんですね。

.1
 1 0 0 0 0 0 0 0   = 0x80