Часто ли вложенные поддомены блокируются из-за обнаружения фишинга?
У меня есть домен, который использует субдомены для пользователей, например:
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), но со стороны сервисов кажется глупым эффективно блокировать все вложенные поддомены. Если это не распространено, я могу просто попробовать отправить билеты в службу поддержки в службы-нарушители.
(это для совершенно нового домена без предыдущего владельца и без вредоносного контента, так как я сам написал все приложение)
Да , хотя я согласен с тем, что это безрассудно вызывать массовые проблемы с такой чрезмерной блокировкой, это не ограничивается отдельными объектами , к которым вы можете обращаться по отдельности исправить это для вас.
Я установил аналогичные правила блокировки в настольных системах, которые я администрирую, и подтвердил крупным коммерческим организациям, что они применяют такие блокировки на своих парках устройств. Мои правила, по крайней мере, применяются только к доменам, содержащим или напоминающим собственные и связанные торговые марки. Другие компании заявляют, что используют «машинное обучение» для определения своей «классификации URL-угроз», что, на мой взгляд, еще более вероятно приведет к тому, что вы испытали с Cisco.
Этот тип обнаружения определенно распространен в контексте электронной почты,-вы должны ожидать, что вы будете немедленно классифицированы как источник спама, если увидите, что вы пересылаете несанкционированную почту для <brandname>.<tld>.<otherdomain>.<tld>.
Ожидается, что вы будете проверять и контролировать своих клиентов, чтобы никогда не позволять мошенникам использовать такие вещи, как bankofamerica.com.yourdomain.example. Если ваши домены выглядят так, как будто вы пренебрегли выбором безопасных значений по умолчанию, ожидайте проблем с особенно чувствительными эвристиками. Я рекомендую вам держаться подальше от каких-либо популярных нДВУ (, например..at)и uTLD (, например..com)для ярлыков, которые вы используете в середине ваших длинных доменных имен.
В зависимости от вида услуг, которые вы предлагаете пользователям, может быть даже целесообразно добавить этот домен в общедоступный список суффиксов . Даже если это не так, прочтите соответствующую документацию, она может помочь вам определить, стоит ли в первую очередь размещать пользовательский контент под доменом, который также используется для других служб (подсказка:в наши дни).