포트

IP 주소로 서버까지 도달하는 것은 건물 입구까지 찾아간 것과 비슷합니다. 그런데 한 서버에서 웹 서비스, SSH 접속, 데이터베이스, 메일 서버가 동시에 돌아가고 있다면 도착한 패킷을 어떤 프로세스에 넘겨야 하는지 결정할 수 없습니다. IP만으로는 '이 서버'까지는 갈 수 있어도 '이 서버의 어떤 서비스'까지는 특정하지 못합니다. 방화벽 설정에서도 같은 문제가 생깁니다. 외부에서 웹 요청은 받아야 하는데 데이터베이스 연결은 막아야 할 때, IP 하나에 서비스를 구분할 방법이 없으면 전부 열거나 전부 닫는 양자택일밖에 남지 않습니다. 포트 번호는 하나의 IP 주소 안에서 서비스를 식별하는 두 번째 좌표를 제공함으로써 이 문제를 해결합니다.

초기 네트워크에서는 한 서버가 한 가지 역할만 했기 때문에 IP 주소만으로 서비스를 특정하는 데 큰 문제가 없었습니다. 그런데 서버 하드웨어가 발전하고 운영 효율이 중요해지면서 한 서버에 여러 서비스를 올리는 것이 자연스러워졌습니다. 웹 서버, 메일 서버, 파일 서버가 같은 물리 장비에서 돌아가기 시작하면 패킷이 도착한 후 어느 프로세스에 전달할지를 결정하는 메커니즘이 필수가 됩니다. TCP/IP를 설계할 때 전송 계층 헤더에 16비트 포트 번호를 넣기로 한 것은 이 문제에 대한 응답이었습니다. IANA(Internet Assigned Numbers Authority)가 잘 알려진 서비스에 고정 번호를 배정함으로써 클라이언트는 사전에 합의된 번호만으로 원하는 서비스에 접근할 수 있게 됐습니다. 오늘날 컨테이너 환경에서 포트 매핑, 쿠버네티스에서 서비스 포트와 타겟 포트를 따로 지정하는 등의 개념도 이 기본 원리 위에 서 있습니다.

포트는 운영체제의 네트워크 스택이 관리하는 논리적 번호입니다. 서버에서 프로세스가 특정 포트에 바인딩하면 그 포트로 들어오는 패킷은 해당 프로세스에 전달됩니다. 클라이언트가 연결할 때는 운영체제가 49152~65535 범위에서 사용하지 않는 임시 포트(ephemeral port)를 자동으로 할당해 출발 주소로 씁니다. 이때 실제 연결을 식별하는 단위는 포트 하나가 아니라, 출발지 IP와 포트, 목적지 IP와 포트, 프로토콜을 합친 5-tuple입니다. 그래서 서로 다른 클라이언트가 같은 서버의 443 포트에 동시에 접속해도 각각의 연결이 구분됩니다. 포트 번호는 TCP와 UDP 헤더에 들어 있으며, IP 헤더의 주소와 함께 패킷이 정확한 목적지에 도달하도록 합니다.

포트와 소켓은 네트워크 프로그래밍에서 자주 함께 등장하지만 역할이 다릅니다. 포트는 0~65535 사이의 번호로, 서비스가 어떤 문에서 대기하고 있는지를 식별합니다. 소켓은 프로토콜, IP, 포트를 합쳐 만든 통신 끝점(endpoint)으로, 실제 데이터를 주고받는 연결 자체를 나타냅니다. 같은 80번 포트에서 수천 개의 소켓이 동시에 열릴 수 있는 이유는, 소켓이 출발지 정보까지 조합해 개별 연결을 구분하기 때문입니다. 포트 번호만으로 보안이 완성된다고 보기도 어렵습니다. 포트를 닫는 것은 문을 잠그는 것이지, 건물 자체를 보호하는 것은 아닙니다. 열려 있는 포트 뒤의 서비스가 취약하면 포트가 열려 있는 한 공격 대상이 됩니다. 그래서 포트 관리는 방화벽, 인증, 암호화와 함께 쓰여야 실질적인 보안이 됩니다.

포트 번호는 서버 배포, 방화벽 규칙, 컨테이너 매핑, 로드 밸런서 설정 같은 운영 작업 전반에서 반복적으로 등장합니다. 새 서비스를 배포할 때 어떤 포트를 열 것인지 결정하는 것은 곧 외부에 무엇을 노출하고 무엇을 숨길지 정하는 것이며, 보안 그룹이나 방화벽 규칙은 대부분 포트 번호를 기준으로 허용과 차단을 나눕니다. 다만 포트 번호는 서비스 식별자일 뿐이지 서비스의 안전성을 보장하지는 않습니다. 443번 포트를 열어 뒀더라도 뒤에서 돌아가는 애플리케이션이 취약하면 의미가 없고, 비표준 포트로 바꿔 봐야 스캔 도구 앞에서는 실질적 방어가 되지 않습니다. 포트 관리의 핵심은 '필요한 포트만 열고 나머지는 닫는다'는 최소 노출 원칙이며, 이것은 방화벽, TLS, 인증과 함께 작동할 때 비로소 의미를 갖습니다.

다음에 볼 개념

함께 보면 좋은 개념