AWS Network FirewallのSuricata互換を検証してみる

記事タイトルとURLをコピーする

クラウドインテグレーション部の村上です。

今回はAWSのマネージドなネットワーク保護サービスであるAWS Network Firewallについて検証してみました。

AWS Network Firewallのルールグループは5-tuple形式やDomain list形式を使って作成することが多いかと思いますが、今回はSuricata rulesを記載して設定してみたいと思います。

AWS Network Firewallとは

AWS Network Firewallを利用すると、ネットワークトラフィックを詳細まで制御できるファイアウォールルールを定義できます。概念やユースケースについては以下のブログをご覧ください。

blog.serverworks.co.jp

Suricataとは

SuricataはオープンソースなネットワークIDS、IPSサービスです。

Suricata is a high performance Network IDS, IPS and Network Security Monitoring engine. https://suricata.readthedocs.io/en/suricata-6.0.1/what-is-suricata.html

ドキュメントを確認すると、AWS Network FirewallはSuricataと互換性があるとのこと。つまりSuricataを利用している場合や使い慣れている場合は、Suricata rulesを使ってそのままAWS Network Firewallをセットアップできるということです。

今回は以下のような構成で、AWS Network FirewallにSuricata rulesを記載し動作を確認します。

f:id:swx-murakami:20210226083812p:plain

まずはSuricataを使ってみる

まずはAWS Network Firewallを使わず、Suricataがどんな動きをするか確認してみます。

インストールしてsuricata.rulesに以下のようなルールを書いてみます。内容はすべてのTCPパケットに対してアラートを出すというものです。

alert tcp any any -> any any (msg:"TCP traffic detected"; sid:200001; rev:1;)

ClientサーバからcurlでWEBサーバにアクセスした後、ログファイルを確認してみます。以下のようなログが記録されていました。

02/26/2021-09:03:00.557718  [**] [1:200001:1] TCP traffic detected [**] [Classification: (null)] [Priority: 3] {TCP} 54.199.234.1:44466 -> 10.11.0.26:80

ちゃんとClientからのパケットが検知されていますね。

AWS Network FirewallにSuricata rulesを記載してみる

リージョンをバージニア北部に変更

次にAWS Network Firewallを利用します。

といっても東京リージョンではまだ利用できませんのでリージョンを変更します。

ネットワークファイアウォールのルールグループ作成

まずルールグループを作成します。ルールグループはsuricata.rulesに相当するものなので、冒頭と同じSuricata ruleを記載します。

f:id:swx-murakami:20210226184418p:plain

ファイアウォールポリシーを作成

つづいてファイアウォールポリシーを作成します。これはどのルールグループをポリシーに紐づけるか設定するもので、複数のルールグループを紐づけることも可能です。

今回は先ほど設定したルールグループを設定します。

f:id:swx-murakami:20210226185734p:plain

ファイアウォールの作成

ファイアウォールの作成では、どのサブネットにデプロイするか選択します。関連付けるファイアウォールポリシーは先ほど作成したものを設定します。

f:id:swx-murakami:20210226190519p:plain

最後にネットワークの設定

最後に以下2点、ネットワークの設定が必要です。もう一度冒頭の構成図を掲載します。

f:id:swx-murakami:20210226083812p:plain

インバウンド通信がファイアウォールエンドポイントを経由するように設定

通常のインバウンド通信(Client → WEB)はインターネットゲートウェイを通って、宛先のインスタンスに向かいます。これをファイアウォールエンドポイントを経由するよう設定するために、インターネットゲートウェイにルートテーブルを関連付けます。

  • まずルートテーブルを作成して、VPCのネットワークアドレス宛ての通信をすべてVPCエンドポイントに向けます。このVPCエンドポイントはファイアウォールをサブネットにデプロイしたときに作成されます。
  • 次に「アクション」→「Edit edge associations」から、このルートテーブルをインターネットゲートウェイに関連付けます。

f:id:swx-murakami:20210226191933p:plain

これでインバウンド通信がファイアウォールエンドポイントを経由するように設定されました。

アウトバウンド通信がファイアウォールエンドポイントを経由するように設定

これは先ほどと逆で、アウトバウンド通信(WEB → Client)もファイアウォールエンドポイントを経由するよう設定するものです。

  • WEBサーバのあるサブネットのルートテーブルのデフォルトルート0.0.0.0/0をVPCエンドポイントに向ける
  • ファイアウォールのあるサブネットのルートテーブルのデフォルトルート0.0.0.0/0をインターネットゲートウェイに向ける

以上で設定は完了です。

ログを確認

AWS Network FirewallはCloudWatchlogsにログを出力することが可能ですので確認してみます。

{
    "firewall_name": "test",
    "availability_zone": "us-east-1a",
    "event_timestamp": "1614333008",
    "event": {
        "timestamp": "2021-02-26T09:50:08.013550+0000",
        "flow_id": 2018809721390604,
        "event_type": "alert",
        "src_ip": "10.11.0.26",
        "src_port": 80,
        "dest_ip": "54.199.234.1",
        "dest_port": 46000,
        "proto": "TCP",
        "alert": {
            "action": "allowed",
            "signature_id": 200001,
            "rev": 1,
            "signature": "TCP traffic detected",
            "category": "",
            "severity": 3
        }
    }
}

Suricata rulesをコピペしただけですが、ちゃんと設定できているようです。

まとめ

AWS Network Firewallのルールグループは、5-tuple形式やDomain list形式でイチから作成することも可能ですが、すでに運用しているSuricata rulesがあれば、それを使うのが簡単そうですね。

以上です。

村上博哉 (執筆記事の一覧)

2020年4月入社。機械学習が好きです。記事へのご意見など:hiroya.murakami@serverworks.co.jp