CMS 지문 인식은 사이버 공간 검색 엔진의 도움으로 웹 사이트의 실제 IP를 찾기 위해 cdn을 우회합니다.

기타 2022-04-20 18:11:00 독서 시간: null

CMS 온라인 식별 도구

http://finger.tidesec.com/
https://fp.shuziguanxing.com/#/
http://whatweb.bugscaner.com/look/
여기에 이미지 설명 삽입
github 오픈 소스 도구
CMSeek-master
Webfinger-master
WhatWeb-master
여기에 이미지 설명 삽입

CDN이란 무엇입니까?

CDN의 전체 이름은 Content Delivery Network, 즉 Content Delivery Network입니다. CDN은 중앙 플랫폼의 로드 밸런싱, 콘텐츠 배포, 스케줄링 및 기타 기능 모듈을 통해 다양한 장소에 배치된 에지 서버에 의존하여 기존 네트워크를 기반으로 구축된 지능형 가상 네트워크로 사용자가 원하는 콘텐츠를 얻을 수 있습니다. 인접, 네트워크 혼잡 감소, 사용자 액세스 응답 속도 및 적중률 향상. CDN의 핵심 기술은 주로 콘텐츠 저장 및 배포 기술입니다.

직설적으로 말하면 동네 창고다.
여기에 이미지 설명 삽입

웹사이트에 CDN이 필요한 이유는 무엇입니까?

성능이 중요합니다. 웹 사이트에서 CDN을 사용하지 않는 경우 모든 사용자는 단일 서버에 요청을 보내야 합니다. 이렇게 하면 서버에 많은 부하가 걸리고 웹 사이트의 성능이 저하되기 때문입니다. 오늘날 대부분의 웹 사이트는 로딩 속도를 높이고 대역폭 비용을 줄이며 보안을 향상시키는 데 도움이 되기 때문에 CDN을 사용합니다.
CDN은 또한 다음과 같은 다양한 유형의 비즈니스 및 조직에 많은 특별한 이점을 제공합니다.

  1. 전자 상거래
  2. 정부
  3. 재원
  4. 미디어/출판
  5. 모바일 애플리케이션

CDN을 사용하면 어떤 이점이 있습니까?

여기에 이미지 설명 삽입

  1. 웹사이트 속도와 로드 시간을 개선합니다.
  2. 대역폭 비용을 줄입니다.
  3. 웹사이트 보안을 향상시킵니다.
  4. SEO 이점
  5. 트래픽 급증 및 확장성
  6. 더 높은 전환율
  7. 신뢰할 수 있음
  8. 등등
    . 따라서 좋은 성능과 안정적인 웹 사이트를 갖고 싶다면 CDN 사용을 고려해야 합니다.
    여기에 이미지 설명 삽입
    CDN을 사용하면 웹사이트의 콘텐츠를 요청하는 모든 사용자가 가장 가까운 CDN 에지 서버에서 캐시된 버전을 가져오므로 콘텐츠가 더 빨리 로드되고 웹사이트의 성능이 향상됩니다.

CDN 역 프록시

여기에 이미지 설명 삽입
역방향 프록시는 클라이언트 요청을 수신하여 백엔드 서버로 전달하는 서버입니다. 클라이언트와 원본 서버 자체 사이의 중간 서버입니다. CDN 역방향 프록시는 원본 서버에서 클라이언트로 응답을 다시 캐싱하여 이 개념을 한 단계 더 발전시킵니다. 결과적으로 CDN의 서버는 자산을 인근 방문자에게 더 빠르게 전달할 수 있습니다. 이 방법은 다음과 같은 이유에서도 이상적입니다.

로드 밸런싱 및 확장성
개선된 웹사이트 보안

CDN 보안과
여기에 이미지 설명 삽입
WAF CDN 자체는 악성 프로그램이 웹사이트를 감염시키는 것을 막지 못하고 CDN 자체가 취약하므로 WAF를 사용해야 합니다.
WAF 또는 웹 응용 프로그램 방화벽은 웹 응용 프로그램과 인터넷 간의 HTTP 트래픽을 필터링하고 모니터링하여 웹 응용 프로그램을 보호하는 데 도움이 됩니다.
일반적으로 XSS(교차 사이트 스크립팅), 파일 포함 및 SQL 삽입과 같은 공격으로부터 웹 응용 프로그램을 보호합니다.

