Network ) 방화벽과 캐시서버

웹서버 설치

• 사내 LAN 에 직접 서버를 설치, 인터넷에서 직접 액세스
  • IP 주소 부족
  • 보안상의 이유
• 사내 LAN 과 인터넷 사이에 방화벽 두기
  • 특정 서버에서 동작하는 애플리케이션에 액세스하는 패킷만 통과, 그 외 패킷 차단
  • 액세스를 허가한 애플리케이션에 구멍이 있다면 공격받을 위험성 있음
• 데이터 센터에 웹 서버 설치
  • 데이터 센터에 서버를 설치하거나 프로바이더가 소유하는 서버를 빌려쓰는 형태
  • 인터넷 중심 부분에서 데이터 센터로 패킷이 흘러가고 서버 머신에 도착
  • NOC, IX 에 직결로 고속 액세스, 안정성, 관리 대신 해줌

→ 어떤 경우든 패킷은 라우터에서 중계 → 최종적으로 서버 도착

방화벽

특정 서버와 해당 서버 안의 특정 애플리케이션에 액세스하는 패킷만 통과, 그 외 패킷 차단

패킷 필터링형

조건을 설정하고 패킷을 필터링해서 특정 패킷 차단

• 패킷의 흐름에 착안
  • 수신처 IP 주소와 송신처 IP 주소에 따라 시점과 종점 판단
  • 수신처가 웹 서버 IP 주소와 일치하면 통과
• 웹 이외의 애플리케이션 패킷 전부 차단
  • TCP 헤더나 UDP 헤더 포트 번호를 조건으로 추가
  • 웹은 80번이니 80번인 패킷만 통과
• 웹 서버에서 인터넷측에 액세스하는 동작 정지하기 위해 액세스 방향을 판단
  • TCP 헤더에 컨트롤 비트를 확인
  • 실제로는 통과시키는 것과 차단하는 것을 완전히 선별할 수 없다 예) DNS 서버
  • UDP 는 TCP 와 달리 접속 단계가 없으므로 컨트롤 비트가 없음. 액세스 방향 판단 불가
  • 위험을 각오하고 전부 통과시키거나, 불편함을 감수하고 전면적으로 차단시켜야 함
• 사내 LAN 과 인터넷, 사내 LAN 과 공개 서버용 LAN 패킷 조건 설정
• 주소 변환 설정
  • 인터넷측에서 사내 LAN 에 액세스할 수 없으니 사내 LAN 패킷 필터링 조건 없어도 됨

 

 

✅ 패킷 필터링은 방화벽용의 특별한 구조가 아니라, 라우터 패킷 중계 기능 중 부가 기능이라고 생각하자!

 

 

 

 

 

방화벽으로 막을 수 없는 공격…

패킷의 내용을 조사하지 않으면 위험한지 판단할 수 없다. 만약 특수한 데이터를 포함한 패킷을 받으면 웹 서버가 다운된다면?

• 웹 서버 소프트웨어에 버그가 있으므로 버그를 고쳐서 다운되지 않도록 한다.
  • 보안 구멍 정보를 항상 새로운 버전으로 갱신한다.
• 패킷의 내용을 조사하여 위험한 데이터가 있는 경우에는 패킷을 차단하도록 한다.
  • 여러 대의 서버가 있는 경우 업데이트를 미루거나 잊어버릴 수 있으니 차라리 이게 효과적이다.

분산 처리

→복수의 서버를 사용하여 처리를 분담해 서버 한 대당 처리량을 줄이는 것.

• 서버에 액세스가 증가하면 회선을 빠르게 하는 것만으로 부족할 수 있다.
• 대량의 패킷을 서버의 처리 능력이 따라잡지 못할 수도 있다.
• 특히 CGI 등의 애플리케이션에서 페이지 데이터를 동적으로 만든다면 서버 머신의 프로세서 파워를 이용하기 때문에 더욱 중요하다.

방법

