L4와 L7 차이, 봉투만 보느냐 편지까지 읽느냐

호스팅이나 보안 견적서를 받아 보면 'L4 스위치 이중화', 'L7 웹방화벽', '디도스 방어' 같은 항목이 한 줄씩 붙어 있곤 합니다. 무엇인지 모른 채 넣자니 비용이 걸리고 빼자니 불안한데, L4와 L7은 장비 이름이 아니라 그 장비가 들어오는 요청을 어디까지 들여다보는지를 가리키는 말이에요. L4는 요청이 어디서 와서 어디로 가는지만 보고 길을 정하고, L7은 그 안에 담긴 내용, 그러니까 어느 페이지를 열어 달라는지와 무엇을 입력했는지까지 읽고 판단합니다. 이 차이를 알면 견적서를 받았을 때 서버가 몇 대인지, 디도스 방어가 어디까지인지, 웹방화벽 규칙은 누가 관리하는지 세 가지를 물어볼 수 있게 돼요.

숫자는 통신을 일곱 층으로 나눈 모델의 층 번호예요

L 뒤의 숫자는 네트워크 통신을 일곱 단계로 나눠 설명하는 OSI 모델의 층(Layer) 번호입니다. 홈페이지 견적서에서는 주로 4층과 7층이 나와서 이 둘을 먼저 구분하면 됩니다.

편지로 치면 4층(L4)은 봉투에 적힌 받는 주소와 호수만 보고 편지를 나르는 우편 분류기이고, 7층(L7)은 봉투를 열어 편지 내용까지 읽은 다음 담당 부서로 넘기는 비서에 가까워요. 여기서 주소는 서버의 IP 주소, 호수는 포트 번호인데, 홈페이지는 보통 443번 문으로 들어오거든요.

L4는 봉투만 보고 서버에 나눠 보내요

로드밸런서는 서버가 여러 대일 때 들어오는 방문자를 서버들에 나눠 보내는 장치입니다. AWS 문서에 따르면 L4 방식의 로드밸런서는 OSI 모델의 네 번째 계층에서 작동하고, 연결이 어디서 와서 어디로 가는지와 포트 번호만으로 보낼 서버를 정해요. 내용을 읽지 않으니 가볍고 빠릅니다.

봉투만 보는 만큼 "관리자 화면 요청은 이 서버로, 예약 페이지는 저 서버로" 같은 구분은 못 하고, 그 요청이 정상 방문인지 공격인지도 내용으로 가려내지 못해요. 자물쇠가 걸린 HTTPS 통신도 보통은 열어 보지 않은 채 그대로 서버에 넘겨요. 장비에 따라 인증서를 올려 암호를 대신 풀어 주는 기능(TLS)을 갖춘 것도 있지만, 그렇더라도 어느 서버로 보낼지는 여전히 봉투의 정보로 정합니다.

L7은 요청을 열어 읽고, 그래서 거를 수도 있어요

AWS는 L7 방식의 로드밸런서가 일곱 번째 계층에서 작동하고, 요청한 주소의 경로나 도메인 이름을 보고 서로 다른 서버로 보낼 수 있다고 안내합니다.

읽으려면 먼저 열어야 하니, HTTPS 요청을 L7에서 다루려면 그 장비에 보안 인증서(SSL)를 올려 두고 장비 안에서 암호를 풀어 내용을 확인한 뒤 서버로 넘겨야 해요. 방문자와 장비 사이의 구간은 그대로 암호화돼 있습니다. 일이 많아 L4보다 무거운 대신, 페이지 경로나 도메인 이름을 보고 서버를 나누는 일은 요청 안을 읽는 L7 장비가 맡아요. 요청 내용을 검사해 의심스러운 것을 걸러 내는 웹방화벽도 같은 층에서 일하다 보니, 견적서에서 '웹방화벽'이 L7과 함께 적혀 있곤 합니다.

디도스는 노리는 층에 따라 막는 방법이 갈려요

