タグ: さくらのVPS

さくらの VPS のパケットフィルタリングを使った SSH ポート開放

以前は iptables にてフィルタリングしていたが、「さくらの VPS」コンソールにある「パケットフィルタリング機能」が拡張され、任意 IP アドレスのフィルタリング設定が可能となったため、SSH ポート開放の制御をそちらに寄せることにした。

手順

自分が接続しているマシンのネットワークIP（グローバルIP、ゲートウェイIP）を探す

AAA.BBB.CCC.DDD

さくらのVPSに接続

パケットフィルタの設定を追加（変更）

設定項目は以下。

  • フィルタの用途「カスタム」
  • プロトコル「TCP」
  • ポート番号「22」
  • 許可する送信元IPアドレス「AAA.BBB.CCC.DDD/32」
    （サブネット「/32」は、上記1つのIPアドレスのみ許可の意。「/32」とかアドレス範囲とか知りたい人は GGR）

この状態で Teraterm, WinSCP などから接続確認

問題なければ、これで終了。
かなり簡単になった。

メリット

  • GUI (Web) 上での設定なので、操作自体が簡単。

デメリット

  • GUI (Web) 上での設定が必須なので、手動作業。一連作業の自動化ができない。
  • パケットフィルタリングの機能自体による制約が生じる。
  • ログを残すような設定など iptables で可能なことができない。
  • カスタムフィルタリングは最大で10個までしか設定できない。
  • 個々のフィルタリングに対してコメントが残せないため、可読性が下がる。
    （間違えて別のパケットフィルタリングを上書きしてしまう恐れなど、ケアレスを誘発する恐れあり。
    まぁ iptables の場合は煩雑で失敗した場合のインパクトは同じような気がする。
    どっちもどっち。）

これらデメリットから、特にログが残せないなどの点については、企業によっては監査が通らない気がする。
その場合はこの設定簡略化そのものが採用できない。

注意

「パケットフィルタを利用しない」とか「SSHを『すべて許可する』」には、くれぐれも選択しないこと。
iptables で適切にフィルタリングをしているなら話は別だが、サーバが丸見えになってしまい、セキュリティ上のリスクが爆増する。

特にビギナーや素人

繋がらないからと言って、この辺りの操作をすると、「あっ」と言う間に何処かの大陸方面からサーバ乗っ取られて、踏み台にされて、さくらインターネットから「サーバー強制停止 ⇒ コンソール（コマンドライン）で対処するか、サーバ初期化するまでパケット全閉塞（実質利用できない）」を喰らうことになる。

少なくとも、SSH からの root 認証不可は絶対だし、鍵認証必須（パスワード認証不可）は強推奨。

【参考】

Web については、.htaccess にてドメインフィルタリングしている。
そのためパケットフィルタは、敢えて「すべて許可する」にしている。

フォトアルバムを設置する

こちらの記事は、今後のシステム開発で経過に応じて、随時編集・追記します。

プロバイダーのホームページ領域を有効活用するため、フォトアルバムでも設置しようかと考えている。

まぁ「フリーのCGIとかプログラムを導入すれば、いいんじゃね」というレベルの、とてもありがちなシステムをつもりなんだが、それら「吊るし」のシステムだと、自分が契約している Web サーバ領域を有効利用するためには、仕様・環境などの条件がイマイチ合致しない。

特に問題となるのがこれ。

@nifty ホームページサービス ミニプラン

そう。
公開ページの設置を予定しているこのWeb領域が、曲者。
もともとは、老舗の「@nifty @homepege」の後継で、先代で提供されていた機能を、最低限継承した代物。

なので、Perl は使えたりするものの、5.8.7 と古かったりとか、一部の標準モジュールが使えなかったりする。
PHP も、このプランでは使えない。

別の記事でも書いたが、上位プランに変更することにより、PHP やデータベースが利用できるようになるのだが、料金や自由度を考えると、別会社のプランを検討する。

