É comum que subdomínios aninhados sejam bloqueados devido à detecção de phishing?

É comum que subdomínios aninhados sejam bloqueados devido à detecção de phishing?

Tenho um domínio que usa subdomínios para usuários, por exemplo:

user1.example.com

Para distinguir entre outros subdomínios oficiais e subdomínios de usuários, reservei “at” para todos esses casos. Por exemplo, alguns subdomínios oficiais são:

api.at.example.com, releases.at.example.com, support.at.example.com

Já me deparei duas vezes com bloqueios devido à detecção de phishing falso positivo. Longe do Google e da Cisco. Eles parecem sugerir que meu site está tentando se passar por "api.at" ou "releases.at".

É bastante irritante que os serviços bloqueiem subdomínios sem outros sinais de atividade maliciosa, simplesmente com base em um nome bastante genérico que recebem. Especialmente irritante para a Cisco, pois eles bloqueiam solicitações de busca/xhr e o usuário não tem opção de ignorar. O Google pelo menos não bloqueia fetch/xhr, apenas se você visitar o domínio no navegador como uma página.

Gostaria de saber o quão comum isso é? Estou pensando em reservar alguns subdomínios de primeiro nível apenas para contornar isso (por exemplo api.example.com), mas parece bobagem que os serviços bloqueiem efetivamente todos os subdomínios aninhados. Se não for comum, posso tentar enviar tíquetes de suporte aos serviços infratores.

(isto é para um domínio totalmente novo, sem proprietário anterior e sem qualquer conteúdo malicioso, pois eu mesmo escrevi o aplicativo inteiro)

Responder1

Sim, embora eu concorde que é imprudente causar problemas generalizados com tal bloqueio excessivo, isso énão limitado a entidades únicasque você poderia consertar isso individualmente para você.

Instalei regras de bloqueio semelhantes em sistemas de desktop que administro e confirmei com entidades comerciais importantes que elas aplicam esses bloqueios em suas frotas de dispositivos. Minhas regras se aplicam pelo menos apenas a domínios que contêm ou se assemelham a nomes de marcas próprias e associadas. Outras empresas afirmam usar “aprendizado de máquina” para determinar sua “classificação de ameaça de URL”, o que para mim parece ainda mais provável de resultar no que você experimentou com a Cisco.

Este tipo de detecção é definitivamentecomum emcontexto de e-mail- você deve ser classificado instantaneamente como uma fonte de spam se for visto retransmitindo mensagens não autorizadas para <brandname>.<tld>.<otherdomain>.<tld>.

Espera-se que você examine e monitore seus clientes para nunca permitir que coisas como bankofamerica.com.yourdomain.examplesejam usadas por golpistas. Se parecer que você negligenciou a escolha de padrões seguros em seus domínios, espere problemas com heurísticas particularmente sensíveis. Eu recomendo vocêfique longe de qualquer ccTLD popular(por exemplo, .at)e uTLD(por exemplo, .com) para rótulos que você usaNo meiode seus nomes de domínio mais longos.

Dependendo do tipo de serviços que você oferece aos usuários, pode até ser apropriado ter esse domínioadicionado à lista pública de sufixos. Mesmo que não seja, leia a documentação relacionada, ela pode ajudá-lo a determinar se é uma boa ideia hospedar o conteúdo do usuário abaixo de um domínio também em uso para outros serviços (dica: os navegadores são feras complexas atualmente).

informação relacionada