MENU

さくらのクラウドのIP制限はどこでやる?PFとOS・アプリ(ミドルウェア)で比較

IP制限サムネイル

皆さんこんにちは!新人のアナサピです!
今回はPFとfirewalldとApacheでIP制御の比較を行いました!
皆さんは「IP制限」と聞くと、何を思い浮かべますか?

  1. さくらのクラウドのパケットフィルタ(PF)
  2. OS(firewalld)
  3. アプリ(Apache)
  4. WAF

等々、色々な方法があります。
ただ、どれも「アクセスを拒否する」という点では同じように見える一方で、「どこで通信を止めているのか」はかなり違います。
実際、制御する場所によって、サーバ負荷やログの残り方、防げる内容まで変わってきます。

今回は、「結局どこでIP制限をするのが良いのか?」をイメージしやすくするために、今回は実際 AlmaLinux + Apache + PHP の環境をさくらのクラウドで用意し、

  • どこで通信が止まるのか
  • CPU負荷はどう変わるのか
  • ログは残るのか

を実際に検証してみました。

結論としては、「どれが正解」というより、“何をどこまで到達させたくないか”などの目的によって使い分けるものだと感じました。
今回はその違いを、実際の負荷テスト結果と一緒に整理していきます。

「そもそもパケットフィルタってなに?」

弊社の社員が分かり易い記事を公開しておりますので、こちらの記事をご覧ください!

目次

今回のポイント

単純な「制限できる / 制限できない」だけでは、今回の3つどれでも制御できますので、比較にはなりません。
そのため今回は、実際に負荷をかけながら、サーバ内部で何が起きているのかも合わせて確認していきます。
今回特に確認したのは以下のポイントです。

  • top
  • tcpdump
  • ログ(access_log)

今回の検証はCPU使用率などが分かりやすくする為に、意図的に重いPHPを設置しております。
あくまでも検証であり、実際はコンテンツの造り方などの環境次第で変わっていきますので、参考程度にご覧ください。

また、今回のポイントを画像にまとめましたので、検証内容をスキップしたい方は こちらから今回のまとめ までスキップできます。

今回の検証環境

スペック

メモリ:2 GB
CPU:2 コア

OS

AlmaLinux 9.7 を使用。

使用したもの

  • Apache(httpd)
  • php-fpm
  • firewalld
  • tcpdump

検証用PHP

今回の検証に必須ではないのですが、CPU負荷を分かりやすくするため、意図的に重いPHPを配置しております。

負荷テスト方法

実際に別のサーバから大量のアクセスを実施しております。
方法については今回の記事とは逸れる為、省略させていただきます。

① 制限なし(ノーガード)

まずは何も制限しない状態です。
※ポートを全開放してしまうと、他のIPからもアクセスできてしまうので、実際はアクセス元のIPのみ許可している状態です。

結果

CPU

topコマンド結果全文

CPUは2コア両方でほぼ100%まで上昇しました。
特に使用率上位に php-fpm が来ております。
意図的に重いPHPを設置しておりますので、当然ではありますが、実際に

HTTP到達

Apache

PHP実行

CPU消費

まで完全に処理が進んでいるのが分かります。

各種確認まとめ

項目状態
CPU非常に高い
tcpdump見える
access_logステータスコード 200

これを基準に各制御方法を確認していきましょう!

IP制限② ApacheでIP制限

次は Apache 側で制御します。

設定

/etc/httpd/conf.d/ipdeny.conf

結果

CPU

topコマンド詳細

先ほどと比べると、かなりユーザー処理が下がっています。
これはApache側で403を返しているため、PHPまで処理がとどいていないことが分かります。
しかし、アクセス自体はApacheまで到達しています。
そのため、access_log にはステータスコード403が記録されています。

つまり、

HTTP到達
↓
Apache
↓
ステータスコード403返却

PHPは実行されない

という状態であることが分かります。

各種確認まとめ

項目状態
CPU少し上昇(30%前後)
tcpdump見える
access_logステータスコード 403

Apache制御のポイント

Apache制御はかなり柔軟です。
例えば、URL単位やディレクトリ単位での制御、Basic認証などのレベルの制御が可能です。
ただし、「Apacheまで到達はしている」のがポイントです。
今回の検証より多くのアクセスがあった場合、CPU使用率などは当然上昇します。

IP制限③ firewalld(OS)でDROP

次はOSレベルです。
今回は firewalld で明示的に DROP しました。

firewalld設定内容

結果

ここでかなり挙動が変わりました。

CPU

これまでの2つの検証と違い、ほとんど0%です。

NIC
↓
Kernel(サーバ)
↓
DROP

Apacheは実行されない

という状態になっていることが分かります。
また、Apacheまで到達していない為、Apacheのアクセスログにも記録されていません。

tcpdumpで確認

Apacheのアクセスログに記録がされないため、tcpdumpというサーバの通信を確認するコマンドで確認します。

実際に記録はされていたので、通信自体が届いていることが確認できます。

各種確認まとめ

項目状態
CPUほぼ使わない
tcpdump記録あり
access_log残らない

IP制限④ さくらのクラウド パケットフィルタ(PF)

最後はクラウド側です。
今回はさくらのクラウドのパケットフィルタで TCP/80 を deny しました。
今回初めて設定したのですが、下記の記事を参考に設定してみました!

結果

CPU

firewalldの時点で、ほぼ使用率0でしたがパケットフィルタはサーバーの外で制御しているため、使用率の変化は見られませんでした。

tcpdumpで確認

先ほどとは異なり、0 packets captured となっております。
つまり、サーバのNICまでHTTP通信が来ていない ということがわかります。

IP制限まとめ

制御箇所Apache到達アクセスログtcpdumpCPU
ノーガード○(200)非常に高い
Apache○(403)少し高い
firewalld××かなり低い
PF×××影響無

今回の検証は比較がしやすいように、IP制限に絞ってCPU使用率を中心に見てきました。
そのため、今回の結果だけを見るとパケットフィルタが一番いいように見えますが、実際は【制御できる範囲】が異なるため、目的にあった用途を選択する必要があります。

特にApacheでの制御は、
「/admin だけ制限したい」
「Basic認証と組み合わせたい」
など、アプリ寄りの細かい制御が得意です。

一方で、DDoSのような大量アクセスや、そもそも通信を通したくないケースでは、より手前で落とせるPFやfirewalldの方が有利になります。
実際の運用されているサーバだと、複数組み合わせて利用することも珍しくありません。

今回の比較結果まとめ

次回の記事について

今回登場した、パケットフィルタ(PF)、firewalld、Apacheの三つは、どちらかというと“サーバに近い層”の話であり、CPU使用率という数字での比較がやりやすかったです。
次回は、今回は敢えて触れてこなかった「制御範囲」という視点から、

「どこで通信を止めると、どこまで到達するのか?」
「WAFとPFは何が違うのか?」
「GSLBやDNSは“防御”なのか?」

といった部分も含めて、外側から内側までのレイヤー構造を整理しながら解説していきたいと思います!

お問い合わせ

この記事をシェアする
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

サービス業からのエンジニア転職。
クラウドに触れながら得た気付きや、初心者からの視点をお届け。
「これから触る人の参考になる情報」をまとめていきます!

【取得資格】
LinuC Level1
さくらのクラウド検定

目次