確かに巷の Perl CGI を探してきて、それを改造して無理矢理動かすというのも一案。
しかしながら、それだと楽しくないし、そもそも巷の Perl CGI も、かなり前に作られたものが多く、レガシーな作り物が多い。

そんなこんなの理由で、昨今のスタンダードな Web システムの実装とレガシーなサーバ環境の共存を研究する目的で、フルスクラッチしてみることにした。

システム構成

ありがちな「公開系」と「管理系」の２構成。

フロントエンド（公開系）

サーバは「@nifty ホームページサービス」
Web コンテンツは「Perl (CGI) + Vue.js (CDN)」で実装。

こちらは「見せるだけ」の機能に特化して、複雑な処理は走らせない。
というか、制限付き CGI （Perl 旧バージョン＋標準モジュール一部欠け）をゴリゴリ開発する気は、更々ない。

Vue.js を利用するものの、フレームワークというよりは、結果セットのフィルタリングやソート時のエフェクト用途で利用する感じ。
ほぼ「受け身」のシステムなので、この程度の簡単な環境で構築。

バックオフィス（管理系）

サーバは「さくらの VPS」
Web コンテンツは「Laravel (PHP) + Vue.js（Laravel のUI として利用）」

こちらは管理機能を実装するため、Web システムとしてはガチ。
とはいえ、昨今の Web システムでは、割とスタンダードな環境。

ちなみに Laravel が Ver.5.x までであれば、Vue.js は内包されていたため、「さくらのレンタルサーバ」でも構築できた。

しかしながら Laravel Ver.6 以降、Vue.js はコマンドで追加インストールするようなスタイルになった。
しかもこのコマンド、中で npm を使用するのだが、この npm が「さくらのレンタルサーバ」がインストールされていない。

調べた限りでは「さくらのレンタルサーバ」に npm を力業でインストールするような猛者もいたようだが、当然ながらトリッキーなため、この時点で「さくらのレンタルサーバ」も採用外とし、「さくらのVPS」への実装とした。

個人的には、今後のシステム開発において「さくらのレンタルサーバ」は、パッケージ不足等で、いよいよ「使えない」という時代がやってきた事を感じてしまった瞬間であった。

公開系と管理系、「さくらの VPS」で構築すれば楽じゃね？

確かにそうなんだけども。
でも、元々「さくらの VPS」は、非公開系のサーバとして運用しているという個人的な事情と、公開系と管理系を同居させることによるセキュリティ面の配慮で分けた次第。
また「レガシーな Web 領域（＝@nifty ホームページサービス）を有効利用する」という命題に応えるため、このような環境にした次第。

重要な考慮すべき部分

バックオフィス⇒フロントエンドの同期

データの追加・更新・削除の都度、キューを作成し、それを非同期バッチにて処理する事によってデータの内容をフロント側に反映することで同期する。

クラッシュ対策（バックアップ）

システム基盤（プログラムソース）については、別途バックアップする（というか、Git に保管しておく）のが前提。
ここで言うのは、データの話。

ちなみに、この Git リポジトリ。PostHook で別サーバに Fetch してるので、リポジトリ自体も複数保存している。

公開系

もともとデータはすべて「管理系」に保持していて、そこから抽出・アップロードされるため、クラッシュしても、データは「管理系」のほうから再度抽出することでリカバリ可能とする。

管理系

データについては、日毎のバックアップをバッチ処理し、バックアップサーバ（ストレージ）に転送する。

考えていること

データ連携

最初はこんな感じで考えていたのだが、もしかしたら Perl の簡易データベース（dbmopen など）が使える可能性があるので、利用可能であれば、その形式に寄せるつもり。

画像

閲覧用画像データには、コピーライトの埋め込みで、以下の候補を検討中。(TBD)

  • ウォーターマーク ⇒ ImageMagic で可能だが、簡単に消せる。
  • 電子透かし ⇒ できればこっちを考えている。
    ステガノグラフィーが主流だと思うけど、技術的に標準化されてないので、できれば標準的なのが使いたい。