역프록시

Reverse proxy
A proxy server connecting the Internet to an internal network.
시나리오 예: 인터넷상의 클라이언트(왼쪽 클라우드)가 역방향 프록시 서버(중앙의 빨간색 타원형)에 요청을 한다. 프록시는 요청을 검사하고, 요청이 유효하며, 요청된 리소스가 자체 캐시에 없는지 판단한다. 그런 다음 요청을 내부 웹 서버(오른쪽)에 전달한다. 내부 서버는 요청된 리소스를 다시 프록시로 전송하고, 프록시는 이를 클라이언트로 전달한다. 인터넷상의 클라이언트는 내부 네트워크를 알지 못하며, 프록시와 통신하는지 웹 서버와 직접 통신하는지 알 수 없다.

컴퓨터 네트워크에서 역방향 프록시는 하나 이상의 서버에서 클라이언트를 대신하여 리소스를 검색하는 프록시 서버의 일종이다. 그런 다음 이러한 리소스는 클라이언트로 반환되어 역방향 프록시 서버 자체에서 발생한 것처럼 나타난다.[1] 그것은 주로 하중의 균형을 맞추기 위해 사용된다.

대형 웹 사이트와 콘텐츠 전송 네트워크는 내부 서버 간의 부하 균형을 맞추기 위해 다른 기술과 함께 역방향 프록시를 사용한다. 역방향 프록시는 정적 컨텐츠의 캐시를 유지할 수 있으며, 이것은 이러한 내부 서버와 내부 네트워크의 부하를 더욱 감소시킨다. 역방향 프록시가 클라이언트와 역방향 프록시 사이의 통신 채널에 압축이나 TLS 암호화 등의 기능을 추가하는 것도 일반적이다.[2]

역방향 프록시는 일반적으로 웹 서비스에 의해 소유되거나 관리되며, 공공 인터넷으로부터 클라이언트에 의해 액세스된다. 대조적으로, 포워드 프록시는 일반적으로 클라이언트를 대신하여 공공 인터넷으로부터 자원을 검색하도록 포워드 프록시에 요청할 수 있다는 점을 제외하고, 프라이빗 내부 네트워크로 제한되는 클라이언트(또는 그 회사)에 의해 관리된다.

역방향 프록시 서버는 Apache, Nginx, Caddy와 같은 인기 있는 오픈 소스 웹 서버에 구현된다. 이 소프트웨어는 HTTP 헤더를 검사할 수 있으며, 예를 들어, 단일 IP 주소로 HTTP 요청의 도메인 이름을 기반으로 다른 내부 서버로 요청을 릴레이할 수 있다. 오픈 소스 소프트웨어인 HAProxy와 Squid와 같은 전용 역방향 프록시 서버는 인터넷 상의 가장 큰 웹사이트에서 사용된다. 역방향 프록시 서버의 인기 있는 상업적 제공업체로는 Cloudflare와 임페르바가 있다.

사용하다

  • 역방향 프록시는 오리진 서버의 존재와 특성을 숨길 수 있다.
  • 애플리케이션 방화벽 기능은 DoS(서비스 거부 공격) 또는 분산 서비스 거부 공격(DDoS)과 같은 일반적인 웹 기반 공격으로부터 보호할 수 있다. 예를 들어 역방향 프록시가 없으면 악성코드를 제거하거나 테이크다운을 시작하는 것이 어려울 수 있다.
  • 보안 웹 사이트의 경우, 웹 서버는 TLS 암호화 자체를 수행하지 않고 대신 TLS 가속 하드웨어를 장착할 수 있는 역방향 프록시로 작업을 오프로딩할 수 있다. (TLS 종료 프록시 참조)
  • 역방향 프록시는 각 서버가 자체 응용 프로그램 영역을 지원하면서 수신 요청의 로드를 여러 서버로 분산시킬 수 있다. 역방향 프록시 웹 서버의 경우, 역방향 프록시는 요청된 자원의 관련 내부 위치에 일치시키기 위해 들어오는 각 요청의 URL을 다시 작성해야 할 수 있다.
  • 역방향 프록시는 웹 가속이라고 알려진 정적 콘텐츠와 동적 콘텐츠를 캐싱하여 오리진 서버의 로드를 줄일 수 있다. 이러한 종류의 프록시 캐시는 종종 상당한 수의 웹 사이트 요청을 충족시킬 수 있으며, 오리진 서버에 대한 부하를 크게 줄일 수 있다.
  • 역방향 프록시는 로딩 시간을 단축하기 위해 압축하여 콘텐츠를 최적화할 수 있다.
  • '스푼-피딩'[3]이라는 이름의 기법에서는 동적으로 생성된 페이지를 한꺼번에 제작해 역방향 프록시에 제공하면 한 번에 조금씩 고객에게 반환할 수 있다. 페이지를 생성하는 프로그램은 계속 열려 있을 필요가 없으므로, 클라이언트가 전송을 완료하는데 필요한 가능한 긴 시간 동안 서버 자원을 방출한다.
  • 역방향 프록시는 단일 공용 IP 주소를 통해 여러 웹 서버에 액세스할 수 있어야 하는 모든 곳에서 작동할 수 있다. 웹 서버는 동일한 로컬 IP 주소를 가진 동일한 시스템의 서로 다른 포트에서 수신하거나, 다른 로컬 IP 주소를 가진 서로 다른 시스템에서 수신한다. 역방향 프록시는 들어오는 각 요청을 분석하여 로컬 영역 네트워크 내의 올바른 서버로 전달한다.
  • 역방향 프록시는 JavaScript 태그나 코드를 페이지에 배치하지 않고 A/B 테스트와 다변량 테스트를 수행할 수 있다.
  • 역방향 프록시는 인증이 없는 웹 서버에 기본 HTTP 액세스 인증을 추가할 수 있다.[4]

