У меня есть домен, который использует поддомены для пользователей, например:
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) для используемых вами метокв серединеваших длинных доменных имен.
В зависимости от типа услуг, которые вы предлагаете пользователям, может быть даже целесообразно иметь этот домендобавлен в список общедоступных суффиксов. Даже если это не так, прочтите соответствующую документацию — она может помочь вам определить, является ли размещение пользовательского контента на домене, который также используется для других служб, хорошей идеей (подсказка: браузеры в наши дни — сложные создания).