디도스(DDoS)는 여러 곳에서 한꺼번에 요청을 쏟아부어 사이트를 멈추게 하는 공격인데, AWS는 이를 층별로 나눠 설명합니다. 3·4층 공격은 길 자체를 막는 쪽이라 회선과 접속 자리를 쓰레기 통신으로 채우고, 7층 공격은 겉보기에 멀쩡한 페이지 요청을 대량으로 보내 사이트 프로그램과 데이터베이스를 지치게 만들어요.

AWS는 3·4층 공격은 자동으로 완화하지만, 7층 공격에는 정상 사용자를 실수로 막지 않도록 기본적으로 자동 완화를 걸지 않는다고 밝히고 있습니다. 7층 공격은 진짜 방문자와 생김새가 같아서 기계적으로 잘라 내면 손님까지 함께 잘리거든요. 그래서 7층에서는 방문자 한 명(같은 IP)이 짧은 시간에 너무 많이 요청하면 잠시 막는 요청 수 제한 규칙을 사이트 사정에 맞춰 따로 걸어 둡니다.

웹방화벽은 입력값을 읽고 공격을 걸러요

OWASP는 웹 보안 표준을 만드는 비영리 단체인데, 웹 애플리케이션 방화벽(WAF)을 웹 요청에 규칙을 적용하는 방화벽으로 정의하고, 대표적으로 막는 공격으로 SQL 인젝션과 XSS를 듭니다. 문의 양식이나 검색창에 글자 대신 데이터베이스 명령을 끼워 넣는 게 SQL 인젝션이고, 게시판 같은 곳에 남의 화면에서 실행될 악성 코드를 심는 게 XSS예요. AWS가 데이터베이스용, PHP 프로그램용 규칙 묶음을 따로 두는 것처럼, 사이트를 무엇으로 만들었는지에 따라 걸어 둘 규칙도 달라집니다.

열어 둘 문(포트)만 열고 나머지를 닫는 방식의 방화벽은 L4 쪽 장치라 이런 검사를 하지 못해요. 제품에 따라 웹 요청 검사 기능을 함께 넣은 방화벽도 있어서, 견적서의 '방화벽'이 어느 쪽인지는 항목 설명을 봐야 알 수 있습니다. 규칙이 너무 엄하면 정상적인 글 등록까지 막히는 일도 생기는데, AWS 한국 블로그가 이런 오탐을 예외로 풀어 주는 운영 절차를 따로 다룰 만큼 흔한 일이에요.

견적서를 받았다면 세 가지를 물어보면 돼요

서버가 몇 대인지부터 물어보면 로드밸런서 항목이 정리됩니다. 로드밸런서는 상태가 나쁜 서버를 빼고 건강한 서버로만 보내는 장치라, 서버를 두 대 이상 두고 한 대가 멈춰도 사이트가 열려 있어야 할 때 제 역할을 합니다. 서버가 한 대뿐이면 나눠 보내는 일은 할 게 없지만, 앞단에서 인증서를 처리하거나 웹방화벽을 붙이는 자리로 쓰는 경우도 있어요. 서버가 한 대인데 로드밸런서가 들어 있다면 무엇을 맡기려는 것인지 물어보면 됩니다.

디도스 방어가 어느 층까지인지도 물어볼 만해요. 3·4층의 대량 트래픽을 회선에서 걸러 주는 데서 끝나는지, 7층의 요청 폭주까지 규칙을 걸어 주는지에 따라 같은 이름의 상품도 하는 일이 다르거든요. 중소기업이라면 KISA(한국인터넷진흥원)가 공격받는 웹사이트의 트래픽을 대신 받아 걸러 주는 사이버대피소를 무료로 운영하고 있어서, 미리 등록해 둘 수 있는지 알아 두면 좋습니다.

웹방화벽 규칙을 누가 관리하는지는 계약 전에 확인해 두는 게 안전해요. 우리 사이트를 만든 프로그램에 맞는 규칙이 들어가는지, 정상 요청이 막혔을 때 누구에게 연락해 얼마나 빨리 풀 수 있는지를 물어보면 됩니다.

받은 견적서의 보안 항목이 지금 사이트에 맞는지 판단하기 어렵다면 웨이비웍스에 문의하실 수 있어요. 사이트 구성과 견적 내용을 알려 주시면 어느 항목이 필요하고 빠진 것은 없는지 같이 정리해 드립니다.