SSG140 Cannot allocate of memory

10月23日の4時頃、サーバのサービスやリソース状態を監視するサーバから100通を超えるALERTメールが携帯電話に入ってきました。とめどなく流れ込んでくるメールが内容を確認する前からただ事ではないことを知らせています。
それらのメールでホスト名を確認すると、VPSサーバに割り当てをしているホストからのものばかり。恐怖でブルブルと震えながらMacを立ち上げ監視サーバを確認すると、VPSだけではなく別のサーバでもアラートが発生していました。
もしかしてVPSサーバのハードが逝ってしまったのか!と思っていたので、少し安心しましたね、変な話ですが。
さらに調べていくと、アラートの傾向が分かりました。25/tcpと80/tcpのみがアラートを発していました。サーバにログインすると、各サービスは正常に稼働しているのに外部からポートを叩くと応答がない。これはファイアーウォールの問題だとすぐに分かるが、なぜ?110/tcpと443/tcpは問題ないのに。

SSG140 Cannot allocate xxxxxxxx bytes of memory

SSG140


相方と連絡を取り合いさらに調べていくと、ファイアーウォールのログに「Cannot allocate xxxxxxxx bytes of memory」とありました。それ以前のログを調べても大した処理してないのになんで?
原因の追及よりもサービスを復旧させることが最優先なのでそれに当たる。
ファイアーウォールはJuniperのSSG140を使用していて、Deep Inspection(不正侵入検知)という機能を有効にしていました。Deep Inspectionを有効にすると、 HTTP、SMTP、IMAP、POP、FTP、DNSのプロトコルに対応する特定のトラフィックに対してアプリケーションレベルのサービスを狙った攻撃やプロトコルの逸脱を排除することができるようになります。
おそらく、ポートの疎通ができなくなったのはこのDeep Inspectionによるもので、メモリーの解放ができていないのではないかと狙いを定めました。SSG140の再起動を考えましたが、配下にあるサーバはサービス提供中で全てが機能していない訳ではないのと、設置場所が遠隔地になるのでそれは最終手段としました。
で、取った手は、Deep Inspection機能を無効にすること。無効にすることでメモリーとブロックされているポートが解放されるであろうと思ったのですが、オペレーションエラーとなり玉砕。
悩んでいると相方から連絡が入り、「できました!」との一声。それと同時に監視サーバから怒濤の如くRecoveryメール。
相方は機転を利かせ、ファイアーウォールのポリシーを組み替えてポートの解放を行なったとのこと。私一人では復旧はできませんでした。感謝感謝!
一連の事象について後にメーカー側に問い合わせをすると、SSG140で使用しているOSのファームウェア(6.0.0r8.0)にメモリの開放漏れとなる不具合があり、Deep Inspectionの更新等を行うとメモリアロケーションエラーになるという現象が発生するとのこと。
若干内容は異なりますが、JuniperのSupportページに似たような現象について書かれています。
ファームウェアに対して修正パッチが用意されているので、パッチを当てることで問題は解消されます。ファームウェアは、 6.0.0r8.0 → 6.0.0r8-hw2.0 にアップデート。
 

関連記事一覧

  1. この記事へのコメントはありません。