2009年8月31日月曜日

[Clustcom News] iptablesのDROPとREJECTはどう違う? 【後編】

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…☆
Clustcomニュースレター No.14  2009.8.31発行
             クラスターコンピューティング株式会社
☆…━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
# このメールは、WEBページから配信登録いただいたお客様、
# 過去に弊社に資料請求いただいたお客様、弊社スタッフと名刺交換を
# させていただいたお客様に配信しています。
# 配信停止手続きにつきましては、文末に記載させていただいております。


こんにちは。
Clustcomメルマガ担当の國生和栄です。


日本では台風を「台風3号」や「台風12号」のように番号で呼びますが、
台風に名前をつけて報道する国もあります。
 
 アメリカでは女性の名前ばかりつけるのが問題になり、その後は
男性名・女性名をABC順でつけていましたよね。


 それも2000年から変更になり、現在では東南アジアを中心とした
アジア諸国とアメリカで編成された台風委員会が、各国から提案された
名前リストを元に名前をつけることになっています。


 ちなみに日本は星座名からリストを作っています。
 「てんびん」「やぎ」など。


 12星座に限定されているわけではないので、、2009年の
台風第1号はちょうど名前リストの順番が第一号と重なり、
くじら座から取った「くじら」と命名されています。


 この話を、社内で話していると、
「フォーク歌手のイルカさんの「クジラのスーさん空をゆく」を
思い出す」
 と言われました。古い歌のようで、私にはわからないので
すが、台風を生き物の名前にすると、また違った感じが
しますね。


 今回の後記は、前回に引き続き、映画のネタを。
 最後まで、どうぞお付き合いください。



さて、本日のトピックです。


┌──Newsletter_Topic ─────────────────────┐


■【Topics】iptablesのDROPとREJECTはどう違う? 【後編】
■提供サービスのご案内

└──────────────────────Newsletter_Topic ─┘


┏┓
┗■ 【Topics】
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━★


━ iptablesのDROPとREJECTはどう違う? 【後編】 ━━━━━━


Linuxカーネル(2.4、2.6以降)には、iptablesというソフトウェアが
入っています。


これを使ってパケットフィルターを実現し、ホスト、ネットワークの
セキュリティーを向上させることができます。


iptablesには、他にもNAT/NAPT機能、コネクション追跡による動的な
パケットフィルター機能もあります。


フィルタールールとしてDROP/REJECTの設定を行い、
パケットを破棄させたとき何が起きているのかを tcpdump を使って
観測しています。今回は後編です。



実験環境として、
同一LAN上に、WebサーバーとWebクライアントを用意しました。


Webクライアント役: 172.16.20.1
Webサーバー役: 172.16.20.239



Webクライアント用のアプリケーションとして telnet コマンドを
使用しました。
TCPの通信テストを行なうには便利なツールです。


サーバーアプリケーションとして 一応 Apache を用意しました。
飛び交うパケットを観測するため、サーバー上で tcpdump も使用
しました。
プロンプトはどちらのホスト側で該当コマンドを実行したのかを示して
います。

実験は4パターン。以下のようなものです。


★実験1
 そもそも Apache が動いていない(該当ポート番号が開いていない)場合
ptablesの設定はデフォルト(ACCEPT)のまま


★実験2
 Apacheが動いているが、該当ポート番号を iptablesにより
DROP(黙って破棄)する場合


★実験3
 Apacheが動いているが、該当ポート番号を iptablesにより
REJECT する場合


★実験4
 Apacheが動いているが、該当ポート番号を iptablesにより REJECT し、
--reject-with icmp-host-unreachable を指定


今回は、以上のうち、実験3と4を行います。
実験1と2については、メルマガのバックナンバーをご覧ください。


http://www.clustcom.com/melma0141



■■□【実験3】 Apacheが動いているが、該当ポート番号を
iptablesにより REJECT する場合



サーバー側で以下の設定を行ないました。


server# iptables -F INPUT # 設定を初期状態に戻します。
server# iptables -i eth1 -A INPUT -p tcp --dport 80 -j REJECT
server# iptables -L -n -v | 一部抜粋

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT tcp -- eth1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 \
reject-with icmp-port-unreachable