1. 여러 대의 웹 서버를 설치하고 한 대가 담당하는 사용자 횟수를 줄이는 방법.
   1. 클라이언트가 보내는 리퀘스트를 웹 서버에 분배해야 한다.
   2. DNS 서버를 이용한 라운드 로빈!

라운드 로빈

DNS 서버에 같은 이름으로 여러 대의 웹 서버를 등록해 놓으면 조회가 있을 때마다 차례대로 IP 주소를 되돌려줌. → 웹 서버가 정지해도 상관않고 IP 주소를 회답해버림 😅

1. 로드 밸런서 이용(부하 분산 장치)

로드 밸런서

1. 로드밸런서를 웹 서버 대신 DNS 서버에 등록한다. → 로드밸런서의 IP 주소를 DNS 서버에 등록한다.
2. 클라이언트가 웹 서버에 리퀘스트를 보내면 로드밸런서로 리퀘스트가 간다.
3. 로드밸런서가 다시 웹 서버에 리퀘스트를 전송한다.

어느 웹 서버에 리퀘스트를 전송해야 돼?

→ 대화가 복수 페이지에 걸쳐져있는지 판단해야 한다

• 복수의 페이지에 걸쳐져 있지 않은 단순한 액세스라면
  • 웹 서버의 부하 상태를 본다.
• 복수 페이지에 걸쳐져있을 때라면
  • 부하와 관계없이 이전 리퀘스트와 같은 웹서버에 전송한다.

HTTP Protocol 은 상태 정보를 저장하지 않는데 어떻게 판단해?

• 양식에 입력한 데이터를 보낼 때 그 안에 전후 관련을 나타내는 정보 부가
• 전후 관계를 판단하기 위한 정보를 HTTP 헤더에 부가함
  • 쿠키

캐시 서버

역할에 따라 서버를 나누는 방법, 프록시를 사용하여 데이터를 캐시에 저장하는 서버

• 액세스 동작의 일정 부분을 웹 서버를 들리지 않고도 캐시 서버에서 처리 가능
• 캐시 서버에서 리퀘스트를 처리하면 그만큼 웹 서버 부하가 줄어 웹 서버 처리 시간 단축 가능=

캐시 서버 동작

캐시서버를 웹 서버 대신 DNS 서버에 등록한다.

캐시가 저장되어 있지 않거나 데이터가 없다면

1. 캐시 서버가 리퀘스트 헤더에 ‘Via’ 필드 추가
2. 리퀘스트 메시지의 내용에 따라 전송 대상의 웹 서버 판단
   1. URI 에 쓰여있는 디렉토리
   2. /dir1/ 이라면 www1.aaa.com
   3. /dir2/ 라면 www2.aaa.com
3. 캐시서버가 클라이언트가 되어 웹 서버에 리퀘스트 메시지 전송
   1. 소켓을 만들고 웹 서버 소켓에 접속
4. 클라이언트에게 웹 서버가 되어 응답 메시지에 ‘Via’ 부가 후 응답 전송
5. 응답 메시지를 캐시에 저장하고 저장 일시 기록

→ 클라이언트와 웹 서버 사이를 중계하는 프록시 구조

캐시가 저장되어 있다면

1. 캐시 서버가 리퀘스트 헤더에 ‘If-Modified-Since’ 필드 추가 후 리퀘스트 전송
   1. 캐시에 있는 데이터 정보가 수정됐는지 확인하는 작업
2. 변경이 없다면 변경이 없다는 응답 메시지 반송
3. 응답 메시지를 클라이언트에게 보냄

포워드 프록시

클라이언트측에 캐시 서버를 두는 방법, 프록시의 원형

• 방화벽을 실현한다는 목적.
• 프록시에서 리퀘스트 메시지를 받아 인터넷에 전송하면 필요한 것을 통과시킬 수 있다.
• URL 내용에 상관없이 리퀘스트를 전부 포워드 프록시에 보냄
• 브라우저 설정이 반드시 필요
  • 설정이 번거롭고 브라우저가 제대로 작동하지 않을 수 있음 (장애의 원인)

리버스 프록시

서버 측에 설치하는 캐시 서버, 포워드 프록시의 단점인 브라우저 설정을 안 해도 되는 방법

