Gunicorn: http 응답 헤더 서버 속성을 마스킹하는 기능

일반적으로 gunicorn은 프로덕션 환경에서 nginx와 같은 리버스 프록시 서버 뒤에 배포되며 nginx는 자체 Server 태그를 출력합니다.

위층 플러스 하나

@benoitc 를 사용하여 명령줄에서 옵션을 제안할 수 있습니다. 어떻게 생각하세요? 그렇지 않으면 @georgexsh 에서 설명한 대로 이 티켓을 닫을 것입니다. 프로덕션 모드에서는 역방향 프록시(nginx, apache, ...)를 사용할 수 있습니다.

post_request 후크에서 환경을 수정할 수 없습니까?

@tilgovi 가 작동하는 것 같군요... 그렇다면 다른 옵션을 만들어야 하는지 확실하지 않습니다...

작동하지 않습니다. 요청은 해당 지점에서 이미 전송되었습니다.

@tilgovi 미들웨어도 작동하지 않습니다. Server 가 기본 헤더에 있기 때문입니다.

서버 헤더를 완전히 제거하면 어떻게 될까요?

+1

헤더 값을 임의의 문자열로 설정할 수 있다면 헤더를 완전히 제거할 수도 있습니다.

+1

헤더를 제거하려는 이유는 무엇입니까?

과거에는 서버 소프트웨어 및 버전을 숨기기 위해 배포에서 헤더를 제거하여 알려진 익스플로잇이 있는 서버를 크롤링하는 사람이 선택하지 않도록 했습니다.

예. 보안이 이유 중 하나입니다. 물론 Server 값을 임의의 값으로 변경할 수 있지만 실제로 필요하지 않은 추가 바이트를 보내는 이유는 무엇입니까?

나는 이 기능에 대한 홍보를 자유롭게 했습니다: #1384 . 그것은 한동안 내 희망 목록에있었습니다.

토론에 추가하려면: 일부 역 프록시 서버는 Server 헤더를 수정하지만 일부는 https://www.w3.org/Protocols/에 설명된 대로 Via 헤더를 추가한다고 주장합니다. rfc2616/rfc2616-sec14.html#sec14.38

불행히도 @mathiasverhoeven 은 어떤 이유로 PR을

헤더의 양을 키-값 쌍으로 지정할 수 있는 --set-headers 에서와 같이 여기에 더 일반적인 옵션을 갖는 것이 불가능합니까? 빈 값은 헤더를 완전히 생략합니다.

현재 Server 를 조정하고 싶지만 X-Product: MyProduct 와 같은 응답 헤더를 하나 더 추가하고 싶습니다.

@mathiasverhoeven 의 PR 을 기반으로 무언가를 함께 던질 수 있습니다. @benoitc 와 @tilgovi 어떻게 생각하세요?

https://www.fastly.com/blog/headers-we-dont-want에 이것을 남겨 둡니다 Server 헤더는 매우 일반적이고 완전히 불필요합니다.

또한 Server 헤더를 생략할 수 있기를 바랍니다. 나는 Hiawatha라는 보안 중심 웹 서버를 사용하여 자체 서버 헤더를 추가하지 않도록 설정하여 역 프록시를 사용하므로 gunicorn의 Server 헤더가 현재 클라이언트에 전달되고 있습니다.

@tuukkamustonen 의 아이디어는 나에게 좋게 들립니다. :)

편집: 방금 https://github.com/benoitc/gunicorn/pull/1617을 보았습니다 server_tokens = true|false|string 은(는) 좋습니다.

플라스크를 실행하는 사람이 있습니까? https://stackoverflow.com/a/46858238/452210 은 process_response 래핑 및 재정의를 제안하고 헤더를 교체하거나 제거합니다.

또한 Server 헤더를 생략할 수 있기를 바랍니다. 나는 Hiawatha라는 보안 중심 웹 서버를 사용하여 자체 서버 헤더를 추가하지 않도록 설정하여 역 프록시를 사용하므로 gunicorn의 Server 헤더가 현재 클라이언트에 전달되고 있습니다.