上記の出力結果から何が起こるか想像できた人がいるかもしれませんね。
準備ができたら、
クライアント側からHTTPによる通信を開始します。



client$ telnet 172.16.20.239 80
Trying 172.16.20.239...
telnet: Unable to connect to remote host: Connection refused


直ちにエラー終了させられました。


その通信過程は以下のようになっていました。


server# tcpdump -i eth1 -p -n icmp or port 80


13:26:06.193291 IP 172.16.20.1.49539 > 172.16.20.239.80:
S 1546543459:1546543459(0) win 5840
<mss 1320,sackOK,timestamp 2462942116 0,nop,wscale 5>

13:26:06.193468 IP 172.16.20.239 > 172.16.20.1:
ICMP 172.16.20.239 tcp port 80 unreachable, length 68



ICMPのエラーがサーバーから送信されています。
そのメッセージには、その原因となったパケットが含まれています。


ICMPのエラーを受け取った側のOSは、
どのアプリケーションに関係する通信なのかを特定できます。
だから、telnetは速やかにエラー終了させられています。


意図しないアクセスに対して DROP すべきか、REJECT すべきか悩ましい
ところです。


多くのOSは REJECT を受け取ってしまうと、しばらくは再送しません。
DoS攻撃が止まってしまうかもしれません。
もし発信元のIPアドレスが偽造されていた場合には、不要なICMPエラーを
送信することになってしまうかもしれません。


なお、REJECTを使うと、そのホストが存在することが相手に知られて
しまいます。


man iptables をよくよく読んでみると REJECT するときの応答メッセージを
強制的に例えば
--reject-with icmp-host-unreachable
「該当ホストへ到達できません」と書き換えられるようです。
そのホストが存在しないという嘘?の応答を設定できるのです。


折角の機会なので、これも試してみました。



■■□【実験4】 Apacheが動いているが、該当ポート番号を iptablesにより
REJECT し、--reject-with icmp-host-unreachable を指定する場合



サーバー側で以下の設定を行ないました。


server# iptables -F INPUT # 設定を初期状態に戻します。
server#iptables -i eth1 -A INPUT -p tcp --dport 80 -j REJECT \
--reject-with icmp-host-unreachable
server# iptables -L -n -v | 一部抜粋

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT tcp -- eth1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 \
reject-with icmp-host-unreachable


準備ができたら、
クライアント側からHTTPによる通信を開始します。


client$ telnet 172.16.20.239 80
Trying 172.16.20.239...
telnet: Unable to connect to remote host: No route to host


その通信過程は以下のようになっていました。


server# tcpdump -i eth1 -p -n icmp or port 80
16:35:55.279386 IP 172.16.20.1.44872 > 172.16.20.239.80:
S 4036630540:4036630540(0) win 5840
<mss 1320,sackOK,timestamp 2465789402 0,nop,wscale 5>


16:35:55.279536 IP 172.16.20.239 > 172.16.20.1:
ICMP host 172.16.20.239 unreachable, length 68


と、あたかもホストが存在しないような ICMP エラーを発生させることが
できます。
ネットワークのトラブルシューティングが困難になるので乱用は禁物です。


しかし、悪意あるポートスキャンには有効なのかもしれません。
いずれにしても、どう設定すべきか、悩みは簡単に解消しそうにはありません。



参考文献:


man tcp
TCP http://tools.ietf.org/html/rfc793


man icmp
ICMP http://tools.ietf.org/html/rfc792


man iptables
http://www.netfilter.org/
http://www.linux.or.jp/JF/JFdocs/packet-filtering-HOWTO.html
http://www.asahi-net.or.jp/~AA4T-NNGK/ipttut/index.html
 


┏┓
┗■ 【提供サービスのご案内】
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━★


1)サーバの販売


  使用方法に応じたサーバを提案、販売しています。


  http://www.clustcom.com/melma0142


2)LVS負荷分散システムの設計/構築


  複数サーバの快適な応答速度のため、ロードバランサーの
  システムを設計し、構築します。


  http://www.clustcom.com/melma0143



3)完全冗長ソリューションの設計/構築 


  ネットワークを冗長化し、障害発生を避けるためのシステムを
  設計し、構築します。


  http://www.clustcom.com/melma0144



