제 웹사이트는 Discourse를 사용하고 있습니다. 처음에는 Cloudflare로 보호되지 않아 DDoS 공격을 받았습니다.
이후 IP 주소를 변경하고 Cloudflare를 적용했지만, 원본 서버 IP가 유출된 것으로 추정되는 DDoS 공격을 다시 받았습니다.
Cloudflare CDN을 사용할 때 원본 서버 IP 유출을 방지하는 방법은 무엇인가요? 좋은 방법이 있으신 분이 계신가요? 감사합니다.
제 웹사이트는 Discourse를 사용하고 있습니다. 처음에는 Cloudflare로 보호되지 않아 DDoS 공격을 받았습니다.
이후 IP 주소를 변경하고 Cloudflare를 적용했지만, 원본 서버 IP가 유출된 것으로 추정되는 DDoS 공격을 다시 받았습니다.
Cloudflare CDN을 사용할 때 원본 서버 IP 유출을 방지하는 방법은 무엇인가요? 좋은 방법이 있으신 분이 계신가요? 감사합니다.
잘 모르겠지만, 온라인에 있는 모든 서버의 IP 주소는 생성되는 동시에 동시에 유출됩니다.
다음과 같이 하면 누출을 많이 방지할 수 있습니다
HTTPS_PROXY 및 HTTP_PROXY 환경 변수를 설정하여 Discourse가 이를 사용하도록 합니다(app.yml의 env 섹션에서 설정).NO_PROXY='127.0.0.1, localhost, <internal-network>'를 설정합니다.다음 링크도 참고하세요: Install discourse with internet access only via proxy, Configuration outbound proxy, Discourse Link previews through a proxy server? - #14 by supermathie
또한, Cloudflare(CF) 뒤에서 작업하는 경우, Discourse 호스트의 방화벽을 수정하여 Cloudflare IP(그리고 사용자가 직접 접근하는 호스트)에서만 수신 트래픽을 허용하도록 설정할 수 있습니다.
이것이 해결책입니다. 불명확성에 의한 보안은 안전하지 않습니다. 그렇게 하면 IP 주소가 공개된 정보여도 문제가 되지 않습니다.
이 방법 또는 더 간단한 방법으로 클라우드 터널(Cloudflare Tunnel)을 사용하는 것이 있습니다. 일회성 설정을 마치면 수신 연결에 대한 방화벽을 대부분 닫아둘 수 있습니다.
저는 얼마 전에 이 방식을 적용했습니다(제가 언급한 프록시 설정은 제외하고요). 이 방법이 모든 방화벽에 적용되는지는 잘 모르겠습니다(혹은 제 환경 설정의 문제일 수도 있고요).
하지만 제 경우 ufw를 사용하는데, Docker는 기본적으로 ufw를 우회하므로 내부 Docker IP에도 규칙을 적용해야 한다는 점을 언급할 가치가 있습니다.
오래된 이야기라 세부 사항은 정확하지 않지만, 이번 주 후반에 여전히 도움이 필요하시면 자세히 살펴볼 수 있습니다.
그리고 네, Cloudflare 터널은 정말 훌륭합니다! @itsbhanusharma
VPS 제공업체가 제공하는 방화벽을 사용해야 합니다. 호스트 기반 방화벽을 사용하면 트래픽이 네트워크 스택에 도달하기 때문에 DDoS 공격을 방어하는 데 훨씬 효과적이지 않습니다.
대부분의 대형 프로바이더가 기본적으로 DDoS 보호를 제공하지 않나요? 이 정도면 충분하지 않을까요? 인터페이스를 통해 CloudFlare IP를 수동으로 추가하는 것은 번거로워 보입니다(예를 들어, 제 커스텀 bash 스크립트는 2초 만에 CF IP를 자동으로 가져옵니다).
솔직히 말하면, 저는 보통 그 반대, 즉 프로바이더의 fw보다 ufw/로컬 fw를 선호한다는 이야기를 더 자주 듣습니다 ![]()
수정; 여기의 논리는 이해합니다. DDoS 관점에서 보면 이것이 더 효과적일 수 있고, 맞습니다. 하지만 그렇다고 해도, 메인 IP가 처음부터 올바르게 숨겨진다면 DDoS는 문제가 되지 않아야 하지 않나요?
요즘은 대부분의 프로바이더가 이를 위한 API를 제공하지 않나요?
맞습니다! 하지만 그것은 꽤 큰 '만약’이긴 합니다…
사실 그건 틀렸습니다. IP가 절대 숨겨지지 않는다는 이유만으로 그런 결론을 내릴 수는 없으니까요. 리버스 프록시나 유사한 도구가 DDoS 공격을 차단할 수 있는 한, DDoS는 큰 문제가 되지 않습니다. 그리고 실제로 공격이 발생하더라도 엔트리 레벨 솔루션만으로는 부족하며 더 많은 것이 필요합니다. 또한 봇이나 슬레이브 사용자가 닫힌 포트나 IP 제한된 포트를 노크하는 정도라면 그렇게 큰 문제가 아닙니다. 저는 이를 워드프레스 세계에서 또 다른 수요일이라고 부르겠지만, 디스커스는 여러 면에서 전혀 다른 세계입니다.
반면에, 저는 이 분야에 전문가가 아닙니다.
하지만 궁금한 점이 있습니다… DDoS 공격이 성공하려면 얼마나 많은 트래픽이 필요할까요? 물론 셋업의 리소스에 따라 다르겠지만, 몇 가지 수치를 알려주실 수 있을까요?
숨겨진의 정의에 따라 다릅니다. 네, 모든 IP 주소는 공개되어 있습니다. 하지만 그렇다면 40억 개의 IP 주소 중 어느 것이 올바른 것일까요? 저는 이 논의의 맥락에서, 특정 Discourse 포럼을 서비스하는 서버의 IP 주소를 결정할 수 있는 방법이 없다면(즉, 호스트의 실제 IP 주소를 반환하는 함수 f(h)가 결정되지 않았다고 보면) 그 IP는 숨겨진 것으로 간주할 수 있다고 생각합니다.
주어진 조건:
하지만 "hidden(숨겨진)"이라는 용어는 혼란스럽고 부정확하다고 동의합니다. "unknown(알 수 없는)"이 더 나은 표현일 것입니다.
DDoS의 유형에 따라 다릅니다. 애플리케이션 레이어 공격의 경우 이것이 사실일 수 있지만, 요청 검사(rate limiting)가 필요하므로 구현하기가 어렵습니다. 하지만 네트워크 레이어 공격(증폭이나 SYN 공격을 통한 단순 트래픽 범람)의 경우 이것이 성립하지 않을 수 있습니다. 또한, 기본적으로 말씀하시는 내용은 "완화할 수 있다면 문제가 아니다"라는 것으로, 이는 당연한 말이지만 실제로는 어렵고/또는 비용이 많이 듭니다.
공격의 유형에 따라 다릅니다. 애플리케이션 레이어 공격은 Discourse에 맞게 조정되어야 하지만, 예를 들어 검색과 같은 무거운 쿼리를 실행하여 애플리케이션 서버를 압도할 수 있습니다. 반면 네트워크 레이어 공격은 더 범용적일 수 있으며, 더 많은 트래픽을 필요로 하고 단순히 nginx나 VPS 네트워크를 막을 수 있습니다.