セキュリティ対策にCrowdSecを活用｜無料で始める不正アクセス対策の方法

企業のWebサイトや業務システムは、毎日のように世界中から不正アクセスの対象になっています。

「自社は有名企業ではないから狙われない」と考えている担当者もいるかもしれません。

しかし、実際のサイバー攻撃は、特定の企業だけを狙うものばかりではありません。

攻撃者は自動化されたプログラムを使い、インターネット上にある多数のWebサイトやサーバーを機械的に調査しています。

管理画面へのログイン試行、SSHへの不正アクセス、脆弱性の探索、Webサイトへの大量リクエストなどが、自動的に繰り返されています。

このような攻撃への対策として注目されているのが、オープンソースのセキュリティ対策ツール「CrowdSec（クラウドセック）」です。

CrowdSecは、サーバーやWebサービスのログを分析し、攻撃と考えられる不審な行動を検知する仕組みです。

さらに、世界中の利用者から共有された攻撃情報を活用し、すでに悪意のある活動が確認されているIPアドレスを事前に遮断することもできます。

CrowdSecのSecurity EngineとRemediation ComponentsはMITライセンスで提供されており、基本的な仕組みを無料で導入できます。公式ドキュメントでは、Security Engineを軽量で協調型の侵入検知システムと説明しており、必要に応じてWAF機能も追加できます。

ただし、CrowdSecをインストールするだけで、すべてのサイバー攻撃を防げるわけではありません。

CrowdSecが何を検知し、どの仕組みでアクセスを遮断するのかを理解し、サーバー更新、バックアップ、アクセス権限管理などの基本対策と組み合わせることが重要です。

この記事では、CrowdSecの基本的な仕組み、不正アクセス対策に利用できる機能、企業での実践的な活用方法、導入時の注意点を、法人の経営企画担当者やWeb担当者にもわかりやすく解説します。

CrowdSec（クラウドセック）とは？無料で始めるセキュリティ対策を解説

CrowdSecとは、サーバーやWebアプリケーションへの不審なアクセスを検知し、攻撃元への対応を支援するオープンソースのセキュリティ基盤です。

読み方は「クラウドセック」です。

CrowdSec（クラウドセック）のwebサイトです。

名前に「クラウド」と入っていますが、一般的なオンラインストレージサービスではありません。

Linuxサーバー、Webサーバー、コンテナ環境などに導入し、ログを読み取って不審な行動を分析する仕組みです。

CrowdSecの大きな特徴は、単純に危険なIPアドレスの一覧を読み込むだけではなく、自社サーバー内で起きている行動も分析できることです。

例えば、同じIPアドレスから短時間に何度もログインを試みている場合、通常の利用者ではなく、パスワードを総当たりで試す攻撃の可能性があります。

Webサイト内の存在しないページへ大量にアクセスしている場合は、脆弱性のある管理画面やプラグインを探している可能性があります。

CrowdSecのSecurity Engineは、サーバーやアプリケーションのログを取り込み、あらかじめ定義された攻撃パターンに一致する行動を検知します。

公式ドキュメントでは、攻撃パターンを「Scenarios」と呼び、ログを読み取るための設定や検知ルールをまとめたものを「Collections」と呼んでいます。Collectionsには、NGINX、SSH、WordPress、一般的なHTTP攻撃など、サービスや用途ごとの設定がまとめられています。

わかりやすく言えば、CrowdSecはサーバーの監視員のような存在です。

サーバーに残されたアクセス記録を確認し、通常とは異なる動きを見つけます。

ただし、Security Engineだけでは、必ずしも攻撃元を自動的に遮断できません。

CrowdSecでは、攻撃を検知する仕組みと、実際に通信を止める仕組みが分かれています。

攻撃を検知するのがSecurity Engineです。

検知結果を受け取り、ファイアウォール、Webサーバー、リバースプロキシなどで通信を止めるのがRemediation Componentです。

以前は「Bouncer」と呼ばれており、現在の公式ドキュメントでも補足としてこの名称が使われています。

公式のトラブルシューティングでは、Remediation Componentが接続されていないSecurity Engineは攻撃を検知できても、攻撃者を実際には遮断できないと説明されています。

CrowdSecには、世界中の利用者から集められた攻撃情報を活用する仕組みもあります。

参加しているサーバーから共有された攻撃シグナルを集約し、悪意のある活動が確認されたIPアドレスを整理します。

