3月の頭に、22台のログBOXが一斉に導入されました。
事前に1台1台の動作確認を行い、個々には問題無い状態を確認していたにもかかわらず、22台のログBOXが動き出すにつれて計測データがサーバに上がって来ないものがある現象に遭遇しました。
最初は3Gルータの調子が悪いのかと想像したのですが、単体試験では問題なく、動いていたし、一応現地BOXのふたを開けて見て貰ってもルータとして接続はできている表示との連絡です。
実際、BOX～サーバ間のVPNでは問題なくサーバかわBOX側にアクセスできてしまいました。
・・・
なんじゃろう。。
と思って入り込んだBOX側で、おもむろに python 製のアップローダを手動で起動してみると
connect
が成功してログインも成功するのに、
timeout
のエラー表示。。
あーーー、そうだFTPの受信用のポートが足らない。。
実は未だに旧態然としたファイル転送であるFTPを利用しているのですね。。
FTPを使っていた最大の理由は、OSが搭載しているFTPサーバにゆだねる事ができた為、受信処理を後回しにできたことです。開発リソースの少ない状況で安易な選択だったなぁと今では後悔していますが、、
しかし、FTPには欠点というか、手順上しかたのないリスクもあります。
一つは制御を行う通信路とデータ送受を行う通信路が別々に必要であることと、
一つはクライアント側で固定IPを持てない場合にサーバ側にデータ受信用のポートを用意しておく必要があるという事です。
ログBOXは、5分おきに測定して結果をローカルのデータスプールに蓄積するので、ほぼ同じタイミングで一斉にアップロードしてくる訳で必然的に大量の受信ポートが必要になります。
という事で、受信ポートを予約数を増やしたのですが、、、今回はこれで暫定処置です。
たくさんの外部からコネクト可能なポートを開けるというのはセキュリティ的によろしいはずもありません。
そこから入られる事は無くても、アクセスされるというのは「アクセスできる事実」を攻撃者に与えることなので、FTPのパッシブポートを用いた攻撃方法を試してくる可能性があることが気持ち悪しですし、なによりもスケールしていく事ができないことが問題です。
早い内に、HTTPでのアップロードに切り替え、効率的に処理できるように見直して行きます。
