ALBへのアクセスを特定のHostヘッダのみに限定する方法の一例

ALBへのIPアドレス直指定や意図していないドメイン(Hostヘッダ)でのアクセスを禁止する方法を考えてみます。一例として、ALBのリスナールルーでHostヘッダをチェックする方法を試してみました。シンプルに実現ができるかなと思います。
2021.10.31

はじめに

清水です。AWSのHTTP/HTTPS向けLoad BalancingサービスであるALB (Application Load Balancer)ではリソース(Load Balancer)ごとにDNS名が割り振られます。使用の際にはこのDNS名を独自ドメインに割り当てて使用することが多いかと思いますが、特に設定をしない場合だと独自ドメイン以外でもDNS名や、それを名前解決したIPアドレスでALBにアクセスが可能です。独自ドメイン、つまりアクセスする際のHostヘッダの内容によってこのアクセスを制限する方法については、例えばAWS WAFを使ったり、バックエンドのEC2側でHostヘッダをチェックしたりといくつか方法が考えられます。今回は今回はALB機能のみを使用して実現することを考えてみました。具体的には、ALBのHostベースルーティング機能と固定レスポンス機能を組み合わせ、意図したHostヘッダの場合のみ背後のEC2にルーティング、それ以外は固定レスポンスを返す方法で実現をしています。

ALBはIPアドレス直でもアクセス可能

まずはALBデフォルトの動作を確認しておきます。ALBはHTTP:80とHTTPS:443でリスンするように設定、HTTPS:443には「www.example.net」用のACM証明書を設定してあります。またRoute 53で「www.example.net」に対してA ALIASレコードで、このALBのDNS名「test-alb-1234567890.ap-northeast-1.elb.amazonaws.com」を設定してある状態です。リスナールールは特に指定していないため、すべてのリクエストが背後のEC2にルーティングされる状態です。背後のEC2ではApache+PHPを動作させています。

独自ドメイン名へのアクセスは当然、意図通り行えます。

$ curl -i http://www.example.net/
HTTP/1.1 200 OK
Date: Sun, 31 Oct 2021 09:05:53 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 16
Connection: keep-alive
Server: Apache/2.4.51 () PHP/5.4.16
Upgrade: h2,h2c
Last-Modified: Sun, 31 Oct 2021 08:56:43 GMT
ETag: "10-5cfa23d50774f"
Accept-Ranges: bytes

www.example.net
$ curl -i https://www.example.net/
HTTP/2 200
date: Sun, 31 Oct 2021 09:05:57 GMT
content-type: text/html; charset=UTF-8
content-length: 16
server: Apache/2.4.51 () PHP/5.4.16
last-modified: Sun, 31 Oct 2021 08:56:43 GMT
etag: "10-5cfa23d50774f"
accept-ranges: bytes

www.example.net

ALBへのDNS名へのアクセスも可能です。HTTPSについては証明書関連のエラーが表れますが、これを-kオプションなどで無視すればアクセスは可能となります。

$ curl -i http://test-alb-1234567890.ap-northeast-1.elb.amazonaws.com/
HTTP/1.1 200 OK
Date: Sun, 31 Oct 2021 09:06:54 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 16
Connection: keep-alive
Server: Apache/2.4.51 () PHP/5.4.16
Upgrade: h2,h2c
Last-Modified: Sun, 31 Oct 2021 08:56:43 GMT
ETag: "10-5cfa23d50774f"
Accept-Ranges: bytes

www.example.net
$ curl -i https://test-alb-1234567890.ap-northeast-
1.elb.amazonaws.com/
curl: (60) SSL: no alternative certificate subject name matches target host name 'test-alb-1234567890.ap-northeast-1.elb.amazonaws.com'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

$ curl -i -k https://test-alb-1234567890.ap-northea
st-1.elb.amazonaws.com/
HTTP/2 200
date: Sun, 31 Oct 2021 09:07:43 GMT
content-type: text/html; charset=UTF-8
content-length: 16
server: Apache/2.4.51 () PHP/5.4.16
last-modified: Sun, 31 Oct 2021 08:56:43 GMT
etag: "10-5cfa23d50774f"
accept-ranges: bytes

www.example.net

IPアドレス直指定の場合も確認してみます。こちらもDNS名のときと同様、HTTPSの場合は証明書関連のエラーが出ますが、これを無視してしまえばアクセス自体は可能です。

$ dig test-alb-1234567890.ap-northeast-1.elb.amazonaws.com +short
52.XXX.XX.180
52.XXX.XXX.161
$ curl -i http://52.XXX.XX.180/
HTTP/1.1 200 OK
Date: Sun, 31 Oct 2021 09:09:22 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 16
Connection: keep-alive
Server: Apache/2.4.51 () PHP/5.4.16
Upgrade: h2,h2c
Last-Modified: Sun, 31 Oct 2021 08:56:43 GMT
ETag: "10-5cfa23d50774f"
Accept-Ranges: bytes

www.example.net
$ curl -i https://52.XXX.XX.180/
curl: (60) SSL: no alternative certificate subject name matches target host name '52.XXX.XX.180'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