나는 심지어 cloudflare가 서버 헤더를 표시하고 있다는 것을 알아차렸고, 그래서 요즘은 명성보다 보안이 더 중요한지 잘 모르겠습니다.

명령줄이나 구성에 다른 옵션을 추가하는 대신 헤더에서 버전을 제거하기만 하면 됩니다. 그런 다음 구성 파일 전용 설정을 추가하여 server_token을 제거하십시오. 그것의 장점은 새 버전으로 정상적으로 업그레이드하는 서버가 서비스를 중지하지 않고 해당 설정을 추가할 수 있다는 것입니다. 생각?

나는 심지어 cloudflare가 서버 헤더를 표시하고 있다는 것을 알아차렸고, 그래서 요즘은 명성보다 보안이 더 중요한지 잘 모르겠습니다.

Cloudflare의 서비스 및 서버 헤더는 개별 사이트의 서버와 다른 컨텍스트를 가지고 있다고 생각합니다. 사이트가 Cloudflare를 통해 역 프록시되는 경우 프록시를 수행하는 것이 Cloudflare라는 사실은 달리 알려지지 않았습니다. 그것은 네임서버 및/또는 IP 주소 등을 통해 명백합니다. 대조적으로 제3자 역방향 프록시가 없는 VPS에서 사이트를 호스팅하는 것은 잠재적으로 서버 소프트웨어의 HTTP 헤더를 통한 직접적인 식별을 피할 수 있다는 희망을 줍니다. (물론 gunicorn이 미래에 취약점이 있는 것으로 밝혀지면 단순히 서버 헤더를 검색하는 것보다 표적을 찾는 것이 더 어려울 것이라고 생각합니다.)

명령줄이나 구성에 다른 옵션을 추가하는 대신 헤더에서 버전을 제거하기만 하면 됩니다. 그런 다음 구성 파일 전용 설정을 추가하여 server_token을 제거하십시오. 그것의 장점은 새 버전으로 정상적으로 업그레이드하는 서버가 서비스를 중지하지 않고 해당 설정을 추가할 수 있다는 것입니다. 생각?

정말 좋을 것입니다. :+1: :약간_웃는_얼굴:

예, 최소한 버전을 제거하십시오. 버전은 명성에 아무 것도 추가하지 않으며 공격자에게 많은 시간을 절약합니다.

버전을 제거할 생각입니다. @tilgovi 그것에 대해 어떤 생각이 있습니까?

나를 위해 좋아!

이것에 진전이 있습니까? 이것은 보안을 위한 빠른 승리처럼 보입니다.

그것은 다음 20.1의 일부가 될 것입니다

버전을 제거할 생각입니다.

서버 헤더를 완전히 제거하는 구성 파일 전용 설정이 아직 계획되어 있습니까?

@DavidOliver 왜 질문

@benoitc 내가 인용한 귀하의 의견은 "그냥"/제거될 버전 번호만 의미하는 것으로 해석될 수 있는 반면, 대화 초반에 서버 헤더를 완전히 제거하는 설정(제가 하고 싶습니다)은 고려 중입니다.

감사 해요.

서버 헤더를 완전히 제거할 수 있다면 그렇게 해야 합니다.

나는 그것을 제거하는 것이
보안. 지난 10년 동안 문제가 되지 않았습니다. 보안
모호함도 도움이 되지 않습니다. 문제가 있다는 것을 알고 싶습니다.
그것을 고친다. 또한 서버를 알면 작업에 도움이 될 수 있습니다.

이 버전이 제공하는 현재 버전을 제거하는 경향이 있습니다.
서버 유지 관리 방법에 대한 정보가 너무 많습니다. 우리는 그것을해야합니다
우리가 유지 한 각 지점.

생각?

베누아