웹사이트 소스 아이피

여기에 이미지 설명 삽입
많은 웹 사이트는 DDoS 공격 및 공격자가 수행할 수 있는 기타 악의적인 작업으로부터 공격자를 보호하기 위해 위의 보호 기능을 사용하여 원본 IP를 숨깁니다.
이러한 사이트의 대부분은 클라우드 기반 보안, 프록시 또는 DNS 기반 서비스를 사용하므로 원래 IP를 찾기가 약간 까다롭습니다.

웹 사이트의 원래 IP가 필요한 이유는 무엇입니까?

여기에 이미지 설명 삽입

답은 간단합니다. 웹사이트의 원래 IP가 있으면 CDN에서 제공하는 모든 보호 기능을 우회할 수 있습니다.

웹 사이트의 원래 IP를 찾는 방법

  1. 내부 사서함 소스, 내부 사서함 서버의 IP 주소 수집
  2. 웹사이트 phpinfo 파일 phpinfo.php
  3. 하위 사이트 IP 주소, 하위 도메인 CDN을 쿼리하는 데 비용이 많이 듭니다. 하위 사이트에서 더 이상 CDN을 사용하지 않을 가능성이 매우 높습니다.
  4. 해외에서 https://asm.ca.com/en/ping.php 방문

하위 도메인에 대한 도메인 이름 쿼리를 고려할 수 있습니다. 많은 경우 재정적 압박이나 예상치 못한 상황에서 많은 사이트가 종종 기본 사이트에서만 cdn을 구성하기 때문입니다.

쿼리 기록 IP

https://dnsdb.io/zh-cn dns 쿼리https:
//x.threatbook.cnWeibu Online
http://toolbar.netcraft.com/site_report?url=xxxOnline 도메인 이름 쿼리http:
//viewdns.info dnsip 쿼리
https: //tools.ipip.net/newping.php 글로벌 및 국가 핑
SecurityTrails history ip
는 스테이션을 마비시키기 위해 ddos를 사용합니다:
원리: 국내 CDN은 종종 가로채는 ddos ​​트래픽에 대해 요금을 부과합니다. 서버가 구매한 서비스 용량보다 큰 경우 이 때 cdn 운영자는 서비스 제공을 중단하고 모든 트래픽을 실제 IP로 전달합니다.

우리는 방어자가 원래 사이트를 보호하기 위해 무엇을 시도했는지에 대한 기본적인 이해를 가졌으며, 이러한 제한을 우회하고 원래 IP를 찾는 동안 사고 과정에서 수행할 작업에 대한 마인드 맵을 얻었습니다. 웹 서버

정찰

가장 중요한 부분은 가능한 한 많은 정보를 얻기 위해 기본적인 정찰을 하는 것입니다. 아이디어는 다음과 같은 유용한 정보를 찾는 것입니다.

  1. IP 범위/CIDR
  2. 호스트 관련 정보
  3. DNS 레코드
  4. 네트워크 서버
  5. 웹 호스팅
  6. 웹 서버와 동일한 서버에 있는 호스팅 서버(예: 메일 서버)
  7. 정보 공개 취약성

DNS 레코드 쿼리 기록 IP에 대한 모든 정보

DNS 레코드는 여러 위치에 기록을 저장합니다. 原来的IP地址이러한 과거 DNS 레코드에는 웹사이트 CDN 이 포함될 수 있습니다 .
앞서 언급했듯이 일부 웹 사이트에는 유용한 정보를 수집할 수 없는 잘못 구성된 DNS 레코드가 있을 수 있습니다.

SecurityTrails 웹사이트

SecurityTrails 를 사용하면 모든 인터넷 자산에 대한 전체 현재 및 과거 데이터를 탐색할 수 있습니다. IP 및 DNS 기록, 도메인, SSL 및 개방형 포트 인텔리전스.

A, AAAA, MX, NS, SOA 및 TXT 레코드에 대한 현재 및 과거 데이터를 찾을 수 있으므로 대상에 대한 간단한 쿼리를 수행하여 기록 데이터, 특히 DNS 레코드를 확인합니다.
이렇게 하면 웹 사이트가 서버의 IP에서 직접 실행되고 CDN으로 이동될 때 실제 서버의 IP를 쉽게 찾을 수 있습니다.

