안녕하세요, 저는 광미입니다.
구축과 검증에서 예상대로 작동하지 않으면 보안 그룹 등 방화벽 기능을 의심하게 된다.
이번에 Security Group의 설정이 정확한지 불안할 때 먹구름 속에 완전히 개방된 것보다 효율적으로 분할할 수 있기 때문에 제가 한 획을 씁니다.

물품 명세서

Listen 포트 확인

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(Windows 2012의 경우)

포트 및 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이 완전히 개방되어 발생하는 이벤트를 방지할 수 있습니다.
본문이 조금이라도 도움이 된다면 다행이다.
오늘은 여기까지.
수고하셨습니다.