利用者はCommunity Blocklistなどを通じて、その情報を防御へ利用できます。

つまり、自社のサーバーが攻撃を受けてから対処するだけではありません。

他の利用者に対して攻撃を行っているIPアドレスを事前に知り、自社へ到達した段階で遮断できる可能性があります。

Community Blocklistは、CrowdSecが悪意のあるIPアドレスとして整理したリストで、既知の攻撃元からの接続を事前に防ぐために利用されます。Community版では、一定数の無料ブロックリストを利用できます。

CrowdSecは無料で始められますが、「完全に費用がかからない」とは限りません。

導入作業、設定、監視、障害対応、ログ確認などには、担当者の時間が必要です。

また、より多くのブロックリストや企業向け機能を利用する場合は、有料プランも選択肢になります。

経営企画やWeb担当者は、ソフトウェアの利用料金だけでなく、運用に必要な人材と時間も含めて導入を判断することが大切です。

長い詳細は読みたくないけど、気になる方はお問い合わせください。

CrowdSecでできる不正アクセス対策と主な機能を徹底紹介

CrowdSecでできることを理解するには、「検知」「判断」「遮断」という3つの段階に分けて考えるとわかりやすくなります。

最初の段階は、サーバーやWebアプリケーションのログを読み取ることです。

ログとは、サーバー上で何が起きたかを記録した履歴です。

Webサーバーのログには、どのIPアドレスが、いつ、どのページへアクセスしたかなどが記録されています。

SSHのログには、サーバーへのログインが成功したか、失敗したかなどが記録されます。

CrowdSecは、このようなログを読み取り、不審な行動が発生していないかを分析します。

例えば、SSHへ短時間に何度もログインを試みる行動があります。

これは、よく利用されるパスワードを次々に試し、管理者権限を奪おうとするブルートフォース攻撃の可能性があります。

WordPressのログイン画面に対して、同じIPアドレスから大量のログイン試行が発生する場合も同様です。

また、存在しない管理画面、古いプラグインのファイル、設定ファイルなどへ繰り返しアクセスする行動は、脆弱性を探している可能性があります。

CrowdSecでは、こうした行動パターンをScenarioによって判断します。

単純に1回アクセスしただけで攻撃と決めつけるのではなく、一定時間内の回数やアクセス内容などを組み合わせて評価します。

これにより、通常の利用者と自動攻撃ツールを区別しやすくなります。

公式のCrowdSec Hubには、Parser、Scenario、Collectionなどの設定が用意されています。

Parserはログの内容をCrowdSecが理解できる形へ整理します。

Scenarioは、整理された情報をもとに攻撃行動を判定します。

Collectionは、特定のサービスを守るために必要な設定をまとめたものです。

ゼロから検知ルールを作らなくても、SSH、NGINX、Apache、WordPressなど、利用環境に合ったCollectionを導入できます。

検知した攻撃元を実際に止めるためには、Remediation Componentを使用します。

例えば、ファイアウォール向けのRemediation Componentを利用すると、危険と判断されたIPアドレスからの通信をネットワークに近い場所で遮断できます。

SSH、データベース、メールサーバーなど、Web以外のサービスを守る場合にも利用しやすい方法です。

公式ドキュメントでは、Firewall Remediation ComponentはSSH、データベース、SMTPなどの基盤サービスを守る用途に適していると説明されています。

Webアプリケーションを守る場合は、NGINX、OpenResty、Traefik、HAProxyなどに対応するWAF機能付きのRemediation Componentを利用できます。

WAFとは、Web Application Firewallの略です。

WebサイトやWebアプリケーションへ送られる通信内容を確認し、SQLインジェクション、クロスサイトスクリプティング、既知の脆弱性を狙った通信などを防ぐ仕組みです。

CrowdSecのAppSec Componentは、Webサーバーやリバースプロキシと連携し、HTTPリクエストを確認します。

公式ドキュメントでは、WAF対応のRemediation Componentにより、リアルタイムのHTTP検査、仮想パッチ、SQLインジェクションやXSS、既知の脆弱性を悪用する攻撃への防御が可能と案内されています。

仮想パッチとは、Webアプリケーション自体の修正が完了するまで、外側の防御ルールによって攻撃通信を止める考え方です。

もちろん、本体の更新を行わなくてよいという意味ではありません。

