[1% network] Ch05. 서버측의 LAN에는 무엇이 있는가
Ch05. 서버측의 LAN에는 무엇이 있는가
학습할 것
- 웹 서버의 설치 장소
- 방화벽의 원리와 동작
- 복수 서버에 리퀘스트를 분해한 서버의 부하 분산
- 캐시 서버를 이용한 서버의 부하 분산
- 콘텐츠 배포 서비스
웹 서버의 설치 장소
- 이번 장은 인터넷에서 서버에 도착할 때까지를 다룬다. 이는 서버의 설치 장소에 따라 다르다.
1. 사내에 웹 서버를 설치하는 경우
- 라우터에서 직접 연결하는 경우
- IP 주소 부족 (서버뿐 아니라 클라이언트에도 글로벌 주소를 할당해야한다)
- 보안에 취약하다.
- 방화벽으로 분리하는 경우
- 일단 패킷을 검사하고 통과를 허가한 패킷만 중계한다.
- 액세스를 허가한 애플리케이션에 보안 구멍이 있으면 공격받을 위험이 있다.
2. 데이터센터에 웹 서버를 설치하는 경우
- 데이터센터는 프로바이더의 중심 부분에 있는 NOC에 직접 접속되었거나 프로바이더들이 상호 접속하는 IX에 직결되어 있다.
- 인터넷 중심 부분에서 데이터센터로 패킷이 흘러가고 데이터센터에 방화벽 등이 설치되었으면 점검을 받은 후 서버 머신에 도착한다.
방화벽의 원리와 동작
방화벽이란?
- 외부로부터 내부망을 보호하여 불법정보의 유입을 차단하기 위한 정책이다.
- 네트워크를 통해 흐르는 패킷을 미리 정해놓은 정책에 따라 허용 또는 거부하거나 검열 수정하는 하드웨어나 소프트웨어 장치이다.
방화벽의 주요 기능
- 접근제어
- 정책에 의하여 허용/차단하기 위한 검사
- 로깅 및 감사 추적
- 허가되지 않은 정보에 대한 로그파일 기록, 의심스러운 사항이나 명백한 침입 사실이 확인될 경우 이에 대한 자세한 정보를 관리자가 추적할 수 있도록 하는 기능
- 사용자 인증
- 전통적인 패스워드 시스템의 취약점 방지를 위해 스마트 카드나 인증 토큰과 같은 인증 기법이 제시되고 있다.
- 데이터 암호화
- 트래픽의 데이터를 암호화하여 외부 침입자에게 노출되어도 비밀성을 보장한다.
방화벽의 종류
- 패킷 필터링 방식
- 어플리케이션 게이트웨이 방식
- 상태 추적 방식
- 서킷 게이트웨이 방식
- 하이브리드 방식
(1) 패킷 필터링 방식
- 네트워크 계층과 전송계층에서 동작하는 방식이다.
- 해당 계층의 데이터를 가지고 인바운드와 아웃바운드 서비스를 제공하는 것으로 네트워크 계층에서는 IP 주소, 전송 계층에서는 포트 주소와 TCP, UDP 플토콜 종류에 대한 데이터를 바탕으로 방화벽 정책을 세워 패킷을 필터링한다.
패킷 필터링 방식의 장점
- 다른 방화벽에 비해 속도가 빠르다. 확인하는 데이터가 다른 방화벽에 비해 적기 때문이다.
패킷 필터링 방식의 단점
- TCP/IP 프로토콜의 구조적 문제로 인하여 패킷 헤더의 조작이 가능하며 패킷 내의 데이터에 대한 공격을 차단하지 못한다.
- 네트워크와 전송 계층만 다루기 때문에 수집 정보가 한정적이고 해당 정보에 대한 로그만으로는 사용자 행위를 유추하기 힘들다.
(2) 어플리케이션 게이트웨이 방식
- 어플리케이션 계층까지 동작하며 통과하는 패킷의 헤더 안의 Data 영역까지도 체크하여 통제한다.
- 해당 서비스별로 프락시라는 통신 중계용 데몬이 구동되어 각 서비스 요청에 대하여 방화벽이 접근 규칙을 적용하고 연결을 대신하는 역할을 수행한다.
어플리케이션 게이트웨이 방식의 장점
- 외부 네트워크와 외부 네트워트가 프록시 서버를 통해만 연결되고, 직접 연결은 허용되지 않기 때문에 내부 네트워크에 대한 경계선 방어 및 내부 네트워크에 대한 정보를 숨길 수 있다.
- 패킷 필터링 방화벽 보다 높은 보안 설정이 가능하다.
- 일회용 패스워드를 이용한 강력한 인증 기능을 제공할 수 있다.
- 세션에 대한 정보를 추적할 수 있고, Content Security가 가능하다. (http, nntp, ftp등의 경우 command level -put, get, post등- 까지 제어가 가능하다.)
어플리케이션 게이트웨이 방식의 단점
- 응용 계층에서 동작하므로 네트워크에 많은 부하를 줄 수 있다.
- 일부 서비스에 대해 투명성을 제공하기 어렵다.
- 하드웨어에 의존적이다.
- 새로운 서비스를 제공하기 위하여 새로운 데몬이 있어야 한다.
- 미리 정의된 어플리케이션만 수용 가능하므로 다양하고 빠르게 발전하는 인터넷 어플리케이션에 대응하지 못한다.
(3)상태 추적 방식
- 패킷 필터링 방식과 어플리케이션 방화벽 방식의 단점을 보완한 방식이다.
- 네트워크 계층에서 패킷을 처리하면서 프로토콜의 상태정보 테이블을 유지하여 프로토콜 특성에 따른 변화를 동적으로 대응한다.
- 기존 패킷 필터링 기능에 세션 추적 기능을 추가하여 일련의 네트워크 서비스의 순서를 추적하여 순서에 위배되는 패킷들은 모두 차단한다.
상태 추적 방식의 동작 원리
- 클라이언트는 특정 서버 연결을 방화벽에 요구한다.
- 방화벽은 상태목록에 출발지, 도착지, 포트 서비스 및 되돌아오는 패킷 여부 기록 후 ACL을 검토한다.
- ACL 목록에서 해당 패킷 통과가 허용되는지 검토한다.
- 해당 패킷 통과가 허용된다면 외부 web 서버 B 에 연결한다.
- web 서버 B 의 응답 패킷이 방화벽에 진입한다.
- 방화벽은 해당 응답 패킷을 ACL 에서 검토한다.
- 허용된 패킷일 경우 상태 목록에서 기존 패킷에 대한 응답 패킷인지를 확인한다.
- 정상적인 응답 패킷인 경우 클라이언트 A 에게 연결한다.
상태 추적 방식의 장점
- 모든 통신채널에 대해 추적 가능하다.
- 한 차원 높은 패킷 필터링 기능을 제공한다.
- 응용프로그램 방화벽과 같은 성능 감소가 발생하지 않는다.
- UDP 와 RPC 패킷 추적이 가능하다.
- 패킷 내의 데이터 상태와 정황(context)이 저장되고 지속적으로 갱신된다.
상태 추적 방식의 단점
- 상태목록(state table)에 DOS 나 DDOS 공격으로 인해 거짓 정보가 가득 차게 되면 장비가 일시적으로 정지하거나 재가동해야 한다.
- 어떠한 이유로 방화벽을 재구동시 현재 연결에 대한 모든 정보를 잃어버리게 되고 정당한 패킷에 대해 거부가 발생할 수 있다.
(4) 서킷 게이트웨이 방식
- 세션 계층에서 응용 계층 사이에서 접근제어를 실시하는 방화벽이다.
- 어플리케이션 게이트웨이와는 달리 각 서비스별로 프락시가 존재하는 것이 아니고, 어느 서비스 프로토콜도 이용할 수 있는 일반적인 대표 프락시를 이용한다
- 클라이언트 프로그램은 모든 통신에서 방화벽에 있는 프락시와 연결을 맺고 안전한 통신채널인 Circuit을 구성한 후 이 Circuit을 통해 내부 시스템과 통신을 한다.
서킷 게이트웨이 방식의 장점
- 내부의 IP 주소를 숨길 수 있다.
- 첫 패킷 검사 후 다음 패킷은 전달만 한다.
- 각 서비스별로 프록시가 존재하지 않고, 모든 서비스가 이용 가능한 일반적인 프록시가 존재한다.
- 수정된 클라이언트 프로그램이 설치된 사용자에게 별도의 인증 절차 없이 투명한 서비스를 제공할 수 있다.
서킷 게이트웨이 방식의 단점
- 방화벽에 접속을 위해서 서킷 게이트웨이를 인식할 수 있는 수정된 클라이언트 프로그램이 필요하므로 사용자들에게 프로그램을 배포해야 하거나 사용 중인 응용프로그램을 수정해야 하는 번거로움이 있다.
(5) 하이브리드 방식
- 패킷 필터링 방식과 어플리케이션 방식을 혼합한 것이다.
하이브리드 방식의 장점
- 내부 보안 정책 및 어플리케이션 등에 맞추어 선택적인 보안 설정이 가능하다.
- 여러 유형의 방화벽 특징을 보유하기 때문에 새로이 등장하는 인터넷상의 모든 서비스에 가장 유동적으로 대처 가능하다.
하이브리드 방식의 단점
- 관리가 복잡하다.
- 설치 시 전문적인 Network Consulting 이 필요하다.
1. 패킷 필터링형이 주류이다.
- 패킷 선별 작업에 다양한 방법이 고안되었으나 여러 이유로 현재는 패킷 필터링형이 가장 많이 보급되었다.
2. 패킷 필터링의 조건 설정 개념
- 패킷 필터링형 방화벽은 수신처/송신처의 IP 주소, 송신처/수신처 포트번호, 컨트롤 비트 등으로 패킷을 필터링한다.
수신처 IP 주소 | 수신처 포트 번호 | 송신처 IP 주소 | 송신처 포트 | TCP 컨트롤 비트 | 통과/ 차단 |
---|---|---|---|---|---|
192.0.2.0/24 | 80 | - | - | - | O |
- | - | 192.0.2.0/24 | 80 | SYN = 1 ACK=0 | X |
- | - | 192.0.2.0/24 | 80 | - | O |
- | - | - | - | - | X |
- 수신처 IP 주소가 웹 서버의 IP 주소에 일치하는 패킷은 통과시킨다.
3. 애플리케이션을 한정할 때 포트 번호를 사용한다
- 애플리케이션을 한정할 때는 TCP 헤더나 UDP 헤더에 기록되어있는 포트 번호를 조건으로 추가한다.
- 수신처 IP 주소가 웹 서버의 주소와 일치하고 수신처 포트 번호가 80번인 패킷은 통과한다.(예시표 1행)
- 송신처 IP 주소가 웹 서버의 주소와 일치하고 수신처 포트 번호가 80번인 패킷은 통과한다. (예시표 3행)
4. 컨트롤 비트로 접속 방향을 판단한다
- 웹의 동작은 TCP 프로토콜을 사용하여 양방향으로 패킷이 흐르므로 단순히 웹 서버에서 인터넷으로 흐르는 패킷을 정지시키면 인터넷에서 웹 서버에 액세스 하는 동작도 정지되기 때문에 패킷이 흐르는 방향이 아닌 액세스 방향을 판단하여 정지시켜야한다.
- 이 때 사용하는 것이 TCP 헤더의 컨트롤 비트이다.
- 최초 패킷만 SYN 1, ACK 0 비트를 가지므로 이를 차단하면 TCP 접속동작이 실패하여 웹 서버에서 액세스 하는 동작을 정지시킬 수 있다.
5. 사내 LAN에서 공개 서버용 LAN으로 조건을 설정한다
6. 밖에서 사내 LAN으로 액세스할 수 없다
- 주소 변환을 이용하면 당연히 인터넷측에서 사내 LAN에는 액세스할 수 없게 된다.
- 따라서 사내 LAN에 대한 액세스를 금지하도록 패킷 필터링의 조건을 설정할 필요가 없다.
7. 방화벽을 통과한다
- 패킷이 도착하면 통과/차단 여부를 판정한 후 차단하는 대상이 되면 패킷을 버리고 버린 기록을 남긴다.
- 이는 버린 패킷 중에 부정 침입의 흔적을 나타내는 것이 있으므로 이것을 분석하여 침입자의 수법을 밝히거나 향후 부정 침입 대책에 도움이 될 수 있기 때문이다.
- 일단 통과시킨다고 결정되면 그 이상의 특별한 구조는 없다
8. 방화벽으로 막을 수 없는 공격
- 방화벽은 시점과 종점만 조사하므로 패킷 중에 특수한 데이터가 포함되어 있어도 이것에 신경쓰지 않고 패킷을 통과시켜 버린다.
복수 서버에 리퀘스트를 분해한 서버의 부하 분산
1. 처리 능력이 부족하면 복수 서버로 부하 분산된다
- 서버에 대한 액세스가 증가할때 대량의 패킷을 서버의 처리 능력이 따라잡지 못할 수도 있다.
- 이 때 복수의 서버를 사용하여 처리를 분담하는 분산 처리 방식을 사용할 수 있다.
DNS 서버에서 분배하는 방법
- 같은 이름으로 여러 대의 웹 서버를 등록해둔다.
이름 | 클래스 | 타입 | 응답 IP 주소 |
---|---|---|---|
www.lab.cyber.co.kr | IN | A | 192.0.2.60 |
www.lab.cyber.co.kr | IN | A | 192.0.2.70 |
www.lab.cyber.co.kr | IN | A | 192.0.2.80 |
- 이 때 조회 순서는 라운드 로빈 방법에 의해 정해진다.
- 고장난 웹 서버가 존재할 경우 보통 DNS 서버는 웹 서버가 동작하지 않는지 확인하지 못하므로 장애가 난 웹 서버의 IP 주소를 응답할 수도 있다.
2. 부하 분산 장치를 이용해 복수의 웹 서버로 분할된다
- DNS 서버에서 분배할 경우 문제점을 피하기 위해 로드밸런서가 고안되었다.
로드 밸런서
- DNS 서버에 웹 서버대신에 로드 밸런서를 등록한다.
- 로드 밸런서가 웹 서버를 선택하여 리퀘스트를 전송하는 방법은 다음과 같다.
- 단순 액세스인지 / 복수 페이지에 걸쳐있는 액세스인지
- 웹 서버의 부하량
- 복수 페이지에 걸쳐있을 경우 웹 서버의 부하와 상관없이 이전의 리퀘스트와 같은 웹 서버에 전송한다.
- 이 전후 관계를 판단하기 위해서 HTTP 사양을 확장하여 HTTP 헤더 필드에 부가하는 방법이 있다. 따라서 부하 분산 장치는 이러한 정보를 조사하여 해결한다.
캐시 서버를 이용한 서버의 부하 분산
1. 캐시 서버의 이용
- 캐시 서버를 이용하는 것은 데이터베이스 서버와 웹 서버 같은 역할에 따라 서버를 나누는 방법 중 하나이다.
- 캐시 서버는 프록시라는 구조를 사용하여 데이터에 캐시(디스크에 저장한 데이터)를 저장하는 서버이다.
- 캐시 서버는 웹 서버로부터 받아 저장해둔 데이터를 읽기만 해서 클라이언트에 송신하므로 웹 서버에서 송신하는 것보다 빠르게 데이터를 송신할 수 있다. 단, 웹 서버에서 데이터가 변경된다면 캐시에 저장된 데이터는 쓸모없는 데이터가 된다. 그렇기 때문에 언제든지 캐시의 데이터를 이용할 수 있는 것은 아니다.
2. 캐시 서버는 갱신일로 콘텐츠를 관리한다
캐시 서버의 동작
- 캐시 서버를 웹 서버 대신 DNS 서버에 등록한다.
- 클라이언트가 캐시 서버에 HTTP 리퀘스트 메시지를 보낸다.
- 캐시 서버가 받아 접속을 기다리는 패킷을 만들고 클라이언트가 접속하면 접속 동작을 실행하여 리퀘스트 메시지를 받는다.
- 캐시 서버는 리퀘스트 메시지의 내용을 조사해 데이터가 자신의 캐시에 저장되었는지를 조사한다.
캐시에 데이터가 없는 경우
- 클라이언트에서 캐시 서버에 보낸 리퀘스트
1 2 3 4 5 6 7
GET /dir1/sample.htm HTTP/1.1 Accept: */* Accept-Language: ja Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 Host: www.lab.cyber.co.kr Connection: Keep-Alive
- 캐시 서버에서 웹 서버에 전송한 리퀘스트의 내용
- 캐시 서버를 경유한 것을 나타내는 헤더 필드를 추가하고 URI에서 전송 대상을 판단하여 전송한다.
1 2 3 4 5 6 7 8
GET /dir1/sample1.htm HTTP/1.1 Accept: */* Accept-Language: ja Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 Host: www.lab.cyber.co.kr Connection: Keep-Alive Via: 1.1 proxy.lab.cyber.co.kr // 캐시 서버를 경유한 사실을 웹 서버에 알리기 위한것
- 캐시 서버를 경유한 것을 나타내는 헤더 필드를 추가하고 URI에서 전송 대상을 판단하여 전송한다.
- 웹 서버에서 캐시 서버에 반송한 응답의 내용
- If-Modified-Since를 추가하지 않은 경우 (캐시에 데이터가 없는 경우) 또는 웹 서버 측에서 변경된 경우 웹 페이지의 데이터가 그대로 되돌아 온다. ``` HTTP/1.1 200 OK Date: Wed, 7 Oct 2020 13:00:00 GMT Server: Apache Last-Modified: Wed, 30 Sep 2020 13:00:00 GMT ETag: “5a9da-27903c726b61” Accept-Ranges: bytes Content-Length: 632 Connection: close Content-Type: text/html
- 캐시 서버에서 클라이언트에 전송한 응답의 내용
- 캐시 서버를 경유한 것을 나타내는 Via 헤더가 붙어있다. ``` HTTP/1.1 200 OK Date: Wed, 7 Oct 2020 13:00:00 GMT Server: Apache Last-Modified: Wed, 30 Sep 2020 13:00:00 GMT ETag: “5a9da-27903c726b61” Accept-Ranges: bytes Content-Length: 632 Connection: close Content-Type: text/html Via: 1.1 proxy.lab.cyber.co.kr // 프록시를 경유한 사실을 알리기 위한 것
캐시 서버에 저장된 캐시가 있을 경우
- 캐시 서버에서 웹 서버에 전송한 리퀘스트 내용
1 2 3 4
GET /dir1/sample1.htm HTTP/1.1 ... If-modified-Since: Wed, 21 Sep 2020 10:25:52 GMT // 웹 서버측에 데이터가 변경되었는지 확인 Via: 1.1 proxy.lab.cyber.co.kr
- 웹 서버에서 캐시 서버에 반송한 응답
1 2 3 4 5
HTTP/1.1 304 Not Modified Date: Wed, 7 Oct 2020 13:00:00 GMT Server: Apache ETag: "5a9da-27903c726b61" Connection: close
3. 프록시의 원점은 포워드 프록시이다
- 클라이언트 측에 캐시 서버를 두는 방법이다.
- 브라우저 설정 화면에 준비되어 있는 프록시 서버 항목에 포워드 프록시의 IP 주소를 설정한다.
- 브라우저에 입력한 URL과 상관 없이 리퀘스트를 전부 포워드 프록시로 보낸다.
- 클라이언트에서 캐시 서버에 보낸 리퀘스트 내용
1 2
GET http://www.lab.cyber.co.kr/sample3.htm HTTP/1.1 ...
4. 포워드 프록시를 개량한 리버스 프록시
- 브라우저에서 프록시를 설정할 경우 그 설정이 번거로우므로 서버 측에 설치하는 캐시 서버를 사용하게 되었고 이를 리버스 프록시라고 한다.
5. 트랜스페어런트 프록시
- 캐시 서버에서 전송 대상을 판단하는 방법 즉 리퀘스트 메시지에서 패킷의 헤더를 조사하여 액세스 대상 웹 서버가 어디 있는지 알 수 있는 방법이다.
콘텐츠 배포 서비스
1. 콘텐츠 배포 서비스를 이용한 부하 분산
- 서버측에 캐시 서버를 두는 방법은 웹 서버의 부하를 경감하는 효과는 있지만, 인터넷의 트래픽을 억제하는 효과는 없다.
캐시 서버 위치
- 웹 서버 직전에 캐시 서버를 두는 경우
- 웹 서버 운영자가 제어 O (웹 서버의 부하를 억제할 수 있다.)
- 인터넷의 트래팩을 억제 X
- 클라이언트 측에 캐시 서버를 두는 경우
- 웹 서버 운영자가 제어 X
- 인터넷의 트래픽을 억제 O
- 인터넷 주위에 캐시 서버를 두는 경우 (프로바이더 측)
- 웹 서버 운영자가 제어 O
- 인터넷의 트래픽을 억제 O
- 프로바이더와 계약하여 웹 서버 운영자가 제어할 수 있는 캐시 서버를 클라이언트측의 프로바이더에 두는 방법
- 콘텐츠 배포 서비스 : 캐시 서버를 설치하고 웹 서버 운영자에게 대출하는 서비스
- CDSP : 이러한 서비스를 제공하는 사업자
2. 가장 가까운 캐시 서버의 관점
DNS 서버의 기본 동작
- 클라이언트는 자신의 LAN에 있는 DNS 서버에 조회 메시지를 보낸다.
- DNS 서버는 웹 서버 이름 계층 구조를 조사하여, 웹 서버측에 있는 DNS 서버를 찾아 조회 메시지를 보낸다
- 대응표를 조사하여 IP 주소를 회답한다.
- 클라이언트 측 DNS 서버에 도착하여 클라이언트측에 회답이 돌려진다.
기본 동작만 살펴본다면 클라이언트측과 캐시 서버의 위치 관계를 전혀 고려하지 않고 라운드 로빈을 이용해 차례대로 IP 주소를 회답하기만 하므로 먼 위치에 있는 캐시 서버의 IP 주소를 돌려줄 수도 있다.
클라이언트와 캐시 서버의 거리를 판단하는 방법
1. 라우터 경로표 이용
- 캐시 서버의 설치 장소에 있는 라우터에서 경로 정보를 모아둔다.
- 이 경로표를 사용하여 DNS의 조회 메시지의 송신처 즉 클라이언트 측의 DNS 서버에 이르는 경로 정보를 조사한다.
- 이 경로표를 이용하여 클라이언트측의 DNS 서버에서 캐시서버까지의 경로정보를 알 수 있다. (어느 라우터가 클라이언트와 가장 가까운지 판단할수 있다)
- 클라이언트 DNS 서버와 캐시서버와의 거리이므로 정확한 거리는 아니지만 어느정도 정확하게 거리를 측정할 수 있다.
2. Location 헤더 이용
- 리다이렉트용 서버를 두고 이 서버를 DNS에 등록한다.
- 리다이렉트용 서버에는 라우터에서 모은 경로 정보가 있으며 여기에서 가장 가까운 캐시 서버를 찾는다.
- 캐시 서버를 나타내는 Location 헤더를 설정하여 응답을 보낸다.
This post is licensed under CC BY 4.0 by the author.