「携帯電話を含むインターネット事業へ業務を拡大しようかな」
「すでに持っているサーバの調子が悪いみたい」
「サーバの反応が悪いと利用者に言われるけれど」


 そんなときに思い出していただけたら・・・。


 クラスターコンピューティング(株)は、サーバ販売と、サーバを
快適に動かすシステムを作っている会社です。  


 

┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏


 ■クラスターコンピューティング(株)ホームページ
http://www.clustcom.com/


 ■clustcom かわらばん (ブログ)
http://kawaraban.clustcom.com/


 ■社長の独り言日記 (社長ブログ)
http://ktaka.blog.clustcom.com/


 ■メルマガアーカイブ (メルマガバックナンバー)
http://marc.clustcom.com/



┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏
 
いかがでしたでしょうか?
お役に立つ情報はありましたでしょうか?



 さて、後記です。


前回のメルマガでは、劇場版エヴァンゲリオンをネタにしましたが、
実は同日に「剣岳 点の記」も鑑賞していました。
 ときどきやります。レイトショー二本立て。


 日露戦争後の日本が舞台のこの作品。


 陸軍参謀本部陸地測量部の測量手、柴崎芳太郎が日本地図作成のための
最後の空白地帯を埋めるため「陸軍の威信にかけて」との命令を受けて
剣岳の登頂を目指す話です。


 ハリウッド系の映画と比べると格段に地味な映画ですが、製作者の
気概を感じられる良作だと思います。
 日本の映画会社が大枚はたいて、こういう映画に投資してくれると
いうのはうれしいものです。
 そのうち、大きくヒットが飛べば、また日本映画の傑作も生まれて
来るのではないでしょうか。


 原作は新田次郎さんで、映画「八甲田山」NHK大河ドラマ「武田信玄」
などの原作小説の作者でもあります。
 「八甲田山」というと、軍人が山でたくさん亡くなって怖いという
イメージが先行しがちですが、小説を読んでみると、ほどよくフィクション
で加工されており、チームを束ねるリーダーシップの差や下準備の
良し悪しが、プロジェクトの結果に多大な影響を与えるという側面が
描かれていて、現代にも通用するものが十分にあります。


 今回の「剣岳 点の記」で「八甲田山」と共通のテーマを感じたのは、
所属する組織の上層部と現場の認識の差。それから、上層部に理不尽な
要求をされても自分の仕事を真摯にこなす男の姿です。
 与えられた以上、困難でも自分のやるべきことと認識する。


 映画で表現されている、古きよき日本の男の静かな気概が、
じんわりとした感動を呼ぶところは、やはり良作です。


 年配の方に人気を集めているというのも、うなずけますね。


 あと、特筆すべきは山の持つ吸引力です。
 次々に映し出される雄大で美しく、そして見るからに険しい山の
姿に見惚れながら、どうして登山家は山に登るのかなぁと考えて
しまいました。
 そこに山があるからとは言いますが、湧き出す感情が伴うと
思うのですが・・・。


 ある街頭インタビューに答えていた一般登山者の方は、
「頂上で飲む一杯の酒の、すがすがしさのため」と答えていました。
 とってもリアルで真実味があると思います。



次回は9月15日頃に配信予定です。お楽しみに!

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ このメールの送信者
クラスターコンピューティング株式会社
〒194-0014 東京都町田市高ヶ坂803 番地
TEL:042-722-7702 FAX: 042-851-5716


クラスターコンピューティング株式会社は
Linuxで、ネットワーク・サーバインフラを作っている会社です。


■ 配信停止
配信停止は、お手数ですが以下のページからお願いいたします 
http://www.clustcom.com/melma/unsub/


Copyright(C) 2008 Cluster Computing ,Inc. All Rights Reserved.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# このメルマガの本文は著作権により保護されていますが、もし、
あなたのお役に立てるのであれば、ご自由に転載していただいて
構いません。その際には「Clustcomニュースレターによると。。。」と、
出典を明らかにするようお願いいたします。


■ どうぞ、ご友人にもご自由に転送してください。
■ 配信登録はこちらから
http://www.clustcom.com/melma/sub/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2009年8月7日金曜日

[Clustcom News] iptablesのDROPとREJECTはどう違う? 【前編】

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…☆
Clustcomニュースレター No.13  2009.8.7発行
             クラスターコンピューティング株式会社