$ curl -i -k https://52.XXX.XX.180/
HTTP/2 200
date: Sun, 31 Oct 2021 09:09:29 GMT
content-type: text/html; charset=UTF-8
content-length: 16
server: Apache/2.4.51 () PHP/5.4.16
last-modified: Sun, 31 Oct 2021 08:56:43 GMT
etag: "10-5cfa23d50774f"
accept-ranges: bytes

www.example.net

ALBへのIPアドレス直指定のアクセスをどう捉えるか

ALBへのIPアドレス直接指定でのアクセスについて考えてみます。ALBのIPアドレスは可変であり、そのうち変わる可能性が高いです。しかし変わるということは、昔どこかの誰かが使用していたIPアドレスがALBにたまたま関連付く可能性もあるわけです。このことからも、意図せずIPアドレス直指定でアクセスされる可能性も否めません。

一般的なユーザからIPアドレス直指定で単純に間違ったアクセスがある、という場合はおそらくHTTPSではなくてHTTPになるかと思います。HTTPSでは証明書のエラーが出るため、そこでアクセスを止めてしまいますよね。このような、たまたHTTPでIPアドレス直指定でのアクセスがあった場合、丁寧に正しいURLをHTTPSでお知らせするのも1つの方法かと思います。以下のように、HTTPのリスナールールでHTTPSへのリダイレクトを入れる際、Hostヘッダを独自ドメイン名で指定しておけば、これが実現できますね。

$ curl -i http://52.XXX.XX.180/
HTTP/1.1 301 Moved Permanently
Server: awselb/2.0
Date: Sun, 31 Oct 2021 09:18:30 GMT
Content-Type: text/html
Content-Length: 134
Connection: keep-alive
Location: https://www.example.net:443/

<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
</body>
</html>

ただし、間違ったIPアドレスでやってきたユーザや、もしくはIPアドレス総当りでなにか攻撃をしているような輩にわざわざHost名を教えるのも微妙だな、というケースもあるかと思います。このような場合には以下で示すように、Hostヘッダを具体的にチェックしてアクセスを制限する方法が採れるかと思います。

ALBのリスナールールでHostヘッダをチェックする

本題の、ALBへのアクセスをIPアドレス直指定や意図していないドメイン(Hostヘッダ)の場合に禁止する方法です。ALBの機能のみで実現する方法として、リスナールールでHostヘッダをチェックする方法が考えられます。ルールでは以下のように、想定のホスト名の場合はターゲットグループに転送、それ以外の場合はALB側で固定レスポンスを返します。Hostベースルーティング機能固定レスポンス機能の組み合わせですね。固定レスポンスについて今回は403 Forbiddenを返すこととしました。想定のHostヘッダ以外のアクセスは、リソースにアクセスすることを拒否するという意図です。

HTTPについても同様の設定をしておきます。

Hostヘッダをチェックするよう設定をしてALBにアクセスした場合、DNS名やIPアドレスなど、想定していない(ALB側に設定していない)アドレス(Hostヘッダ)でアクセスすれば、ステータスコード403が返ります。

$ curl -i http://test-alb-1234567890.ap-northeast-1.elb.amazonaws.com/
HTTP/1.1 403 Forbidden
Server: awselb/2.0
Date: Sun, 31 Oct 2021 09:38:49 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 9
Connection: keep-alive

Forbidden

$ curl -i -k https://test-alb-1234567890.ap-northeast-1.elb.amazonaws.com/
HTTP/2 403
server: awselb/2.0
date: Sun, 31 Oct 2021 12:21:27 GMT
content-type: text/html; charset=utf-8
content-length: 9

Forbidden

$ curl -i http://52.XXX.XX.180/
HTTP/1.1 403 Forbidden
Server: awselb/2.0
Date: Sun, 31 Oct 2021 09:38:59 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 9
Connection: keep-alive

Forbidden

$ curl -i -k https://52.XXX.XX.180/
HTTP/2 403
server: awselb/2.0
date: Sun, 31 Oct 2021 12:22:18 GMT
content-type: text/html; charset=utf-8
content-length: 9

Forbidden

この方法の利点としてはALB側で設定できること、ALBのみで実現できることかなと思います。例えばEC2側でHostヘッダをチェックする、ということも検討できるかと思いますが、そのチェックのためにEC2のリソースを使用してしまうのもなにか釈然としないかな、と。できればEC2のリソースは使わず、その前段のALB側で処理ができれば、と思ったしだいです。

またAWS WAFにおいて、他のチェック項目と一緒にこのようなHostヘッダのチェックする、ということも検討できるかと思います。もちろんAWS WAFでより統合的にチェックを行うことのほうがメリットはあるかと思いますが、コストなどに制限がありAWS WAFまで使わなくても、という場合に、ALBの機能を用いてサクッと設定できるのではないかと思いました。

まとめ

ALBのリスナールールでHostヘッダのチェックを行い、想定したHostヘッダのアクセス(想定したドメインでのアクセス)以外は背後のEC2へのアクセスを行わせず、ALBの固定レスポンスを返す設定を行ってみました。機能的にはALBのHostベースルーティングと固定レスポンスを組み合わせたものですが、改めてALBでいろいろなことができるようになっていると思ったしだいです。