2019년 12월 29일 일요일 04:23 Randall Leeds [email protected]에서 다음과 같이 썼습니다.

서버 헤더를 완전히 제거할 수 있다면 그렇게 해야 합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/benoitc/gunicorn/issues/825?email_source=notifications&email_token=AAADRIQBGN2KQRKOKLAYK43Q3AJ2PA5CNFSM4ASCOWF2YY3PNVWWK3TUL52HS4DFVREXG43VMXHJ63LNMV
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAADRISEUFGD43CKXLV3EZTQ3AJ2PANCNFSM4ASCOWFQ
.

>

내 모바일에서 보낸

안녕,

데이터가 있는 연결을 통해 응답을 제공하기 위해 gunicorn을 사용하고 있습니다.
비싸고, 내가 제거할 수 있는 것은 내가 지불할 필요가 없는 것입니다.

서버 헤더는 작지만 작은 것이 추가되고 때로는
작은 것은 원리스 패킷에 모든 것을 담을 수 있음을 의미합니다.
버전이 있는 서버 헤더는 페이로드의 약 1.7%인 24바이트입니다.
1460의 MSS 및 TLS 헤더를 사용합니다. 추가 패킷 없이도
더 큰 패킷은 완전히 재전송해야 할 가능성이 훨씬 더 높습니다.
연결이 좋지 않을 때(원격 장소에 있는 셀룰러 네트워크와 같이).

새로운 HTTPS 연결에서 핸드셰이크 및 인증서
교환은 페이로드를 최대한 활용하고 작은 것은
무시. 연결 유지, 중복을 사용하는 소규모 반복 요청의 경우
헤더는 요청/응답의 훨씬 더 큰 부분이 됩니다.

이것은 클라이언트를 더 중요하게 생각하는 사람들에게도 중요할 수 있습니다.
비용보다 성능(처리량보다 대기 시간이 많음).

이 사용 사례의 경우 가장 유용한 옵션은
단순히 값을 제거하는 것이 아니라 헤더를 완전히 제거하십시오.
또는 버전 부분.

이 의견은 대부분 관련 참조/사양/RFC 정보를 추가하는 것으로 제한되며 (바라건대) 대부분 의견이 없는 해석/주석입니다.

RFC7231 하이퍼텍스트 전송 프로토콜(HTTP/1.1): 의미 및 콘텐츠 https://tools.ietf.org/html/rfc7231#section -7.4.2

...원본 서버는 응답에서 서버 필드를 생성할 수 있습니다(MAY).

원본 서버는 불필요하게 세분화된 세부 정보를 포함하는 서버 필드를 생성해서는 안 되며 제3자의 하위 제품 추가를 제한해야 합니다(SHOULD). 지나치게 길고 상세한 서버 필드 값은 응답 대기 시간을 증가시키고 공격자가 알려진 보안 허점을 (약간) 더 쉽게 찾고 악용할 수 있는 내부 구현 세부 정보를 잠재적으로 드러냅니다.

https://tools.ietf.org/html/rfc7231#section -9.6

9.6. 제품 정보 공개
User-Agent(섹션 5.5.3), Via([RFC7230]의 섹션 5.7.1) 및 Server(섹션 7.4.2) 헤더 필드는 종종 각각의 발신자의 소프트웨어 시스템에 대한 정보를 나타냅니다. 이론적으로 이것은 공격자가 알려진 보안 허점을 더 쉽게 악용할 수 있도록 합니다. 실제로 공격자는 사용 중인 명백한 소프트웨어 버전에 관계없이 모든 잠재적인 허점을 시도하는 경향이 있습니다. 네트워크 방화벽을 통해 포털 역할을 하는 프록시는 방화벽 뒤에 있는 호스트를 식별할 수 있는 헤더 정보 전송과 관련하여 특별한 예방 조치를 취해야 합니다. Via 헤더 필드를 사용하면 중개자가 민감한 시스템 이름을 가명으로 바꿀 수 있습니다.

