iptables --uid-owner는 LAN 사용자가 아니라 Squid의 로컬 소켓과 일치한다
Squid의 이그레스를 따질 때는 --uid-owner를 로컬 소켓 생성자라는 의미로 사용하고, 전달되는 LAN 패킷과는 분리해 다뤄야 한다.
iptables의 owner 매치는 로컬 프로세스의 소켓이 만든 패킷을 식별할 수 있다. 예를 들어 -m owner --uid-owner 1234는 UID 1234가 소유한 로컬 소켓을 가리키며, HTTP 프록시 사용자 이름을 식별하는 것이 아니다.
Squid가 실행되는 머신에서는 다음 경로를 구분해야 한다:
| 트래픽 | 관련 구분 |
|---|---|
| 클라이언트가 이 머신의 Squid에 연결한다 | 프록시 리스너로 들어오는 연결 |
| Squid가 목적지 연결을 연다 | 로컬에서 생성된 아웃바운드 소켓 |
| LAN 클라이언트가 이 머신을 통해 직접 라우팅한다 | 로컬 생성 소켓이 없는 전달 트래픽 |
이 확장은 OUTPUT과 POSTROUTING에서 유효하다. 전달되는 패킷에는 이 매치에 해당하는 로컬 소켓이 없으므로, FORWARD 규칙이 Squid의 UID를 물어 원격 컴퓨터의 사용자를 알아낼 수는 없다.
따라서 Squid 자체의 아웃바운드 소켓만 허용하는 정책은 프록시에만 의존하는 네트워크 설계의 한 부분만 다룬다. 게이트웨이 전달, 리스너 접근, 그 밖의 허용된 서비스, 실제 프록시 서비스 계정은 각자의 적절한 범위에서 처리해야 한다.
Squid가 nobody로 실행된다고 가정하지 말고 설정된 런타임 ID를 사용하라. 여러 프로세스가 하나의 UID를 공유할 수 있으므로 UID 기반 허용은 계정 경계일 뿐, 특정 실행 파일이 모든 허용 연결을 만들었다는 증거는 아니다.