보안 그룹 규칙 부재 증명 — CloudTrail 교차 검증

개발용 EC2 서버 20대를 모니터링에 새로 편입시키는 작업이었습니다. 모니터링은 Zabbix 를 쓰는데, 각 서버에 Zabbix 에이전트를 깔아야 Zabbix 가 그 서버의 지표를 수집합니다. 20대를 한 대씩 붙기는 번거로워서, 에이전트 설치를 SSM (AWS Systems Manager)으로 한 번에 일괄 배포했습니다.

에이전트가 깔리면 Zabbix 의 자동 등록이 돌아 그 서버를 모니터링 대상으로 알아서 추가합니다. 그런데 등록되자마자 20대 중 3대가 곧바로 “host down”(수집 불가)으로 떴습니다. 반사적으로 든 생각은 “오늘 누가 보안 그룹을 건드렸나” 였습니다. 틀렸습니다. 그 규칙은 처음부터 없었습니다.

왜 3대만 — 서버가 먼저 접속하는 패시브 체크

쓰던 템플릿이 패시브 체크 위주였습니다(대부분 항목이 서버가 에이전트로 접속해 값을 가져오는 방식). 즉 모니터링 프록시가 각 노드의 에이전트 포트(10050) 로 먼저 다이얼합니다. 그러려면 노드의 보안 그룹에 프록시로부터의 10050 인바운드가 열려 있어야 합니다.

문제의 3대는 공용 SG 대신 전용 SG 만 달고 있었고, 거기 10050 규칙이 없었습니다. 나머지 17대는 공용 SG 로 그 포트가 열려 있어서 멀쩡했습니다.

에러 메시지도 힌트였습니다.

[4] Interrupted system call

Connection refused 가 아니라 타임아웃(패킷이 조용히 버려짐)입니다. 포트가 막혀 SYN 이 응답 없이 드롭된 모습입니다.

부재 증명 — 독립된 두 증거

“규칙이 지워졌다” 와 “규칙이 원래 없었다” 는 대응이 완전히 다릅니다. 그래서 서로 독립된 두 곳에서 확인했고, 둘 다 같은 결론을 냈습니다.

• CloudTrail 90일 스윕 — 그 SG·ENI·인스턴스에 찍힌 Authorize*/Revoke*/Modify* 이벤트가 0건. 90일 안에 규칙을 넣거나 뺀 적이 없다는 뜻입니다.
• 모니터링 히스토리 — agent.ping 데이터가 보관 기간 전체에 걸쳐 비어 있음. 한 번이라도 접속됐다면 과거 데이터가 남아 있어야 하는데 전무했습니다. 즉 이 노드는 애초에 한 번도 안 붙었습니다.

두 증거가 독립적으로 같은 결론(한 번도 없었음)을 가리키니, “누가 지웠나” 를 쫓는 삽질을 접을 수 있었습니다.

호스트명 설정과 자동 등록 매칭 실패

같이 확인하다 하나 더 나왔는데, 기본 호스트명을 쓰는 노드에서 에이전트의 Hostname= 설정을 지우면 자동 등록 매칭이 조용히 안 맞아 템플릿 없는(항목 0개, 알림도 없는) 호스트로 등록됩니다. 겉으론 등록된 것처럼 보여서 더 위험합니다.

변경 이력이 아니라 부재를 확인해야 할 때

장애를 보면 “무엇이 바뀌었나” 부터 찾게 되지만, 답이 “아무것도 안 바뀜, 원래 그랬음” 일 때가 있습니다. 부재를 증명하려면 서로 독립된 증거 둘이 같은 결론을 내야 합니다 — 변경 이력(CloudTrail)이 0건이고, 동작 이력(ping 데이터)도 전무하면, 그건 “지워진” 게 아니라 “처음부터 없던” 겁니다. 그리고 패시브 체크는 서버가 노드로 접속하는 방향이라, 노드 쪽 인바운드가 열려 있어야 한다는 걸 기억하면 “왜 하필 이 몇 대만” 이 풀립니다.