위험

  • 역방향 프록시는 이를 통해 요청을 하는 모든 IP 주소를 추적할 수 있으며 암호화되지 않은 트래픽을 읽고 수정할 수도 있다. 따라서 암호를 기록하거나 악성코드를 주입할 수 있으며, 악의적인 당사자에 의해 손상되거나 실행될 경우 그렇게 할 수 있다.
  • 전송 트래픽이 암호화되고 역방향 프록시가 트래픽을 필터링/캐시/컴프레싱하거나 다른 방법으로 수정 또는 개선해야 하는 경우, 프록시는 먼저 통신을 해독하고 다시 암호화해야 한다. 이를 위해서는 프록시가 TLS 인증서와 그에 상응하는 개인 키를 보유해야 하므로, 암호화되지 않은 데이터에 접근할 수 있는 시스템의 수가 확대되고, 공격자의 더 가치 있는 대상이 된다.
  • 외부 데이터 침해의 대부분은 해커들이 조직에서 의도적으로 배치한 기존의 역방향 프록시를 악용하는 데 성공하거나, 해커들이 기존의 인터넷 대면 서버를 역방향 프록시 서버로 전환하는 데 성공했을 때 발생한다. 손상되거나 변환된 시스템을 통해 외부 공격자가 공격의 프록시를 지정할 수 있어 내부 네트워크 및 시스템에 대한 액세스가 가능하다.
  • 기업의 내부 사용을 위해 개발된 애플리케이션은 일반적으로 공공 표준으로 강화되지 않으며 모든 해킹 시도를 견뎌낼 수 있도록 설계되지 않는다. 조직이 역방향 프록시를 통해 이러한 내부 응용프로그램에 대한 외부 접근을 허용할 경우, 의도치 않게 자체 공격 표면을 증가시키고 해커를 초대할 수 있다.
  • 역방향 프록시가 공격을 필터링하도록 구성되지 않았거나 공격 서명 데이터베이스를 최신 상태로 유지하기 위해 매일 업데이트를 받지 않으면 제로 데이 취약성이 필터링되지 않은 상태로 통과하여 공격자가 역방향 프록시 서버 뒤에 있는 시스템을 제어할 수 있게 된다.
  • 제3자(예: Cloudflare, Imperva)의 역방향 프록시를 사용하면 프록시를 운영하는 제3자의 손에 기밀성, 무결성 및 가용성 3가지 전체를 맡긴다.
  • 역방향 프록시가 많은 다른 도메인 앞에 있는 경우, 그 중단(예: 잘못된 구성 또는 DDoS 공격)은 모든 프런트 도메인을 다운시킬 수 있다.[5]
  • 역방향 프록시는 또한 백엔드 서버에 직접 접근할 수 있는 다른 확실한 방법이 없는 경우 단일 장애 지점이 될 수 있다.

참고 항목

참조

  1. ^ "Forward and reverse proxies". The Apache Software Foundation. Retrieved 26 August 2018.
  2. ^ "Proxy servers and tunneling". MDN Web Docs. Retrieved 6 December 2020.
  3. ^ "squid-cache wiki entry on "SpoonFeeding"". Francesco Chemolli. Retrieved 9 February 2011.
  4. ^ "Possible to add basic HTTP access authentication via HAProxy?". serverfault.com.
  5. ^ "Cloudflare outage knocks out major sites and services, including Discord". finance.yahoo.com. Retrieved 14 December 2020.