☆…━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
# このメールは、WEBページから配信登録いただいたお客様、
# 過去に弊社に資料請求いただいたお客様、弊社スタッフと名刺交換を
# させていただいたお客様に配信しています。
# 配信停止手続きにつきましては、文末に記載させていただいております。


こんにちは。
Clustcomメルマガ担当の國生和栄です。


 梅雨も去って、蒸し暑い夜が続くようになってきましたね。
 そして、花火大会の季節到来です。


 外出先で偶然に遠花火を見かけると、心が弾みます。でも、いつもと
変わらないつもりで乗った電車で、うっかり観客の帰宅ラッシュに
巻き込まれたりなんかすると、憂鬱ですよね。


 日本国内と海外では、花火にも違いがあります。
 日本の花火は「菊」「牡丹」と称されるように、パッと丸く開く
ものが主流です。どの角度から見ても丸く見えます。


 ですが、海外では必ずしも丸く開くものが主流ではないようです。
 最近では、まるく開く花火も作られていますので、一概には断言でき
ないかも知れませんが、色の変化や尾を引かせるなどの技術は、
アジア圏独特のものと言えそうです。



 今回の後記は、話題のアニメ「エヴァンゲリオン:破」の楽しみ方を
紹介したいと思います。



さて、本日のトピックです。


┌──Newsletter_Topic ─────────────────────┐


■【Topics】iptablesのDROPとREJECTはどう違う? 【前編】
■提供サービスのご案内


└──────────────────────Newsletter_Topic ─┘


┏┓
┗■ 【Topics】
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━★


━ iptablesのDROPとREJECTはどう違う? 【前編】 ━━━━━━ 


Linuxカーネル(2.4、2.6以降)には、iptablesというソフトウェアが
入っています。

これを使ってパケットフィルターを実現し、ホスト、ネットワークの
セキュリティーを向上させることができます。


iptablesには、他にもNAT/NAPT機能、コネクション追跡による動的な
パケットフィルター機能もあります。


今回は、フィルタールールとしてDROP/REJECTの設定を行い、
パケットを破棄させたとき何が起きているのかを tcpdump を使って
観測してみました。



実験環境として、
同一LAN上に、WebサーバーとWebクライアントを用意しました。


Webクライアント役: 172.16.20.1
Webサーバー役: 172.16.20.239



Webクライアント用のアプリケーションとして telnet コマンドを
使用しました。
TCPの通信テストを行なうには便利なツールです。


サーバーアプリケーションとして 一応 Apache を用意しました。
飛び交うパケットを観測するため、サーバー上で tcpdump も使用
しました。
プロンプトはどちらのホスト側で該当コマンドを実行したのかを示して
います。


実験は4パターン。以下のようなものです。


★実験1
 そもそも Apache が動いていない(該当ポート番号が開いていない)場合
ptablesの設定はデフォルト(ACCEPT)のまま


★実験2
 Apacheが動いているが、該当ポート番号を iptablesにより
DROP(黙って破棄)する場合


★実験3
 Apacheが動いているが、該当ポート番号を iptablesにより
REJECT する場合


★実験4
 Apacheが動いているが、該当ポート番号を iptablesにより REJECT し、
--reject-with icmp-host-unreachable を指定


今回は、以上のうち、実験1・2を行います。



■■□【実験1】 そもそも Apache が動いていない(該当ポート番号が
開いていない)場合 iptablesの設定はデフォルト(ACCEPT)のまま


クライアント側からHTTPによる通信を開始します。


client$ telnet 172.16.20.239 80
Trying 172.16.20.239...
telnet: Unable to connect to remote host: Connection refused


直ちにtelnteはエラー終了しました。
その通信過程は以下のようになっていました。


server# tcpdump -i eth1 -p -n port 80 or icmp


11:32:16.496194 IP 172.16.20.1.47670 > 172.16.20.239.80:
S 1808538857:1808538857(0) win 5840
<mss 1320,sackOK,timestamp 2461234683 0,nop,wscale 5>

11:32:16.496331 IP 172.16.20.239.80 > 172.16.20.1.47670:
R 0:0(0) ack 1808538858 win 0



TCPコネクション開設要求(Syn パケット)がクライアントから
サーバーへ送信されています。

