Ruby on RailsでWifiルータ一覧サイトを作ってみました


背景・目的

昔からNW機器が好きです。特にルータとスイッチ。IPSやDDoS製品の導入やエージングもたまにやっていたりしますが、「自宅でも無駄に凝ったNWを作るのが好きです。」

そのような趣味が高じて、以前は自宅内でラックを用意して1Uのスイッチやルータ(簡易FW)等もおいていたのですが、電気代、騒音が問題となり、結局は消費電力が低くて静音で使いやすい物を・・・と調べることになります。

調べていても脳内に残っていてそのうち忘れてしまうので、情報のまとめサイトとしてRails6.1で構築してみたので、公開してみます。

「この製品はファームウェア〇〇で安定した」、「サポセンが優秀」、「△△で特価販売中」等のコメントも受け付けられるようにしたので、ナレッジとして共有できれば幸甚です。

実サイトのご紹介

hwlog.senritu.netとして公開しました。一人で調べてデータ登録していた為、まだ無線LAN製品しか登録がありませんが、この後、スイッチのページも追加予定です。

サイト作成時に試行錯誤した点

WordPressや、固定的なHTMLでのサイト公開は何度も経験があるものの、個人でウェブアプリケーションを開発して公開する一連の流れを実施したのは初めてとなったため、苦労した点とそれをどうしたかをまとめてみます。

タイトル苦労した点解決方法
サイトデザインデザイナーではない為、サイトの配色等に困りました。多色でサイトを作ろうとすると、フォントや背景色など気になる点ばかりが増えて、配色だけで時間を要することも。カラフルな色使いは止めました。黒・グレー・白のみとし、リンクを青、警告を赤と割り切りました。

その代わり、内容が整ってきたら更新できるよう、色指定はCSSにまとめました。
コンテンツ内容凝ったリンク集のようなものをイメージしていた為、各社の製品ページやマニュアルを見て登録するのが大変。こちらは地道に登録しました。Railsでscaffoldしたようなページだと登録効率が悪い為、新規登録時と編集時でUIを変更しました。

以前、データ元は全部エクセル管理し、WordPressにまとめて投稿するPythonプログラムを作った事がありますが、大量のデータを扱うときは、表組の方が前後比較も出来、間違いに気づきやすく誤字脱字を修正しやすいです。

上記をRails上の編集ページでも実装しようとしてToDoとして管理しています。
速度全体をRailsの動的ページで表示すると、性能劣化が心配。かつ高性能サーバが必要となり維持費が大変。RailsでCMSを作り、HTMLを出力して提供しています。ですので、提供されているページの大半をただのHTMLで提供されるようにしました。

例えば、このソート済みページもHTMLで提供しています。
第三者のデータ登録上記のようにRailsをCMSのようにしたため、コメントなどのユーザーからのフィードバックを受けられない。Ajaxでコメント登録機能等は背後のアプリケーションサーバにリクエスト送信するようにしました。

コメント反映は即時とすることも可能だったのですが、一定時間後に反映する設計としました。
セキュリティ不必要なコンテンツの表示や、Webページを対象とした攻撃への対策がきちんととれているか?上記の通り、コンテンツをHTMLとして提供する方向で舵を切ったため、評価すべき個所が少なくできました。

Rails内でコメントに対するバリデーションを実施しているのみです。

また、ユーザー登録、コンテンツ編集画面等は、サーバの設定で外部からアクセス不可としています。
スパム対策スパムコメント対策の仕方が不明サーバのログから投稿元を確認することは出来るので、事後対応となる。
WordPressで言うところの「Akismet Anti-Spam」のような仕組みをつけたいが、ToDoとしました。
本番公開開発環境と本番環境は異なるが、本番環境でミスった場合のリカバリをどうするか?コンテンツをHTMLとして出力する為、日ごとのフォルダが分かれているので、以下の対策が可能
・本番サイト(コンテンツ):正常時点への戻し
・本番サイト(プログラム):gitからの戻し
・DB:前日戻し
サイト作成時に試行錯誤した点

リリース前のセキュリティ評価について

個人のウェブアプリケーション構築の為、脆弱性評価予算(※)は勿論持っていません。

(※)仕事で何度も脆弱性診断を発注した事がありますが、業者によって値段もピンキリで一回の診断で最低でも100万以上はかかります。ページ数が多いと2000万~3000万は覚悟する必要があるので、最初から検討外です。

しかし、ウェブアプリケーションを一般公開するということは、万が一の場合、第三者に迷惑をかけてしまうこともある為、下記対策を実施しました。

OS側の対策

  • パッチの最新化
  • Webサーバ等の設定を厳格に
  • 不必要なサービスの停止
  • 外部からアクセス可能なポートを最小限とするようFWで制御
  • Webサーバ設定で管理者向け画面へのアクセスを制御

本音としては、ログの監視も取り入れたいのですが、これは定点での実施にしています。

ウェブアプリケーション側(プログラム)の対策

  • 【設計】開発言語の最新化
  • 【設計】外部流出して問題となるデータを排除
  • 【設計】第三者からの入出力がある個所を明確化
  • 【設計】第三者提供画面はHTMLとする
  • 【実装】一般的になXSS対策やOS、DBインジェクションはFW側で対処
  • 【実装】コンテンツ編集画面はユーザー認証必須(そもそも外部からアクセスできない為、多段防御)

個人で公開したウェブアプリケーションに対する攻撃評価手法は、運用しながら勉強していきたいと思います。

・・・・とは言っても、脆弱性診断ベンダが高額で提供しているサービスなので、個人ベースでどこまで出来るかは不明ですが・・・・

今後について

伝統的な日本企業で働いていると、「完璧なものにしてから・・・・」と言う考えが根付いてしまうのですが、個人提供サービスであれば、まずはある程度のコンテンツが登録出来たら公開してしまって良いのではないかと考え、今回の公開に至っています。

一旦、公開してしまうことで「コンテンツ追加や機能追加、バグ修正をしなくちゃ」と言うモチベーションも高まる為、完璧を目指すよりは走りながら考えたいと考えています。

ブックマーク パーマリンク.

コメントを残す

メールアドレスが公開されることはありません。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください