.png){kind=small}
Vol.02 記事一本で押さえるネットワークセキュリティの基礎
- mitsuruto32
- 4月24日
- 読了時間: 15分
この記事であなたがやるべきこと
ネットワークセキュリティの基礎として、以下の5項目でやるべきことを押さえておくこと
ファイアウォールによる厳密なIP/ポートアクセス制御
IDS/IPSによる侵入検知/防御
VPN機器のセキュリティ対策は万全に！
本当の意味でセキュアなプロトコルを使う
ネットワーク機器や通信のログは重要なものに絞って取得
やるべきことに加え、考え方や思想を含めて理解し、要件に応じて対策を行うかどうか判断できるようになること
はじめに
「ネットワークセキュリティ」という言葉を聞いて、皆さんはどんな想いを抱きますか？「得意です！」「大好き！」という方も中にはいらっしゃるかもしれませんが、「正直ピンとこない」「あんまり得意じゃない」という方も少なくないでしょう。
会社、あるいはシステム全体のセキュリティ対策を考えるうえでも、ネットワークセキュリティというのはかなり重要度が高い位置づけです。しかし、そもそもネットワークを専門とするエンジニアが少ないこともあり、ネットワークセキュリティに関して盤石な知識とスキルを持っている人は少ないです。若手エンジニアならなおさらです。
そこで今回は、セキュリティに興味を持ち始めたネットワーク担当のエンジニア向けに、「とりあえずこの記事の内容を押さえておけばネットワーク対策の第一歩としてはOK」というところを目指して解説していきたいと思います。
ネットワークセキュリティってどんなもの？
そもそも「ネットワークセキュリティ」って具体的に何を指すのでしょうか？ここでは、「ネットワーク担当のエンジニアがネットワーク機器で行うセキュリティ対策」としておきます。そのため基本的にはルーター、ファイアウォール、ロードバランサーやネットワークアプライアンス等のネットワーク機器で行うセキュリティ対策に焦点を絞ります。
ちなみに、「ネットワーク担当のエンジニア」の業務内容は企業やチームによっても様々で、場合によっては以下のようなものもネットワーク担当が兼任していることもあるかもしれませんが、今回は対象外とします。
アンチウイルスソフトやEDRによるマルウェア対策
各サーバー内で行うセキュリティ対策※
メールセキュリティ
※各サーバー内におけるセキュリティ対策は本シリーズの「Vol.01 ゼロから始めるサーバーセキュリティの入門」でご紹介してますので、サーバーセキュリティにもご興味ある方はぜひご一読ください。
ネットワークセキュリティ対策一覧
それでは本題のネットワークセキュリティ対策に入りたいと思います。今回は以下の5つを紹介します。
ファイアウォールによる厳密なIP/ポートアクセス制御
IDS/IPSによる侵入検知/防御
VPN機器のセキュリティ対策は万全に！
本当の意味でセキュアなプロトコルを使う
ネットワーク機器や通信のログは重要なものに絞って取得
ファイアウォールによる厳密なIP/ポートアクセス制御
ネットワーク対策において最も基本となるところですが、非常に重要です。特にインターネット向けに公開しているシステムにおいてファイアウォール機器によるIPアドレス/ポート番号ベースのアクセス制御（パケットフィルタリング）自体をしていないところはほぼないとは思いますが、アクセス制御の厳しさについてはシステムによってまちまちです。
例えば、
インターネット→内部へのアクセスはしっかり制限しているが、内部→インターネットはパッチやツールインストール等で多数の接続先にアクセスすることがあるため、宛先Anyで全開放してしまっている
サーバ台数が増えたときにいちいちファイアウォールの設定変更をしなくて済むように、
内部間の通信はセグメントレベルで広く開放しており、これによって本来必要のないサーバー/端末間も通信可能になっている
TCP/UDPポートでのアクセス制御は厳密にしているが、ICMPは疎通確認や障害切り分け時によく使うので送信元Anyで許可している
というケースです。
「別にそれぐらい普通では...」と思われるかもしれませんし、実際私が見ていた現場でもこうした設定は多々見かけました。しかし、これらはすべて攻撃を受けるリスクがある設定です。
万が一システム内部に侵入された際に、内部からインターネット経由で攻撃者のサーバに情報を持ち出すことが容易にできてしまう
とある端末がランサムウェアに感染した際に、本来通信要件のないサーバに対しても感染を広げることができてしまう
ICMP Flood攻撃（Pingを使ったDoS攻撃）を仕掛けることができる
基本的には、
内部→インターネット向けの通信も、必要なものを洗い出して最小限に絞る
内部間の通信もネットワークセグメントレベルではなくホスト（/32）レベルで絞る
ICMPも必要な送信元/宛先IPアドレスに対してだけ許可する
というのがセキュリティ的にはベストプラクティスであると認識しておきましょう。
一方で、どれも運用上楽だったり便利だったりするのでそのような設定になっていることが多く、簡単に辞められるものでもなかったりします。これらにおいて、運用効率性とセキュリティ堅牢性のどっちを取るかは、システムの重要度や要件を鑑みて判断することになるでしょう。大事なのはリスクを認識しておき、状況に合わせて判断できるようにしておくことです。
IDS/IPSによる侵入検知/防御
IDSは侵入検知システムと略され、コンピュータやネットワークに対しての不正侵入の検知を目的とするセキュリティ装置です。似たような言葉でIPSというものがありますが、IPSは侵入防御システムと呼ばれ、IDSでは検知するだけであるのに対し、IPSは不正攻撃として検知した場合は防御まで自動で行います。
ファイアウォールと何が違うのかというと、ファイアウォールのパケットフィルタリングだけでは防げない、「IP・ポートレベルでは許可扱いとされてしまう攻撃」を検知することできます。
例えば、外部向けに公開しているWebアプリケーションの場合、送信元IPアドレスは特定できないので、ファイアウォールでは「送信元IPアドレス：Any、宛先ポート：tcp443」等で許可します。ここに誰かがDoS攻撃をした場合、ファイアウォール的には許可されてしまいますよね。これに対しIDS/IPSでは「同じ送信元から●秒間に▲回アクセスされたら攻撃とみなす」みたいなロジックで検知を行います（IPSならブロックまでします）。
このご時世、ファイアウォールでは防御しきれない攻撃が溢れていますので、Webシステム等の外部に公開するシステムにおいてはIDS/IPSは必須です。ただし、検討不十分で入れてしまうとうまく活用できず、宝の持ち腐れどころか、業務やサービスに影響する可能性もあります。
例えば以下のようなパターンです。
検知精度が悪く、不正アクセスなのに検知できなかったり、正常アクセスなのに防御してしまう（誤防御）
そもそもチューニングがあまりできない（例：DoS攻撃の検知基準は”10秒間に100アクセス以上”で固定で、そこから変えられない）
本来攻撃したかった攻撃が検知できない（DDoS攻撃やSQLインジェクション等はIDS/IPSでも検知できるものは限られている）
クラウド型/アプライアンス型の比較的最新で高価なIDS/IPSを使っていればこのようなことはあまりないですが、比較的古いものや、ファイアウォールやルーターにIDS/IPS機能がちょっとついている程度のものを使っていると珍しくないことです。
IDS/IPSの導入や改善をする際には、費用の他に
どんな攻撃までカバーする必要があるか？（DDoS攻撃や、L7レベルの攻撃もIDS/IPSで対応する必要があるか）
検知閾値のチューニングは可能か？（どのレベルで可能か？）
サポート体制はどうか？（特にセキュリティ専門知識を持つエンジニアがいない場合は気にすべき）
といったあたりを押さえておくと有効活用できる可能性が上がります。
VPN機器のセキュリティ対策は万全に！
VPN（Virtual Private Network）は、インターネットのような不特定多数が利用するネットワーク上に、仮想的な専用線をつくる技術です。通信内容を暗号化することで、途中で誰かに盗聴されても中身を解読されないようにします。
特にコロナ禍によるリモートワーク普及のタイミングでVPNは出番が増えましたが、それと同時にVPN機器が感染経路となるセキュリティ事故が増加しています。警察庁の「令和６年におけるサイバー空間をめぐる脅威の情勢等について」の「ランサムウェアの被害に関する統計②」によると、ランサムウェア被害にあった企業の感染経路の5割以上がVPN機器ということが分かっています。
VPN機器から攻撃が成功するパターンとして、主に以下の2つがあります。
VPN機器のID/パスワード等が非常に安易である、不必要なアカウントがきちんと管理されずに存在している等の理由で、認証を突破される
VPN機器の脆弱性を利用し、認証を回避して不正ログインする
つまり、VPN機器を使っている場合、脆弱性に対する早急な対応と認証の強化が必須です。以下のような対策をしておきましょう。
VPN機器のログインパスワードは、英数字や記号などを交えた複雑で長いものを利用する
多要素認証機能がついている場合は活用する
脆弱性が発見された場合、リアルタイムに検知できる仕組みを作る（公式ベンダーからの通知のサブスクリプション、セキュリティベンダーからの通知サービス、RSS、Googleアラート等）
本当の意味でセキュアなプロトコルを使う
みなさんは「セキュアプロトコル」と言われてピンと来ますか？あまり普段の業務で直接この呼び名を使うことは少ない気がしますが、通信の機密性や完全性の確保をするための機能を持つプロトコルのことをこのような名前で呼ぶことがあります。例えば暗号化プロトコルでいうとHTTPSやTLS、WPA等が該当し、それ以外だと認証/認可のためのプロトコルであるKerberosやSAML、鍵交換プロトコルのDHやECDH等も該当します。
セキュアプロトコルを利用する上で注意するべきなのは2点です。
比較的新しく、安全性が高いプロトコル/バージョンを選定する
その中で、クライアント-サーバーの両者が対応しているものを確認する
セキュアプロトコルを使う上で知っておくべきなのは、「セキュアプロトコルであれば安全」というのは勘違いである、ということです。セキュアプロトコルでも、脆弱性が見つかっているものや、攻撃の技術の進化に伴って安全ではなくなってしまったものがあります。
例えば無線LANにおける代表的なセキュリティ規格としてWPAがあります。WPAは数年前までは「WEPに代わる安全性の高いプロトコル」という扱いでしたが、近年ではWPAでも解読される危険性があるので後継のWPA2を使うべきだとされており、もっというとWPA2も、悪用の可能性は低いものの、KRACKsという脆弱性が見つかっているため、WPA3を積極的に利用すべきだという声があります。
その他にも公開鍵暗号方式であるRSAでは、鍵の長さを選択して作成することができますが、1024bit以下のものはコンピュータの進歩によって解読されるリスクがあるので非推奨とされています。
そのため、「セキュアプロトコルを使っていればOK」という認識ではNGで、「ちゃんと今の時代も安全性の高い、新しいプロトコル/バージョンを使っているか？」という視点で設計/実装していく必要があります。
では最新のものさえ使っていればOKか？というとそういうわけでもありません。なぜかというと、相手が対応していないリスクがあるためです。例えば筆者がロードバランサーの更改を担当していた時、移行リハーサルの際にとある顧客端末からの通信がエラーになり、原因を調べたところ「ロードバランサー側のバージョン変更に伴い、古くて脆弱なTLS暗号化スイートが選択でいなくなった。しかし、エラーになった顧客端末ではそのTLS暗号化スイートを使っていたため、通信が出来ずエラーになった」とわかりました。
つまり、「自分とやり取りをする相手の双方がサポートしている中で、比較的最新かつ安全なプロトコル/バージョンを利用する」というのが、セキュアプロトコルを使う上でのポイントになります。
ネットワーク機器や通信のログは重要なものに絞って取得
ここまでは、攻撃や侵入をされる前、いわゆる「事前対策」「予防的統制」と言われる部分の対策を紹介してきましたが、最後は万が一攻撃をされてしまった後に備えての対策、「ログの取得」です。
攻撃や不正アクセスを受けた場合の証跡としてログは非常に重要な位置づけですが、それはシステムが直接動いているサーバーだけではなく、経路上にあるネットワーク機器においても同様です。
特に重要度が高いのは、以下のようなログです。
ネットワーク機器自体への管理アクセスログ： 先ほども触れたVPN機器のように、ネットワーク機器に侵入することから攻撃が始まるケースも多々あります。本番作業をしていない時間に管理者ユーザーのアクセスログが出た場合にアラート通知する仕組みを作れば、こうした攻撃を早期に検知することが出来ます。
重要度の高い設定変更のログ： 攻撃者がネットワーク機器の認証を突破して管理者権限でログインできた場合、何をするかというと、VPNやパケットフィルタリング等の設定を変えて攻撃者が侵入できるようにします。つまり、これらの設定を変えたログを収集/監視することで、攻撃を検知したり、後から証跡として活用したりできる場合があります。（とはいえ、管理者権限まで取られていると、ログも改ざんされたり出力しない設定にされたりしてしまうことも多々ありますが...）
通信の許可/拒否のログ： ネットワーク機器本体のログだけではなく、通信を許可/拒否した際のログを取っておくことが攻撃の情報を押さえるうえで非常に役立ちます。大量に出力されている拒否のログから攻撃の時間帯を把握したり、攻撃元のＩＰアドレスに絞って個別の拒否設定を入れたりといった活用方法が考えられます。ただし、あまり大量にログを出すと見づらくなるだけでなく、機器本体への負荷がかかってパフォーマンスに影響が出るリスクも出るので、拒否のログを取るのはインターネットからのインバウンドだけに絞るなどの取捨選択は必要です。
欲を言えば、通信の中身自体を見られるパケットキャプチャを取っておくのも攻撃対策や障害切り分けの観点で非常に有益なことが多いのですが、パケットキャプチャデータというのは容量が大きく、帯域もストレージ量も半端なく食うので、セキュリティとリソース、コストのバランスを考えたうえで導入を慎重に決める必要があります。
前の現場でパケットキャプチャサーバーを入れる話が出たのです、尋常じゃない金額が動くプロジェクトになっていました...＄
セキュリティ事故や攻撃検知のためにどんなログを取るべきか？というのはこだわると奥が深いですが、まずは前述の3点で取得を検討しておけば、はじめの一歩としては十分です。先に述べたように、余分なログを取るとかえってリソース負荷や管理面でマイナスになることも多いので、セキュリティ事故や障害時の調査の時に何が必要か？をイメージして、必要なものに絞って取ることが大事です。
よくある疑問・注意点（Q&A）
Q1: 「基礎」という割には触れてない内容があるような...
A: はい、いくら「ネットワークセキュリティの基礎」といっても、「イマドキほとんどの現場で押さえてないわけないよな...」「ちょっとでもITかじれば自然と知るよね...」というのは省いています。
例えば以下のあたり。
HTTPじゃなくてHTTPS使おうね！
TelnetじゃなくてSSHを使おうね！
オレオレ証明書は開発環境以外では使わないようにね！
Q2: WAFの話はしないんですか？
A: 確かにWAFはネットワークセキュリティに分類しても違和感ないのですが、今回は外しました。というのも、WAFはアプリケーションレイヤの攻撃を対象にしているので、ネットワークエンジニア側で設計/チューニングをするのはハードルが高いからです。
とりあえずWAFのアプライアンスやクラウドサービスを使ってネットワークレベルの設定をすることぐらいはできても、中身の検知ルールを理解して触るというのは、アプリケーションに詳しい人がいないと厳しいことが多いと思います。なのでWAF入れるって話をされた駆け出しネットワークエンジニアは、ちゃんとアプリ側の人を巻き込んで進められるか確認したほうがいいです。私はそれで痛い目を見ました。
今日から実践！
ネットワークセキュリティ基礎のチェックリスト
ファイアウォールによる厳密なIP/ポートアクセス制御
内部→インターネット向けの通信も、必要なものを洗い出して最小限に絞る
内部間の通信もネットワークセグメントレベルではなくホスト（/32）レベルで絞る）
ICMPも必要な送信元・宛先IPアドレスに対してだけ許可する
がベストプラクティスだが、運用/セキュリティ要件のバランスを鑑みて判断する。
IDS/IPSによる侵入検知/防御
IDS/IPS製品を選定/設計するときは以下を考慮する。
どんな攻撃までカバーする必要があるか？（DDoS攻撃や、L7レベルの攻撃もIDS/IPSで対応する必要があるか）
検知閾値のチューニングは可能か？（どのレベルで可能か？）
サポート体制はどうか？（特にセキュリティ専門知識を持つエンジニアがいない場合は気にすべき）
VPN機器のセキュリティ対策は万全に！
VPN機器を担当する場合、以下を満たしているか確認する。
VPN機器のログインパスワードは英数字や記号などを交えた複雑で長いものを利用する
多要素認証機能がついている場合は活用する
脆弱性が発見された場合、リアルタイムに検知できる仕組みを作る（公式ベンダーからの通知のサブスクリプション、セキュリティベンダーからの通知サービス、RSS、Googleアラート等）
本当の意味でセキュアなプロトコルを使う
セキュアプロトコルを使う場合、以下の流れで選定する。
比較的新しく、安全性が高いプロトコル/バージョンを選定する
その中で、クライアントとサーバーの両者がサポートしているものを確認する
ネットワーク機器や通信のログは重要なものに絞って取得
特に以下3点を取得するようにする。
ネットワーク機器自体への管理アクセスログ
重要度の高い設定変更のログ
通信の許可/拒否のログ
まとめ
今回はネットワーク機器におけるセキュリティとして代表的なものを挙げました。ネットワークセキュリティの世界も奥が深いため、記事1本ですべてを語ることはできません。ただ、今回は「さすがにどんな現場/システムでもやってるだろう」というレベルの教科書的なものというよりは、「意外とやってない現場もある」という、ある程度実務で使いそうなものを中心に、まずはここを押さえておけば第一歩として良いだろう、というものをご紹介しました。
この記事がネットワークエンジニアになって日が浅い方にとって、新しい気づきや学びになることを祈っております。お読みいただきありがとうございました！