その応答(SEQ番号1808538857+1=1808538858がACK番号)として
Reset
が返送されています。


そのためクライアント側のアプリケーションは直ちに終了させられて
います。



■■□【実験2】 Apacheが動いているが、該当ポート番号を
iptablesにより DROP(黙って破棄)する場合



サーバー上で以下の設定を行ないました。


server# iptables -F INPUT # 設定を初期状態に戻します。
server# iptables -i eth1 -A INPUT -p tcp --dport 80 -j DROP
server# iptables -L -n -v | 一部抜粋


Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP tcp -- eth1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80


準備ができたら、
クライアント側からHTTPによる通信を開始します。


client$ telnet 172.16.20.239 80
Trying 172.16.20.239...



3分間ほど待たされて。。。



telnet: Unable to connect to remote host: Connection timed out


とtelnetがタイムアウトしました。



その通信過程は以下のようになっていました。


server# tcpdump -i eth1 -p -n port 80 or icmp


11:51:22.835468 IP 172.16.20.1.60098 > 172.16.20.239.80:
S 2607676146:2607676146(0) win 5840
<mss 1320,sackOK,timestamp 2461521270 0,nop,wscale 5>


11:51:25.835288 IP 172.16.20.1.60098 > 172.16.20.239.80:
S 2607676146:2607676146(0) win 5840
<mss 1320,sackOK,timestamp 2461522020 0,nop,wscale 5>


11:51:31.835230 IP 172.16.20.1.60098 > 172.16.20.239.80:
S 2607676146:2607676146(0) win 5840
<mss 1320,sackOK,timestamp 2461523520 0,nop,wscale 5>


11:51:43.835209 IP 172.16.20.1.60098 > 172.16.20.235.80:
S 2607676146:2607676146(0) win 5840
<mss 1320,sackOK,timestamp 2461526520 0,nop,wscale 5>


11:52:07.835072 IP 172.16.20.1.60098 > 172.16.20.239.80:
S 2607676146:2607676146(0) win 5840
<mss 1320,sackOK,timestamp 2461532520 0,nop,wscale 5>


11:52:55.834795 IP 172.16.20.1.60098 > 172.16.20.239.80:
S 2607676146:2607676146(0) win 5840
<mss 1320,sackOK,timestamp 2461544520 0,nop,wscale 5>



同じSEQ番号 2607676146 でTCPコネクション開設要求(Synパケット)を
何度も送信(つまり再送)していることがわかります。


その間隔は、3秒後、6秒後、12秒後、24秒後、48秒後と2倍づつ増えて
います。


5回再送(一番最初のものを含めるとと合計6回送信)を行ない、
約3分後にtelnetコマンドがタイムアウトしました。



man tcpすると、、、


tcp_syn_retries (integer; default: 5)

→アクティブな TCP 接続に初期 SYN の再送を試みる最大回数。この数値
は 255 よりも大きくすべきではない。デフォルトの値は 5 で、およそ
180 秒に対応する。


とありますので、これが効いているようです。



 今回は、ここまで。
 次回、実験3と4を行います。



参考文献:


man tcp
TCP http://tools.ietf.org/html/rfc793

man icmp
ICMP http://tools.ietf.org/html/rfc792

man iptables
http://www.netfilter.org/
http://www.linux.or.jp/JF/JFdocs/packet-filtering-HOWTO.html
http://www.asahi-net.or.jp/~AA4T-NNGK/ipttut/index.html


 


┏┓
┗■ 【提供サービスのご案内】
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━★


1)サーバの販売


  使用方法に応じたサーバを提案、販売しています。


  http://www.clustcom.com/melma0131



2)LVS負荷分散システムの設計/構築


  複数サーバの快適な応答速度のため、ロードバランサーの
  システムを設計し、構築します。


  http://www.clustcom.com/melma0132



3)完全冗長ソリューションの設計/構築 


  ネットワークを冗長化し、障害発生を避けるためのシステムを
  設計し、構築します。


  http://www.clustcom.com/melma0133



「携帯電話を含むインターネット事業へ業務を拡大しようかな」
「すでに持っているサーバの調子が悪いみたい」
「サーバの反応が悪いと利用者に言われるけれど」


 そんなときに思い出していただけたら・・・。


 クラスターコンピューティング(株)は、サーバ販売と、サーバを
快適に動かすシステムを作っている会社です。  


 
━=━=━=━=━=━=━=━=━=━=━=━=━=━=━=━=━=━


【お便り募集】


読者の皆様からのお便りを募集しています。
 ご感想、ご質問などをお寄せください。


日ごろ疑問に感じていること、専門的な疑問、なんでもかまいません。
 もちろん、基本的なことも大歓迎です! 


紙面掲載させていただいた場合には、ささやかなプレゼントを差し
上げます。

┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏


 ■クラスターコンピューティング(株)ホームページ
http://www.clustcom.com/


 ■clustcom かわらばん (ブログ)
http://kawaraban.clustcom.com/


 ■社長の独り言日記 (社長ブログ)
http://ktaka.blog.clustcom.com/


 ■メルマガアーカイブ (メルマガバックナンバー)
http://marc.clustcom.com/



┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏
 
いかがでしたでしょうか?
お役に立つ情報はありましたでしょうか?



 さて、後記です。


新劇場版の「エヴァンゲリオン:破」はご覧になりましたでしょうか?


 ご存じない方にご説明いたしますと、エヴァンゲリオンというのは、
1995年に放送されていたテレビアニメ作品です。
 放送当時、思春期の精神的な成長や閉塞感を描いたことで注目され、
アニメファンでなかった視聴者も引き込まれて、大ブームになりました。


 今回の【エヴァンゲリオン:破】は新劇場版の第二作目。
 ますますタイアップが派手になり、話題騒然のエヴァですが、
この作品には大きく分けて、二通りの楽しみ方がある!と私は思っています。


 詳しい方にはいまさらなお話ですが、ご存じない方はちょっとした
小ネタとして頭のポケットへ収納してくださいませ。


  
<その1>
◎ごくごく普通に、思春期少年の成長モノとして楽しむ。
  
 →この作品はロボットアニメの皮をかぶった【萌えアニメ】です。
  女の子の魅力にドキドキして、派手な戦闘にわくわくして、
  そして張り巡らされた伏線のことなど忘れて楽しんでください。
 (テレビ版・旧劇場版では伏線が回収されず、放置されることが
多々あります。)



<その2>
◎特撮マニアたちの集大成を楽しむ。


 →オタクとしては、このうがった楽しみ方が大プッシュです。


  エヴァンゲリオンはケーブルがはずれると、数分しか戦えません。
  エヴァンゲリオンはちょっと猫背気味に戦います。


  なにかを思い出しませんか?


  エヴァには、70年代前後のSFブームが大きく影響しています。
  その時代に少年や青年だった人たちが作り手になって、自分たちの
  愛したものを詰め込んだ作品という見方ができます。



 数分しか戦えない、ちょっと猫背気味に戦うのはウルトラマンですね。
 作中では、エヴァがライダーキックを決めたりもしています。


 今回の新作でも、かつてのSF作品や70年代頃のオマージュが
全編に散りばめられていました。
  
劇場版は全4作の予定。前作から今作まで、2年。
 次回作の公開はいつでしょうか・・・。


 そういうわけですので、まだまだ完結までは時間がかかります。
 今から、テレビ版を見はじめても間に合います。
 お暇があれば、是非どうぞ!!



次回は8月20日頃に配信予定です。お楽しみに!

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ このメールの送信者
クラスターコンピューティング株式会社
〒194-0014 東京都町田市高ヶ坂803番地
TEL:042-722-7702 FAX: 042-851-5716


クラスターコンピューティング株式会社は
Linuxで、ネットワーク・サーバインフラを作っている会社です。


■ 配信停止
配信停止は、お手数ですが以下のページからお願いいたします 
http://www.clustcom.com/melma/unsub/


Copyright(C) 2008 Cluster Computing ,Inc. All Rights Reserved.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# このメルマガの本文は著作権により保護されていますが、もし、
あなたのお役に立てるのであれば、ご自由に転載していただいて
構いません。その際には「Clustcomニュースレターによると。。。」と、
出典を明らかにするようお願いいたします。


■ どうぞ、ご友人にもご自由に転送してください。
■ 配信登録はこちらから
http://www.clustcom.com/melma/sub/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━