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

개발용 EC2 서버 20대를 모니터링 대상으로 새로 추가하는 작업이었습니다. 모니터링은 Zabbix 를 쓰고, 각 서버에 에이전트를 깔아야 지표가 수집되니, 20대에 한 대씩 접속하는 대신 SSM(AWS Systems Manager)으로 에이전트 설치를 한 번에 일괄 배포했습니다.

에이전트가 깔리면 Zabbix 의 자동 등록이 돌아 그 서버를 모니터링 대상으로 알아서 추가해 줍니다. 그런데 등록되자마자 20대 중 3대가 곧바로 host down, 그러니까 수집 불가로 떴습니다.

제일 먼저 든 생각은 “오늘 누가 보안 그룹을 건드렸나” 였습니다. 배포 직후에 몇 대만 안 되면 방화벽부터 의심하는 게 보통이고, SG 는 여러 사람이 만지는 자원이라 실제로도 흔한 원인입니다.

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

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

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

에러 메시지도 같은 방향을 가리켰습니다.

[4] Interrupted system call

Zabbix 가 에이전트 응답을 기다리다 제한 시간에 걸려 끊을 때 나오는 메시지라 Connection refused 가 아니라 타임아웃입니다. 포트가 닫혀 있으면 거절 응답이 바로 오지만, 아무 응답 없이 시간만 흐른 건 SYN 이 조용히 버려졌다는 뜻이라 방화벽이 막고 있다고 보는 게 맞습니다.

부재 증명 — 독립된 두 증거

여기서 규칙이 지워진 건지 원래 없던 건지가 갈립니다. 지워진 거면 누가 언제 왜 지웠는지를 찾아 되돌려야 하고, 원래 없던 거면 그냥 넣으면 끝나는 일이라 대응이 완전히 달라서, 서로 독립된 두 곳에서 확인했습니다.

확인한 곳	무엇을 봤나	결과	이게 말해 주는 것
CloudTrail 90일치	그 SG·ENI·인스턴스의 Authorize* / Revoke* / Modify*	0건	90일 안에 누구도 규칙을 넣거나 뺀 적이 없다
Zabbix 히스토리	agent.ping (보관 기간 전체)	데이터 없음	한 번도 붙은 적이 없다

CloudTrail 은 “바꾼 사람이 없다” 를, 히스토리는 “붙은 적이 없다” 를 말합니다. 한 번 이라도 붙었던 적이 있으면 그때 찍힌 agent.ping 이 남아 있어야 하지만 전무했습니다.

변경 이력과 동작 이력이라는 서로 상관없는 두 곳이 같은 결론을 가리키니 누가 지웠나를 쫓는 삽질을 접고 규칙을 넣는 쪽으로 넘어갈 수 있었습니다.

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

같이 확인하다 하나 더 나왔습니다. Zabbix 자동 등록은 에이전트가 보내온 호스트명을 액션 조건과 대조해서 템플릿을 붙이는데, 에이전트 설정에서 Hostname= 을 지우면 시스템 호스트명이 그대로 올라갑니다. 조건에 걸어 둔 이름과 달라지면 매칭이 실패해 템플릿이 안 붙은 호스트로 등록됩니다. 항목이 0개라 수집도 알림도 없는데 목록에는 등록된 것처럼 보이니 오히려 더 위험합니다.

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

장애를 보면 무엇이 바뀌었나부터 찾게 되지만, 이번처럼 아무것도 안 바뀌었고 원래 그랬던 거면 그 방향으로는 답이 안 나옵니다. 부재를 증명하려면 서로 독립된 증거 둘이 같은 결론을 내야 하고, 변경 이력이 0건이고 동작 이력도 전무하면 그건 지워진 게 아니라 처음부터 없던 겁니다.

패시브 체크는 Zabbix 쪽이 서버로 접속하는 방향이라 서버 쪽 인바운드가 열려 있어야 합니다. 일괄 배포 후에 몇 대만 안 붙으면 그 몇 대의 SG 구성이 나머지와 어떻게 다른지부터 비교하면, 왜 하필 이것들만인지가 대개 거기서 나옵니다.