(더 이상 사용되지 않음) RFC2616에서:

15.1.2 민감한 정보의 전송
일반 데이터 전송 프로토콜과 마찬가지로 HTTP는 전송되는 데이터의 내용을 조절할 수 없으며 주어진 요청의 컨텍스트 내에서 특정 정보의 민감도를 결정하는 선험적 방법도 없습니다. 따라서 응용 프로그램은 해당 정보 제공자에게 가능한 한 이 정보에 대한 많은 제어를 제공해야 합니다(SHOULD). 4개의 헤더 필드는 이 컨텍스트에서 특별히 언급할 가치가 있습니다: Server, Via, Referer 및 From.
서버의 특정 소프트웨어 버전을 공개하면 서버 시스템이 보안 허점을 포함하는 것으로 알려진 소프트웨어에 대한 공격에 더 취약해질 수 있습니다. 구현자는 서버 헤더 필드를 구성 가능한 옵션으로 만들어야 합니다(SHOULD).

PEP3333 Python 웹 서버 게이트웨이 인터페이스 v1.0.1 https://www.python.org/dev/peps/pep-3333/#the -start-response-callable

일반적으로 서버 또는 게이트웨이는 올바른 헤더가 클라이언트에 전송되도록 할 책임이 있습니다. 애플리케이션이 HTTP(또는 유효한 기타 관련 사양)에 필요한 헤더를 생략하는 경우 서버 또는 게이트웨이는 헤더를 추가해야 합니다. 예를 들어 HTTP Date: 및 Server: 헤더는 일반적으로 서버 또는 게이트웨이에서 제공합니다.

• 서버 응답 헤더는 HTTP 1.1에 따라 선택 사항입니다.
• RFC는 지나치게 상세한 서버 필드가 사이트에서 취약한 서버를 검색하는 것을 더 쉽게 만들 수 있음을 인식합니다. 분명히 이것은 한 단계 더 어렵게 만드는 모호한 조항이며, 세부 사항이 너무 많은 것은 상황에 따라 다릅니다.
• 더 이상 사용되지 않는 HTTP 1.1 RFC2616은 서버 헤더를 숨기는 값이 조금 더 굵습니다.
• PEP3333은 필수 또는 일반 헤더의 컨텍스트에서 Server 헤더를 언급할 때 약간 과도하게 지나치는 것 같습니다.

Apache HTTPD ServerTokens 와 같은 이에 대한 많은 의견: https://httpd.apache.org/docs/2.4/mod/core.html#servertokens

ServerTokens를 최소값 미만으로 설정하는 것은 상호 운용성 문제를 디버그하기 어렵게 만들기 때문에 권장되지 않습니다. 또한 Server: 헤더를 비활성화해도 서버 보안이 강화되지 않습니다. "암호를 통한 안보"라는 생각은 신화이며 잘못된 안전 의식으로 이어집니다.

서버 헤더를 gunicorn 로 변경하는 것은 실용적인 솔루션이며 구성 없이 그렇게 해야 한다고 생각합니다.

모든 전송의 크기를 최적화하려는 @kmichel-sereema와 같은 사람들은 여기가 그런 미세 최적화를 수행하는 곳이 아니라고 생각합니다. HTTP 헤더가 너무 많은 오버헤드라면 HTTP 1.x는 사용하기에 이상적인 프로토콜이 아니며 서버 헤더를 변경하거나 비활성화할 수 있도록 추가 구성을 추가해야 한다고 생각하지 않습니다.

@tilgovi 의 제안은 나에게 좋은 절충안처럼 보입니다.

많은 환경에서 이것은 심지어 무의미할 수도 있습니다. gunicorn 배포 문서 에서는 gunicorn 앞에 nginx와 같은 프록시 서버를 서버 응답 헤더 를

@tilgovi & @jamadden의 제 제안과 의견에 따라 #2233에 대한 이 호의를 종료합니다. 코드와 의견에 감사드립니다!