WordPress本体、テーマ、プラグイン、サーバーソフトウェアは、可能な限り速やかに更新する必要があります。

仮想パッチは、更新までの時間を補う追加対策として考えるべきです。

さらに、CrowdSecではCommunity Blocklistを利用できます。

自社のログでまだ攻撃を検知していなくても、CrowdSecのネットワーク内ですでに攻撃活動が確認されたIPアドレスを事前に遮断できます。

これは、各企業が個別に攻撃へ対応するだけではなく、参加者同士の情報を防御へ活かす仕組みです。

ただし、IPアドレスだけですべての攻撃者を判断できるわけではありません。

攻撃者はIPアドレスを変更したり、一般利用者と同じクラウドサービスを悪用したりすることがあります。

そのため、ブロックリスト、行動分析、WAF、認証強化などを組み合わせることが重要です。

CrowdSecを活用した企業向けセキュリティ対策の実践方法

企業がCrowdSecを導入するときは、いきなりすべてのサーバーへ設定するのではなく、守る対象と目的を明確にすることが重要です。

最初に整理したいのは、自社が保有しているインターネット上の資産です。

コーポレートサイト、採用サイト、ECサイト、会員サイト、業務システム、APIサーバー、メールサーバー、VPN、SSH接続口などを書き出します。

その中から、外部公開されているもの、個人情報を扱うもの、停止すると業務へ大きな影響が出るものを優先します。

例えば、会社案内を掲載するだけのWebサイトと、顧客情報を扱う会員サイトでは、事故が起きた場合の影響が異なります。

すべてを同じレベルで守ろうとすると、予算や人員が不足します。

重要度に応じて優先順位を決めることが、現実的なセキュリティ対策につながります。

次に、CrowdSecが読み取るログを決めます。

SSHへの不正ログインを防ぎたい場合は、認証ログを監視します。

Webサイトへの攻撃を確認したい場合は、NGINXやApacheなどのアクセスログを監視します。

WordPressを守りたい場合は、Webサーバーのログに加えて、WordPress向けCollectionやRemediation Componentの利用を検討します。

CrowdSecはログに記録された情報をもとに判断するため、必要なログが出力されていなければ、正しく分析できません。

導入前に、ログの保存場所、形式、保存期間、容量を確認しましょう。

そのうえで、利用しているサービスに合ったCollectionを導入します。

例えば、SSHを利用しているならSSH向け、NGINXを利用しているならNGINX向けのCollectionを設定します。

必要のないCollectionを大量に導入すると、管理が複雑になり、誤検知の原因を特定しにくくなります。

最初は保護対象を絞り、動作を確認しながら範囲を広げる方法がおすすめです。

次に、検知した攻撃をどこで遮断するかを決めます。

サーバー全体への接続を止める場合は、Firewall Remediation Componentが選択肢になります。

Web通信の内容を確認して対応したい場合は、NGINX、Traefik、HAProxyなどに対応するWAF機能付きの構成を検討します。

Cloudflareなどの外部サービスと連携し、サーバーへ到達する前に遮断する構成もあります。

CrowdSecは、一台のサーバーへすべてを導入する構成だけではありません。

複数のサーバーからログを集め、中央で分析する構成や、Kubernetes、Dockerなどの環境にも対応できます。

公式ドキュメントでは、単一サーバー、複数サーバー、集中ログ管理、Kubernetes、コンテナ、WAF専用など、複数の導入方式が案内されています。

導入時には、最初から自動遮断を強く設定しすぎないことも重要です。

正常な利用者を誤って攻撃者と判断すると、顧客がWebサイトを閲覧できなくなったり、社員が管理画面へ入れなくなったりする可能性があります。

最初は検知結果を確認し、どのようなIPアドレスが、どの理由で対象になっているかを調べます。

問題がないことを確認してから、自動遮断の範囲を広げましょう。

社内や保守会社が利用する固定IPアドレスは、必要に応じて許可リストへ登録します。

ただし、許可リストを広げすぎると、その接続元が悪用されたときに検知できなくなります。

許可する対象は最小限にとどめ、定期的に見直す必要があります。

また、CrowdSecの導入と同時に、OS、Webサーバー、CMS、プラグインの更新状況も確認しましょう。

古いサーバー環境では、CrowdSecを追加するより、サーバー自体を移行した方が安全性と運用コストを改善できる場合があります。