여기에 이미지 설명 삽입
DNS 레코드에는 원래 IP에 대한 정보가 포함되어서는 안 됩니다. SPF 및 TXT 레코드를 주의 깊게 살펴 원래 IP에 대한 정보가 포함되어 있는지 확인하십시오.
원본 서버를 가리키는 간단한 A, AAA, CNAME 또는 MX 레코드는 원본 IP를 노출합니다.
유사한 사이트는

MX 레코드에 대한 모든 것

MX 레코드는 메일 교환 레코드로, 메일 서버를 가리키며 이메일 시스템이 메일을 보낼 때 받는 사람의 주소 접미사에 따라 메일 서버를 찾는 데 사용됩니다.

MX 레코드는 원래 IP를 쉽게 찾을 수 있기 때문에 가장 선호되는 방법 중 하나입니다. 메일 서버가 웹 서버와 동일한 IP로 호스팅되는 경우 공격자는 발신 이메일에서 해당 IP 주소를 찾을 수 있습니다.
여기에 이미지 설명 삽입
메일 서버가 웹 서버와 동일한 IP에서 호스팅되는 경우 "비밀번호 재설정" 기능을 사용하는 또 다른 흥미로운 옵션이 있으므로 대상 웹사이트에서 계정을 생성한 다음 비밀번호 재설정을 사용하면 수신이 표시될 수 있습니다. 원본 서버 IP.

수신한 이메일에서 볼 수 있는 모든 IP 주소를 수집하고 수동으로 시도하여 서버의 원래 IP인지 확인해야 합니다. 예를 들어, 때때로 "return path" 값이 유용할 수 있습니다.

다음은 CDN 공급자/블루 팀 구성원이 웹사이트의 원본 IP를 숨기기 위해 수행하는 작업입니다.

모든 하위 도메인을 동일한 CDN에 유지
다른 하위 도메인을 사용하는 경우 정보 공개 취약성으로 이어질 수 있는 파일을 제공하여 원래 IP를 유출할 수 있으므로 루트 도메인에 비해 성공 확률이 더 높습니다.

사용자 작업을 기반으로 아웃바운드 연결을 시작하지 마십시오
. 웹 서버가 임의의 주소에 연결되도록 할 수 있으면 소스 IP가 표시됩니다. 사용자가 주어진 URL에서 사진을 업로드할 수 있는 "URL에서 업로드"와 같은 기능은 다운로드를 수행하는 서버가 웹사이트 원본 서버가 아니도록 구성되어야 합니다. 이는 공격자가 입력한 URL을 선택할 수 있는 경우 연결하는 사람을 모니터링하기 위해 특별히 웹사이트를 구축하거나 고유한 URL과 연결된 IP를 모니터링하는 공개 서비스를 사용할 수 있기 때문에 중요합니다.


CDN을 구성할 때 원래 IP DNS 레코드를 변경하면 여러 위치에 기록이 저장됩니다. 이러한 기록 DNS 레코드에는 웹 사이트 원본의 원래 IP 레코드 CDN이 포함됩니다.

IP를 사용하여 웹사이트에 대한 직접 액세스 제한
방어자에게 또 다른 흥미로운 옵션은 IP 주소를 사용하여 웹사이트에 액세스하려는 사용자를 제한하여 도메인 이름이 제공되는 경우에만 웹사이트가 로드되도록 하는 것입니다. Nginx에서 수행하는 방법을 살펴보겠습니다.

포트 80의 IP에 대한 직접 액세스를 비활성화/차단하기 위해 다음과 같이 새 서버 구성을 만듭니다.

server {
    
    
 listen 80 default_server;
 server_name _;
 return 404;
}

포트 443의 IP에 대한 직접 액세스를 비활성화/차단하려면 서버 구성 모듈 중 하나에서 다음 명령을 사용합니다.

if ($host != "example.com") {
    
    
 return 404;
}

예:

server {
    
    
 listen 443 ssl;
 server_name example.com
 
 ssl_certificate /etc/nginx/ssl/example.com.crt;
 ssl_certificate_key /etc/nginx/ssl/example.com.key;

 if ($host != "example.com") {
    
    
  return 404;
 }
}