• 리퀘스트 메시지 URI 에 쓰여있는 디렉토리명과 전송 대상의 웹서버를 대응
• 보통 리퀘스트 메시지와 똑같이 전송
  • GET /dir1/

트랜스페어런트 프록시

패킷 맨 앞에 있는 IP 헤더에 수신처 IP 주소를 확인하고 액세스 대상 웹 서버가 어딨는지 찾는 방법

1. 브라우저 설정 필요 없음
2. 전송 대상을 캐시 서버에 설정할 필요 없음
3. 어느 웹 서버나 전송 가능

구조

• 브라우저 ↔ 트랜스페어런트 프록시 ↔ 웹 서버

장점

• HTTP 메시지를 전송한다는 구조에 대한 관심이 적어진다.
• 캐시를 이용한다.

→ 사용 비중이 높다.

캐시 서버를 두는 장소

캐시 서버는 어느 장소에 두느냐에 따라 이용 효과가 차이난다.

• 서버 측
  • 웹 서버 부하 경감
  • 트래픽 억제 효과 없음
• 클라이언트 측
  • 인터넷 혼잡에 휘말려들지 않으니 패킷 흐름 안정
  • 웹 서버 운영자가 제어 불가능
  • 캐시서버 존재 유무도 확인 불가
• 클라이언트측의 프로바이더 (굿!)
  • 트래픽 억제 가능
  • 서버 운영자가 캐시 서버 제거 가능
  • 이것을 이용하려면 “콘텐츠 배포 서비스” 를 사용한다

콘텐츠 배포 서비스 CDS

캐시 서버를 설치하고 이것을 웹 서버 운영자에게 대출하는 서비스 캐시 서버의 수를 줄일 수 있고 서버측, 클라이언트측 캐시 서버 장점을 다 가져올 수 있다.

• 사업자 CDSP 는 중요한 프로바이더와 계약하고 다수의 캐시 서버를 설치
• 웹 서버 운영자와도 계약하여 웹서버와 CDSP 의 캐시 서버 연대

→ 웹 서버와 캐시 서버를 잘 연대시키면 클라이언트가 웹 서버에 액세스할 때 CDSP 의 캐시 서버에 액세스한다.

클라이언트가 캐시 서버의 거리를 판단하는 법

라우터 조사

1. 캐시 서버 설치 장소에 있는 라우터에서 경로 정보 모으기
2. 이 경로표를 사용해서 DNS 메시지 송신처, 즉 클라이언트측의 DNS 서버에 이르는 경로 정보 조사
3. 이것을 모든 라우터에 대해 조사하고 비교
4. 어느 라우터가 클라이언트측과 DNS 서버에 가장 가까운지 알 수 있음

Redirect

1. 리다이렉트용 서버를 웹 서버측의 DNS 서버에 등록
2. 클아이언트가 HTTP 리퀘스트 메시지 송신
3. 리다이렉트용 서버에는 DNS 서버처럼 라우터에서 모은 경로 정보가 있어서 가까운 캐시 서버 찾기
4. *Location 헤더를 붙여 응답을 돌려보냄 *Location 헤더 → 그 데이터는 이 쪽의 서버에 있으니 그 쪽으로 다시 엑세스하세요.
5. 클라이언트가 캐시 서버에 다시 액세스

• 단점
  • HTTP 메시지 대화 증가하여 Overhead 증가
• 장점
  • HTTP 메시지의 송신처 IP 주소를 바탕으로 거리를 판단하니 정밀도가 높다.

패킷 왕복 시간

패킷 왕복 시간을 통해 캐시 서버까지의 거리를 계산, 최적의 캐시 서버에 액세스하도록 스크립트 프로그램을 내장한 페이지 반송.

→ 클라이언트 스스로 최적의 캐시 서버 판단하고 액세스

캐시 내용 갱신

캐시 서버의 효율을 좌우하는 요소. 웹 서버에서 원래 데이터를 갱신할 경우 이것을 즉시 캐시 서버에 반영해야 한다.