WordPressの表示速度、保守性、セキュリティに不安がある場合は、wordpress サーバー 移行 | セキュリティ改善 コスト削減 へのように、サーバー環境全体を見直すことも有効です。

CrowdSecは古いシステムを安全な状態へ変える魔法の道具ではありません。

安全なサーバー構成を作ったうえで、攻撃の検知と遮断を強化する追加対策として活用しましょう。

CrowdSecを導入するメリット・デメリットと注意点とは

CrowdSecを企業が導入する最大のメリットは、オープンソースの仕組みを利用しながら、不正アクセスの検知と遮断を強化できることです。

Security Engineと主要なRemediation ComponentsはMITライセンスで提供されており、ソフトウェア自体は無料で利用できます。

中小企業では、高額なセキュリティ製品をすべてのサーバーへ導入するのが難しい場合があります。

CrowdSecであれば、小規模な環境から試し、必要に応じて対象を広げられます。

また、利用しているWebサーバーやサービスに合わせてCollectionを選べるため、自社環境に必要な検知機能を追加しやすい点もメリットです。

世界中から共有された攻撃情報を利用できることも大きな特徴です。

自社だけのログを分析する場合、実際に攻撃を受けて初めて危険なIPアドレスを認識することがあります。

CrowdSecのブロックリストを活用すれば、他の環境で悪意のある活動が確認された接続元を事前に遮断できる可能性があります。

Community版では利用できるブロックリスト数に制限がありますが、無料の範囲から試すことができます。

公式ドキュメントでは、Communityプランで利用できるブロックリスト数に上限があることが案内されています。

管理画面を通じて、複数のSecurity Engine、ブロックリスト、攻撃情報をまとめて確認できることも、運用上の利点です。

複数のWebサイトやサーバーを管理している企業では、一台ずつログを確認するより、状況を集約した方が異常を把握しやすくなります。

一方で、CrowdSecにはデメリットもあります。

まず、導入と運用に一定の技術知識が必要です。

Linux、ログ、ファイアウォール、Webサーバー、ネットワークなどの基本知識がなければ、適切な設定が難しい場合があります。

誤った設定を行うと、攻撃を検知しているだけで遮断できていなかったり、正常な顧客の通信を止めたりする可能性があります。

特に注意したいのが、Security EngineとRemediation Componentの違いです。

Security Engineをインストールしただけで安心してしまうと、攻撃を記録しているだけで、実際には通信を止めていない可能性があります。

導入後は、検知だけでなく、遮断まで正しく動作していることをテストする必要があります。

また、CrowdSecだけですべての攻撃を防ぐことはできません。

CrowdSecは、ログやHTTPリクエストから確認できる不審な行動の検知を得意としています。

しかし、社員がフィッシングメールにだまされてパスワードを入力した場合や、管理者のパソコンがウイルスへ感染した場合までは、CrowdSecだけでは解決できません。

ソフトウェアの脆弱性、内部不正、認証情報の流出、設定ミスなど、サイバー事故の原因は多岐にわたります。

多要素認証、定期バックアップ、権限管理、社員教育、脆弱性対応などと組み合わせることが必要です。

誤検知への対応も考えておかなければなりません。

例えば、社内システムが短時間に多数のリクエストを送った場合、攻撃と似た動きに見えることがあります。

検索エンジンのクローラー、監視サービス、外部連携システムなどが対象になる可能性もあります。

誤検知が起きたときに、誰がログを確認し、誰が遮断を解除するのかを決めておきましょう。

経営企画担当者は、無料という言葉だけで判断せず、構築費、保守費、監視工数、障害対応まで含めた運用コストを確認する必要があります。

社内に技術者がいない場合は、CrowdSecに詳しいサーバー管理会社やセキュリティ事業者へ相談する方が、結果として安全で効率的な場合もあります。

CrowdSecをWebサーバーやシステム運用へ活かすポイント

CrowdSecをWebサーバーや業務システムの運用へ活かすには、導入した後の監視と改善が重要です。

セキュリティツールは、インストールした時点で完成するものではありません。

Webサイトの構成、利用するソフトウェア、攻撃手法は常に変化します。

CrowdSecの設定も、環境の変化に合わせて見直す必要があります。

最初のポイントは、守る対象に合った構成を選ぶことです。

SSHやデータベースなど、サーバー基盤への不正接続を防ぎたい場合は、Firewall Remediation Componentが適しています。

