読者です 読者をやめる 読者になる 読者になる

NW屋的日常徒然日記

ネットワークを専門にする元社内SEの日常とITネタ諸々を綴って行きます。

【JTB】詳報を基にNW構成の問題点を考える

ネットワーク 情報セキュリティ DNS

 こんばんは。昨日のJTB子会社情報漏洩事件の詳報がITproに記事が上がっていました。この記事を基にセキュリティ上及びNW構成の問題点を検討して行きたいと思います。

 まず、3月15日に標的型メールが届いたことに端を発します。メールを受信したPCがマルウェア感染し、他のPCにも感染を広げたようです。この記事の図を見る限りでは、感染した/させられたPCを含めて同一セグメントに配置されています。そして、サーバセグメントは別になっているようですが、この間にFWが設置されているようには記載されていません。この図の矢印がインターネット方向を向いているので疑問が残りますが、「webサーバへの不審な通信を検知」とあります。外部からwebサーバへのアクセスがあって、マルウェア感染したwebサーバが(不審な相手先の)外部へ通信して情報漏洩ということなのかなと理解しています。「不審な通信先をブラックリスト登録」とありますから、素直に読むと、webサーバから「不審な通信先」に対して通信を行っているものと理解出来ます。

 ということは、

 webサーバが直接外部に対して通信出来るということになりますが???

 webサーバはサーバ内のコンテンツを外部に提供するのが役割なので、自分がクライアントになる場面というのはかなり限られるはずです。なので、外部との必要最小限の通信に絞り込んで、プロキシサーバ経由で通信し、それ以外はFWで禁止してしまえば良さそうに思えます。

 それから、PCからwebサーバと商品情報制御サーバに通信出来てしまうのはどう考えても拙いので、PCもwebサーバに接続出来るがメールはNGなVLANと、メールは受信可能だがwebサーバには接続不可なVLANの2つに分割した方が良さそうです。(実際の運用はもう一捻り要りそうですが)

 そして、webサーバ用VLANと商品情報制御サーバ用VLANとデータベースサーバ用VLANに分割して、webサーバ--->商品情報制御サーバ--->データベースサーバの通信方向のみ許可(もちろんポートも限定する)するようにFWで制御してやればいいのではないかと(この図を見る限りでは)考えました。

 さらに、「メール発信元は海外のレンタルサーバだ」とありました。ということは、FromフィールドとIPアドレスが合致しない可能性が高いと推測します。だとすると、メール受信側がSPF認証対応であれば弾き飛ばせた可能性もあったように考えられます。送信元をANAに偽装していたような話でしたので、ANASPFレコードをDNSサーバに登録していれば、この情報を基に弾くことは可能です。

(先程ana.co.jpのTXTレコードを引くとちゃんと結果が返ってきました。)

 ただ、SPF対応と言っても、DNSサーバにTXTレコードでIPアドレス等を記述しているだけで、受信側の対応をしていないケースや、記述内容が"-all"ではなく、"~all"と書かれているケースがあります。前者なら問答無用で弾くことが可能なのですが、後者ですと、設定によりますがsoftfail扱いで疑わしいまま受信してしまうことになります。因みにana.co.jpは"-all"でhardfailでした。

 他にこの記事ではC&Cサーバが使うポートとプロトコルに関しても言及しています。「「今までは独自ポートを使っていたが、最近はhttpプロトコルで80番ポートを使うようになったので検知しにくくなった。」とのことです。となると、単なるFWでは怪しい通信かどうかの判断が難しくなります。L4までしか見ないタイプのFWではなく、L7まで見るFWやUTMに置き換えてやる必要があります。

 そして、社内にセキュリティ専任部門がないというのもかなり拙かったように思われます。あくまでITproの記事からの推測でしかありませんので、本当のところは分かりませんが、設計上の甘さがあったんじゃないかと思えてなりませんでした。