こんにちは、ひろかずです。

構築や検証中に思うように動作しない時にSecurity Groupをはじめとするファイアウォール機能を疑いたくなりますよね。
今回は、SecurityGroupの設定が正しいか不安な時に闇雲にフル開放してしまうより効率的に切り分けをできる方法があるので、一筆書きます。

お品書き

  1. Listenポートの確認
  2. VPC FlowLogsの確認

1. Listenポートの確認

サーバで待ち受けていないポートをSecurity Groupで開放する必要はありません。
どのサービスがどのポートを使用しているかを再確認し、開放するべきポートが開放されているかを確認しましょう。

0.0.0.0:ポート番号 や:::ポート番号 で表現されているポートが外部からの待受を想定しているポートです。
上手くできないことに関連するポートを開放すると良いでしょう。
切り分けたい現象にもよりますが、sshやntp等の関連性が薄いサービスポートを空ける必要性は低いはずです。

出力例

netstat -luntp (Amazon Linuxの場合)

# netstat -luntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN      2331/rpcbind
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      32508/sshd
tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN      32592/sendmail
tcp        0      0 0.0.0.0:36254               0.0.0.0:*                   LISTEN      2352/rpc.statd
tcp        0      0 :::111                      :::*                        LISTEN      2331/rpcbind
tcp        0      0 :::80                       :::*                        LISTEN      2628/httpd
tcp        0      0 :::22                       :::*                        LISTEN      32508/sshd
tcp        0      0 :::4118                     :::*                        LISTEN      15287/ds_agent
tcp        0      0 :::443                      :::*                        LISTEN      2628/httpd
tcp        0      0 :::46046                    :::*                        LISTEN      2352/rpc.statd
：

netstat -nao & Task Manager(Windows2012の場合)

コマンドプロンプトでポートとPIDを確認し、Task ManagerでPIDとサービスを確認することができます。

C:\Users\Administrator>netstat -nao

Active Connections

  Proto  Local Address          Foreign Address        State           PID
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       792
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       72
  TCP    0.0.0.0:4118           0.0.0.0:0              LISTENING       163
  TCP    0.0.0.0:5985           0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:47001          0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:49152          0.0.0.0:0              LISTENING       600
  TCP    0.0.0.0:49153          0.0.0.0:0              LISTENING       928
  TCP    0.0.0.0:49154          0.0.0.0:0              LISTENING       972
  TCP    0.0.0.0:49155          0.0.0.0:0              LISTENING       121
  TCP    0.0.0.0:49157          0.0.0.0:0              LISTENING       688
  TCP    0.0.0.0:49158          0.0.0.0:0              LISTENING       208
  TCP    0.0.0.0:49164          0.0.0.0:0              LISTENING       696
  TCP    172.31.40.9:139        0.0.0.0:0              LISTENING       4
  ：

2. VPC FlowLogsの確認

インスタンスに紐付けられているENIで遮断している通信を確認します。
実際に目的とする動作を行い、その実施時間で遮断している通信(REJECTで検索)があるかを確認するのが良いでしょう。

VPC FlowLogsの設定の仕方はawsブログ : VPC Flow Logs – トラフィックフローの収集、閲覧を参照してください。

このように、Security Groupで遮断された通信はひと目で判断することができます。
切り分けの観点であれば、これで十分と言えるでしょう。

おわりに

闇雲にSecurity Groupを開きすぎてしまうと、原因が特定できないだけではなく、セキュリティを著しく低下させてしまいます。
サービスの稼働を優先させた場合、設定を戻すこともままならず、セキュリティを低下させたまま運行することになるかもしれません。

検証環境や構築中の環境でも、インターネットからの脅威は本番環境と変わらずに訪れます。
むしろ、セキュリティ強度の劣る検証環境や構築中の環境は、格好の標的になるでしょう。

Security Groupフル開放によるインシデントは防げます。
本稿が少しでもその助けになれば幸いです。

今日はここまでです。
お疲れ様でした。

元記事はこちら

「Security Groupの適切な設定のためにできる、たった2つのこと(STOP!フル開放運動)」