一方で、WordPress、ECサイト、会員サイトなど、Webアプリケーションへの攻撃を防ぎたい場合は、WAF機能に対応した構成を検討します。

公式ドキュメントでは、WebアプリケーションにはNGINX、OpenResty、Traefik、HAProxyなどのWAF対応Remediation Componentを利用し、SSHやSMTPなどにはFirewall Remediation Componentを利用する考え方が示されています。

WordPressでは、CrowdSecの公式ドキュメントに、専用プラグインとAppSec Componentを組み合わせる構成が紹介されています。

この構成では、悪意のあるIPアドレスに関する判断だけでなく、WordPressへ送信されるHTTPリクエストをAppSec Componentで確認できます。

ただし、WordPress管理画面へプラグインを追加するだけでは、すべての機能が自動的に有効になるとは限りません。

Security Engine、認証用のAPIキー、AppSec Componentなどを正しく設定する必要があります。

次に重要なのが、導入後の動作確認です。

CrowdSecのプロセスが起動しているか。

必要なログを読み取れているか。

Collectionが正しく読み込まれているか。

攻撃を想定したテストで検知できるか。

Remediation Componentが判断を受け取り、通信を止められるか。

これらを順番に確認します。

管理画面に接続されているからといって、ログ分析や遮断が正しく動いているとは限りません。

設定変更後やサーバー移行後にも、必ず再確認しましょう。

また、検知件数だけを見て安全性を判断しないことも重要です。

攻撃を100件検知したから危険、0件だから安全とは限りません。

ログが正しく読み込まれていないため、0件になっている可能性があります。

反対に、正常な自動処理を大量に検知し、件数が増えている可能性もあります。

どのScenarioで、どの接続元が、どのサービスを対象に検知されたのかまで確認する必要があります。

月に一度は、検知件数、遮断件数、主な攻撃方法、対象となったサービス、誤検知、設定変更の有無を確認するとよいでしょう。

重要なシステムでは、毎日またはリアルタイムに近い監視体制が必要な場合もあります。

監視頻度は、システムの重要度と事故発生時の影響に応じて決めます。

CrowdSecのHubやCollectionも定期的に更新します。

新しい攻撃パターンや脆弱性へ対応するため、検知ルールや仮想パッチが追加される場合があります。

ただし、本番環境へ自動更新を適用すると、予期しない動作が起きる可能性もあります。

可能であれば検証環境で確認してから本番へ反映しましょう。

さらに、CrowdSecのログや通知を、既存の監視システムへ連携することも有効です。

メール、チャット、監視ダッシュボードなどへ重要な検知情報を送れば、担当者が異常へ気づきやすくなります。

ただし、すべての検知を通知すると、通知が多すぎて重要な異常を見落とす「アラート疲れ」が起きます。

危険度、対象システム、検知回数などに応じて通知条件を整理しましょう。

CrowdSecを活用する目的は、攻撃件数を眺めることではありません。

重要なサービスを止めず、顧客情報や企業情報を守り、事故が起きた場合に早く対応できる状態を作ることです。

Web担当者だけに任せるのではなく、経営者、経営企画、システム担当者、保守会社が役割を共有することが重要です。

よくある質問と回答 Q&A

Q. CrowdSecは無料で利用できますか？

A. CrowdSecのSecurity Engineと主要なRemediation Componentsは、オープンソースのMITライセンスで提供されています。そのため、基本的な検知と遮断の仕組みは無料で導入できます。ただし、企業向け機能、追加の脅威情報、利用できるブロックリスト数などによって、有料プランが必要になる場合があります。また、導入や保守を外部へ依頼する場合は、作業費が発生します。

Q. CrowdSecをインストールするだけで攻撃を防げますか？

A. インストールしただけでは十分ではありません。Security Engineは攻撃の検知を担当しますが、通信を実際に遮断するにはRemediation Componentが必要です。検知、判断、遮断の各機能が正しく接続されているかを確認してください。

Q. CrowdSecとファイアウォールの違いは何ですか？

A. 一般的なファイアウォールは、通信元、通信先、ポート番号などの条件に基づいて接続を許可または拒否します。CrowdSecはログやアクセス行動を分析し、不審な接続元を判断します。その判断結果をファイアウォール向けRemediation Componentへ渡すことで、動的な遮断ができます。

Q. CrowdSecとWAFは同じものですか？

