사용자를 위해 하위 도메인을 사용하는 도메인이 있습니다. 예:
user1.example.com
다른 공식 하위 도메인과 사용자 하위 도메인을 구별하기 위해 이러한 모든 경우에 대해 "at"을 예약했습니다. 예를 들어 일부 공식 하위 도메인은 다음과 같습니다.
api.at.example.com, releases.at.example.com, support.at.example.com
저는 거짓 긍정 피싱 감지로 인해 차단을 두 번이나 겪었습니다. 지금까지 Google과 Cisco에서는 그렇지 않았습니다. 그들은 내 사이트가 "api.at" 또는 "releases.at"를 가장하려고 한다는 것을 암시하는 것 같습니다.
서비스가 단순히 주어진 상당히 일반적인 이름에 기초하여 악의적인 활동의 다른 징후 없이 하위 도메인을 차단한다는 것은 다소 짜증나는 일입니다. 특히 Cisco는 사용자가 우회할 수 있는 옵션이 없는 fetch/xhr 요청을 차단하므로 짜증스럽습니다. Google은 최소한 브라우저에서 도메인을 페이지로 방문하는 경우에만 fetch/xhr을 차단하지 않습니다.
이것이 얼마나 흔한 일인지 알고 싶습니다. 단지 문제를 해결하기 위해 일부 첫 번째 수준 하위 도메인을 예약하는 것을 고려하고 있지만(예 api.example.com: ) 서비스가 모든 중첩된 하위 도메인을 효과적으로 차단하는 것은 어리석은 것 같습니다. 일반적이지 않은 경우에는 문제가 있는 서비스에 지원 티켓을 제출해 볼 수도 있습니다.
(이것은 이전 소유자가 없고 악성 콘텐츠가 전혀 없는 새로운 도메인을 위한 것입니다. 전체 앱을 직접 작성했기 때문입니다.)
답변1
예, 나는 그러한 과잉 차단으로 인해 광범위한 문제를 일으키는 것이 무모하다는 점에 동의하지만 이것은단일 엔터티에 국한되지 않음이 문제를 개별적으로 해결할 수 있습니다.
나는 내가 관리하는 데스크톱 시스템에 유사한 차단 규칙을 설치했으며 주요 상업 기관이 장치 전체에 걸쳐 이러한 차단을 시행한다는 것을 확인했습니다. 내 규칙은 최소한 소유 및 관련 브랜드 이름을 포함하거나 유사한 도메인에만 적용됩니다. 다른 회사에서는 "URL 위협 분류"를 결정하기 위해 "머신 러닝"을 사용한다고 주장하는데, 제가 보기에는 Cisco에서 경험한 것과 같은 결과가 나올 가능성이 훨씬 더 높습니다.
이런 종류의 탐지는 확실히일반적인이메일 컨텍스트- 에 대한 승인되지 않은 메일을 릴레이하는 것이 발견되면 즉시 스팸 소스로 분류될 것으로 예상해야 합니다 <brandname>.<tld>.<otherdomain>.<tld>.
bankofamerica.com.yourdomain.example사기꾼이 이러한 정보를 사용하지 못하도록 고객을 조사하고 모니터링해야 합니다 . 도메인이 안전한 기본값 선택을 소홀히 한 것처럼 보이면 특히 민감한 경험적 접근 방식에 문제가 있을 수 있습니다. 나는 당신을 추천합니다인기 있는 ccTLD를 피하세요(예: .at)그리고 uTLD(예: .com) 사용하는 라벨중간에더 긴 도메인 이름을 사용하세요.
사용자에게 제공하는 서비스 종류에 따라 해당 도메인을 보유하는 것이 적절할 수도 있습니다.공개 접미사 목록에 추가됨. 그렇지 않더라도 관련 문서를 읽으면 우선 다른 서비스에도 사용되는 도메인 아래에 사용자 콘텐츠를 호스팅하는 것이 좋은 생각인지 판단하는 데 도움이 될 수 있습니다(힌트: 요즘 브라우저는 복잡합니다).