이것은 https://your ip에 대한 모든 트래픽을 차단합니다.

우리는 이 제한을 우회하는 흥미로운 방법에 대해 논의할 것입니다.

CDN의 요청만 화이트리스트 에 추가하는 가능한 솔루션
은 CDN을 화이트리스트에 추가하는 것입니다. 이 접근 방식은 유망해 보이고 방어자가 원본 서버를 숨길 수 있기에 충분하기 때문입니다. 그들은 작동할 수 있습니다:

옵션 A: IP 주소를 화이트리스트에 추가

IP 주소를 화이트리스트에 추가할 때의 문제는 원본에 도달할 수 있는 모든 CDN 에지 서버의 IP 주소가 있어야 한다는 것입니다.
여기에는 몇 가지 문제가 있습니다. 많은 CDN은 IP 주소 목록을 제공하지 않으며, 제공하더라도 IP 주소를 추가하거나 변경할 수 있으며 알림을 잊어버릴 수도 있습니다. 이러한 화이트리스트는 사이트가 손상되지 않도록 정기적으로 업데이트해야 합니다.

옵션 B: 요청의 고유 식별자 허용

아이디어는 간단합니다. CDN은 원본 서버에서 고유 식별자를 요청에 보내 원본 서버에서 CDN을 식별하고 요청을 허용하는 데 사용할 수 있습니다. 그러나 이 방법은 완전히 안전하지 않습니다. 공격자는 또한 요청을 자유롭게 설정할 수 있습니다. 즉, 사용하는 CDN 공급자를 알고 있고 CDN 공급자가 원본 서버에 자신을 식별하는 방법도 알고 있습니다. 공격자가 이 정보를 가지고 있으면 요청을 쉽게 스푸핑할 수 있습니다.

옵션 C: 추측할 수 없는 원래 호스트 이름

이것은 공격자가 웹 서버에 액세스하려고 할 때 찾을 수 없기 때문에 방어자에게 가장 안정적인 솔루션일 것입니다. 방어자는 임의의 긴 영숫자 세트를 만들고 이를 하위 도메인으로 사용합니다. 예를 들어 도메인 이름이 "HolyBugx.com"인 경우 "2547d0jeid15ma.HolyBugx.com"과 같은 하위 도메인을 설정합니다.
그렇게 하면 호스트 이름은 그들과 그들의 CDN 공급자에게만 알려지고 그들은 그 호스트 이름으로 요청을 화이트리스트에 올릴 수 있습니다.

요약하다

동일한 CDN에 모든 하위 도메인 유지 아웃바운드 연결
차단 아웃바운드 연결 차단
CDN 구성 시 원본 IP 변경
IP 주소를 사용하여 웹사이트에 대한 직접 액세스 제한

참조
Cloudflare.com
CDN.net
Sitelock.com
knoldus.com
keycdn.com
Imagekit.io 저자: Rahul Nanwani
GeekFlare.com 저자: Chandan Kumar
Detectify.com 저자: Gwendallecoguic
Secjuice.com 저자: Paul dannewitz
Nixcp.com 저자: Esteban Borges
Pielco11.ovh 사용자:
Soroush Dalili의 Pielco11 WAF 회피 기법

~에서

추천

출처blog.csdn.net/qq_42096378/article/details/124116046
추천
행
(MySQL의 마이그레이션 테이블 데이터에서 MSSQL2008R2에) MySQL 용 마이크로 소프트 SQL 서버 마이그레이션 지원 _3
양적 연구 방법 (PUBL0055)
C # 색상 변환
vim 일반 작업
지도에 스트림 내 목록에 추가
[전체 가이드] 비밀번호 없이 OPPO 전화 잠금 해제하는 방법
vim이 정지 모드에서 응답하지 않습니다.
Qt: 윈도우 이벤트 전달 순서
MySQL 内存泄露怎样检查
고급 C 언어 포인터
아카이브
기타
2020-04-08(1460)
2020-04-07(1517)
2020-04-06(1499)
2020-04-05(1440)
2020-04-04(1629)
2020-04-03(1644)
2020-04-02(1572)
2020-04-01(1665)
2020-03-31(1639)
2020-03-30(1334)

코드 세계

© 2018 codetd.com