A. 完全に同じではありません。CrowdSecのSecurity Engineは、ログをもとに不審な行動を検知します。AppSec ComponentとWAF対応のRemediation Componentを組み合わせることで、Webリクエストの内容を確認し、SQLインジェクション、XSS、既知の脆弱性を狙う攻撃などへ対応できます。

Q. WordPressにもCrowdSecを導入できますか？

A. 導入できます。CrowdSecにはWordPress向けのRemediation ComponentとAppSecの設定方法が用意されています。ただし、共有レンタルサーバーでは、Security Engineのインストールやサーバー設定を自由に変更できない場合があります。利用中のサーバー会社へ確認してください。

Q. レンタルサーバーでも利用できますか？

A. サーバーの契約内容によります。VPS、クラウドサーバー、専用サーバーなど、管理者権限を利用できる環境では導入しやすくなります。一般的な共有レンタルサーバーでは、必要なソフトウェアをインストールできない可能性があります。

Q. CrowdSecはWindowsでも利用できますか？

A. 公式ドキュメントにはWindows向けの導入方法が用意されており、IIS向けCollectionの設定も案内されています。ただし、Linux環境と設定方法が異なるため、対象となるログやRemediation Componentの対応状況を確認してください。

Q. 正常な利用者を誤って遮断することはありますか？

A. 可能性はあります。短時間に大量のリクエストを送る社内ツール、監視サービス、検索エンジンのクローラーなどが、不審な行動として検知される場合があります。導入初期は検知内容を確認し、必要に応じてルールや許可リストを調整しましょう。

Q. CrowdSecを導入すればウイルス対策は不要ですか？

A. 不要にはなりません。CrowdSecは、サーバーやWebサービスに対する不審な通信の検知と遮断を支援する仕組みです。パソコンのウイルス対策、メールのフィッシング対策、社員教育、多要素認証、バックアップなどは別に必要です。

Q. CrowdSecの運用は誰が担当するべきですか？

A. Linux、Webサーバー、ネットワーク、ログ管理の知識を持つ担当者が適しています。社内に専門担当者がいない場合は、サーバー保守会社やセキュリティ事業者へ依頼する方法があります。導入後の監視、誤検知対応、更新作業まで含めて担当者を決めましょう。

CrowdSecを活用方法｜不正アクセス対策 まとめ

CrowdSecは、サーバーやWebアプリケーションのログを分析し、不正アクセスや攻撃と考えられる行動を検知するオープンソースのセキュリティ対策ツールです。

Security Engineが攻撃を検知し、Remediation ComponentがファイアウォールやWebサーバーなどと連携して、危険な通信を遮断します。

SSHへのブルートフォース攻撃、WordPress管理画面への不正ログイン、Webサイトの脆弱性を探すアクセスなど、さまざまな攻撃への対策に活用できます。

さらに、世界中の利用者から共有された攻撃情報をもとにしたCommunity Blocklistを利用することで、自社でまだ検知していない既知の攻撃元を事前に遮断できる可能性があります。

CrowdSecを活用するポイントは、インストールすることではありません。

自社が守るべきWebサイトやシステムを整理し、必要なログ、Collection、Remediation Componentを正しく組み合わせることが重要です。

また、CrowdSecを導入しただけで、すべてのセキュリティ対策が完了するわけではありません。

OSやWordPressの更新、多要素認証、バックアップ、アクセス権限の管理、社員教育など、基本的なセキュリティ対策と組み合わせる必要があります。

古いサーバーや管理されていないWordPress環境を利用している場合は、CrowdSecの追加だけではなく、サーバー移行や運用体制の見直しも検討しましょう。

法人の経営企画担当者やWeb担当者は、無料で利用できるという理由だけで導入を判断するのではなく、設定、監視、誤検知対応、障害対応を含めた運用体制を確認することが大切です。

CrowdSecを正しく導入し、継続的に検知結果と設定を見直すことで、Webサイトや業務システムへの不正アクセスを減らし、企業の情報資産を守るための有効な防御策となるでしょう。

#CrowdSec #クラウドセック #セキュリティ対策 #サイバーセキュリティ #不正アクセス対策 #サーバーセキュリティ #WordPressセキュリティ #WordPress #Webセキュリティ #WAF #ファイアウォール #ブルートフォース攻撃 #オープンソース #脆弱性対策 #サーバー運用 #Web担当者 #経営企画 #中小企業DX