시험 환경에서 밖으로 나가는 요청을 필요한 곳만 열고 나머지는 막아야 했다. 기존 설정을 보니 HTTP_PROXY 로 squid 를 거쳐 나가고 있어서 그 프록시 주소를 보안 그룹 허용 목록에 넣으려고 했다.
Table of contents
Open Table of contents
원인 — 프록시를 허용하면 열리는 범위
프록시 주소를 허용하면 그 프록시를 거치는 모든 요청이 통과하게 된다. 프록시는 어디로든 보낼 수 있으므로 그 허용은 사실상 아무것도 막지 않는 설정이 된다.
허용해야 하는 것은 프록시가 아니라 그 너머의 목적지였다. 통제하려는 대상이 경유 지점인지 종착점인지를 먼저 정해야 목록의 내용이 정해진다.
검증 — 목적지 목록의 정본
목적지 목록이 필요한데 문서에는 그런 것이 없었고 실제 호출 대상은 클라이언트 코드 안에 흩어져 있었다. 두 저장소의 클라이언트 코드에서 grep -rhoE 'https?://[^/"]+' | sort -u 로 호출 주소를 뽑으니 스무 개 남짓이 나왔고 시험용 변형까지 합쳐 스물 몇 개가 됐다.
문서가 아니라 코드가 정본인 종류의 정보였고 그것을 뽑는 데 명령 하나면 충분했다. 이런 목록은 사람이 기억으로 채우면 반드시 빠지는 것이 생긴다.
조치 — 파일 관리와 무중단 반영
두 가지 방법이 있었는데 squid.conf 안에 acl 로 직접 나열하는 것과 allowed.txt 파일로 두고 squid 공식 문서의 acl aclname dstdomain 이 그 파일을 읽게 하는 것이다. 뒤쪽을 골랐다. 이유는 목록을 코드 옆 파일로 두면 새 연동이 생길 때 코드와 이 파일을 함께 갱신하는 절차로 묶을 수 있어서다. 대신 파일이 갱신됐는지를 배포 검사에 하나 더 넣어야 하는 것을 감수했다. 갱신한 뒤에 squid -k reconfigure 로 재기동 없이 설정만 다시 읽게 할 수 있는지도 함께 확인했다.
재기동이 필요하면 사람이 갱신을 미루게 되고 그러면 목록이 낡은 채로 남는다. 반영 비용이 낮아야 그 관리가 실제로 유지된다는 것이 이 설계의 전제였다.
주의 — 목록에 있는 것과 경로를 지나는 것
목록을 만들다 보니 HTTP_PROXY 가 주석 처리돼 프록시를 안 거치고 직접 나가는 대상이 있었다. 그런 대상은 허용 목록에 넣어도 아무 효과가 없는데 애초에 그 경로를 지나지 않기 때문이다.
목록에 들어 있다는 것과 그 통제 지점을 실제로 지난다는 것은 별개의 사실이고 앞의 것만 보면 통제되고 있다고 착각한다. 실제로 경유시키려면 설정을 되살려야 하므로 그것을 별도 작업으로 적었다.
배경 — 어느 계층이 실제로 막는가
차단이 제대로 되는지 시험하다가 이름을 해석해 주지 않아도 주소로 직접 가면 통한다는 것을 확인했다. 장비가 대역 사이를 라우팅하므로 이름 해석을 막는 것만으로는 경계가 만들어지지 않았다.
실제 경계는 squid 의 http_access 였고 그것만이 주소로 오든 이름으로 오든 동일하게 막는다. 그래서 차단 시험에서 거부 여부만 보지 않고 어떤 오류로 거부되는지까지 봤는데 403 이 아니라 NXDOMAIN 으로 거부되면 그것은 프록시가 막은 것이 아니기 때문이다.
정리
- 허용 목록의 대상은 프록시가 아니라 그 너머의 목적지다
- 통제하려는 대상이 경유 지점인지 종착점인지를 먼저 정한다
- 목적지 목록의 정본은 대개 문서가 아니라 코드다
- 반영 비용이 낮아야 목록 관리가 실제로 유지된다
- 목록에 있는 것과 그 통제 지점을 지나는 것은 별개다
- 이름 해석을 막는 것으로는 경계가 만들어지지 않는다
- 어느 계층이 실제로 막는지를 확인한다
- 차단 시험에서 어떤 오류로 거부되는지까지 본다