Qual é a contramedida Brute Force melhor distribuído?

https://stackoverflow.com/questions/479233

20-08-2019
|

Pergunta

Primeiro, um pouco de fundo: Não é nenhum segredo que estou implementando um sistema de autenticação + auth para CodeIgniter, e até agora eu estou ganhando (por assim dizer). Mas eu correr em um desafio não-trivial bonita (que a maioria das bibliotecas de autenticação perder inteiramente, mas I insistir em manuseá-lo corretamente): como lidar de forma inteligente com em larga escala, variável-username brute-force distribuídos ataques .

Eu sei que todos os truques habituais:

Limitando # de tentativas falhadas por IP / host e negar o acesso criminosos (por exemplo Fail2Ban) - que já não funciona desde botnets têm crescido mais inteligente
Combinando o acima com um lista negra de 'más' IPs conhecidos / hosts (por exemplo denyhosts) - que se baseia em botnets caindo para # 1, que cada vez mais não
IP / host listas brancas combinado com auth tradicional (infelizmente inútil com os usuários IP dinâmicos ea alta rotatividade na maioria dos sites da web)
A definição de um limite Sitewide sobre # de tentativas falhadas dentro de um período de N minutos / hora, e estrangulamento (suspensão) todas as tentativas de acesso depois de que para um número de minutos / hora (com o problema que DoS atacá-lo torna-se peça botnet criança)
obrigatórios assinaturas digitais (certificados de chave pública-) ou tokens de hardware RSA para todos os usuários opção NO login / senha com (sem dúvida uma sólida solução, mas apenas prático para fechado, serviços dedicados)
Forçados esquemas de senha ultra-fortes (por exemplo> 25 caracteres sem sentido com símbolos - novamente, muito prático para os usuários casuais)
E, finalmente, CAPTCHAs (que poderia funcionar na maioria dos casos, mas são irritantes para os usuários e praticamente inútil contra um determinado, engenhoso atacante )

Agora, estas são apenas as idéias teoricamente viáveis. Há muito de idéias lixo que sopram do site aberta (por exemplo a ataques DoS triviais). O que eu quero é algo melhor. E por uma melhor, quero dizer:

Tem que ser seguro (+) contra DoS e ataques de força bruta, e não introduzir quaisquer novas vulnerabilidades que poderiam permitir que um bot um pouco furtivos para continuar a operar sob o radar
Tem de ser automatizado. Se ele requer um operador humano para verificar a cada login ou monitorar a atividade suspeita, ele não está indo para o trabalho em um cenário do mundo real
Tem que ser viável para Mainstream uso da web (ie. Alto churn, alto volume, e o registo aberto, que pode ser realizada por não-programadores)
Ele não pode impedir a experiência do usuário para o ponto onde os usuários casuais vai ficar irritado ou frustrado (e potencialmente abandonar o site)
Ele pode não envolver gatinhos, a menos que estejam realmente muito segura gatinhos

(+) por 'seguro', quer dizer, pelo menos tão segura quanto a capacidade de um usuário paranóico para manter seu segredo senha

Assim - Vamos ouvi-lo! Como você fazê-lo ? Sabe de uma melhor prática que eu não tenha mencionado (oh por favor, diga que você faz)? Admito que tenho uma idéia de meus próprios (combinando ideias de 3 e 4), mas eu vou deixar os verdadeiros especialistas falam antes de envergonhar-me; -)

Solução

Tudo bem, estagnação o suficiente; aqui está o que eu vim acima com até agora

(desculpe, longa postar à frente. Seja corajoso, amigo, a viagem vai valer a pena)

A combinação de métodos 3 e 4 do post original em uma espécie de 'difusa' ou dinâmico whitelist, e então - e aqui está o truque - não bloquear IPs não na lista de autorizações, apenas estrangulando-los para o inferno e voltar .

Note que esta medida é única destina-se a impedir este tipo muito específico de ataque. Na prática, é claro, ele iria trabalhar em combinação com outras melhores práticas abordagens para auth:-username fixo de estrangulamento, per-IP estrangulamento, a política de senha forte imposta pelo código, Unthrottled login do biscoito, hash todos os equivalentes de senha antes de salvá-los, nunca mais usando perguntas de segurança, etc.

Hipóteses a respeito do cenário de ataque

Se um atacante está mirando usernames variáveis, nossa estrangulamento nome de usuário não dispara. Se o atacante está usando uma botnet ou tem acesso a uma ampla gama de IP, a nossa estrangulamento IP é impotente. Se o atacante tem pré-raspado nossa lista de utilizadores (geralmente possível em serviços web-registo aberto), não podemos detectar um ataque em curso com base no número de 'usuário não encontrado' erros. E se aplicar um sistema de ampla restritiva (todos os nomes de usuário, todos os IPs) de estrangulamento, de tal ataque vai DoS todo o nosso site para a duração do ataque mais o período de estrangulamento.

Então, o que precisamos fazer algo mais.

A primeira parte da contramedida: Whitelisting

O que pode ser bastante certeza, é que o atacante não é capaz de detectar e dinamicamente spoof os endereços IP de vários milhares de nossos usuários (+). O que torna whitelisting viável. Em outras palavras: para cada usuário, armazenamos uma lista dos IPs (hash), de onde o usuário tem anteriormente (recentemente) logado

Assim, o nosso esquema de whitelisting funcionará como um 'porta da frente' bloqueado, onde o usuário deve estar conectado de uma de suas 'boas' IPs reconhecidos, a fim de logar-se em tudo. Um ataque de força bruta contra esta 'porta da frente' seria praticamente impossível (+).

(+) a menos que o atacante 'possui' o servidor, todos os nossos usuários caixas, ou a própria conexão - e, nesses casos, não temos mais um 'problema de autenticação', temos uma verdadeira franquia de tamanho situação pull-a-plug FUBAR

A segunda parte da contramedida: de todo o sistema de estrangulamento de IPs não reconhecidos

A fim de fazer um trabalho de whitelist para um serviço de web-registro aberto, onde os usuários mudar de computador com frequência e / ou ligar a partir de endereços IP dinâmicos, precisamos manter uma 'porta de gato' aberto para usuários que se conectam a partir de IPs não reconhecidos. O truque é projetar que porta para botnets se usuários preso, e assim legítimos ficar incomodado o mínimo possível .

Em meu esquema, isto é conseguido através da criação de um muito número máximo restritiva de tentativas de login por IPs não aprovados mais de, digamos, um período de 3 horas (pode ser mais sábio para usar um mais curto ou período mais longo dependendo do tipo de serviço), e fazer que a restrição Global , ou seja. para todas as contas de usuário.

Mesmo um lento força bruta (1-2 minutos entre tentativas) seria detectado e contrariado rapidamente e eficazmente a utilização deste método. Claro, um muito lento força bruta ainda pode passar desapercebido, mas as velocidades muito lentas contra o propósito do ataque de força bruta.

O que eu estou esperando para realizar com este mecanismo de limitação é que, se o limite máximo é atingido, os nossos 'porta de gato' bate fechado por um tempo, mas os nossos restos porta da frente aberta a usuários legítimos conectar por meio usuais:

De qualquer ligando de um de seus IPs reconhecidos
ou usando um cookie de login persistente (em qualquer lugar)

Os usuários única legítimos que seriam afetados durante um ataque - ie. while do estrangulamento foi ativado - seria usuários sem cookies de login persistentes que estavam registrando no de um local desconhecido ou com um IP dinâmico. Esses usuários não seria capaz de logon até que o estrangulamento desgastou fora (o que poderia demorar um pouco, se o atacante manteve sua botnet funcionando apesar do estrangulamento).

Para permitir que este pequeno subconjunto de usuários para espremer através da porta de gato outra forma fechados, mesmo enquanto bots ainda estavam martelando-lo, eu iria empregar um formulário de login 'backup' com um CAPTCHA. De modo que, quando você exibir o "Desculpe, mas você não pode logon a partir deste endereço IP no momento" mensagem, incluir um link que diz " seguro de login de backup - os seres humanos só ( bots: não mentir ) ". Piada de lado, quando clicar nesse link, dar-lhes um formulário de login reCAPTCHA-autenticado que ultrapassa o estrangulamento em todo o site. Dessa forma, se eles são humanos e saber o login + senha correta (e são capazes de ler CAPTCHAs), eles vão não ser negado serviço, mesmo se eles estão se conectando a partir de um host desconhecido e não usando o autologin cookie.

Ah, e só para esclarecer:. Desde que eu considero CAPTCHAs a ser geralmente mal, a opção de login 'backup' faria única aparecer enquanto estrangulamento era ativo

Não há como negar que um ataque sustentado assim ainda constituiria uma forma de ataque DoS, mas com o sistema descrito no lugar, só afetaria o que eu suspeito de ser um pequeno subconjunto de usuários, ou seja, as pessoas que don' t usar a "lembrar de mim" cookie e acontecer de ser o login, enquanto o ataque ocorrer e não está entrando a partir de qualquer de seus IPs habitual e que não sabem ler CAPTCHAs. Só quem pode dizer não a todos esses critérios - especificamente bots e realmente azarado pessoas com deficiência -. Vai ser afastado durante um ataque bot

EDIT: Actully, pensei em uma maneira de permitir que os usuários ainda CAPTCHA-desafiados passam durante um 'bloqueio': em vez de, ou como um suplemento, o login CAPTCHA backup, fornecer ao usuário uma opção para ter um uso único, o código de bloqueio específico do usuário enviado para o seu e-mail, que ele pode usar para ignorar o estrangulamento. Isso definitivamente cruza por cima do meu limite 'aborrecimento', mas desde que ele só é usado como um último recurso para um pequeno subconjunto de usuários, e uma vez que ainda bate sendo trancado para fora de sua conta, seria aceitável.

(Também, nota que nenhum isso acontece se o ataque é menos sofisticado do que a versão distribuída desagradável que eu descrevi aqui. Se o ataque é proveniente de apenas alguns IPs, ou apenas bater alguns nomes de usuário, ele será impedido muito mais cedo, e com não conseqüências em todo o site)

Então, essa é a contramedida vou implementar na minha biblioteca auth, uma vez que eu estou convencido de que é sólido e que não há uma solução muito mais simples que eu perdi. O fato é que há tantas formas sutis de fazer as coisas erradas em segurança, e eu não estou acima de fazer falsas suposições ou lógica irremediavelmente falho. Então, por favor, todo e qualquer comentário, crítica e melhorias, sutilezas etc. são muito apreciados.

Outras dicas

A poucos passos simples:

certos nomes de usuários comuns na lista negra, e usá-los como um honeypot. Administrador, convidado, etc ... não deixe ninguém criar contas com esses nomes, por isso, se alguém não tentar registrá-los em você sabe que é alguém fazendo algo que não deveria.

Certifique-se de quem tem o poder real no site tem uma senha segura. Exigir admins / moderadores para ter senhas mais longas com uma mistura de letras, números e símbolos. Rejeitar senhas trivialmente simples de usuários regulares com uma explicação.

Uma das coisas mais simples que você pode fazer é que as pessoas dizer quando alguém tentou fazer login em sua conta, e dar-lhes um link para relatar o incidente, se não fosse eles. Uma mensagem simples quando se logar como "Alguém tentou entrar em sua conta em 04:20 quarta-feira, blá, blá. Clique aqui se não foi você." Ele permite que você mantenha algumas estatísticas sobre os ataques. Você pode reforçar as medidas de segurança monitorando e se você ver que há um aumento repentino no número de acessos fraudulentos.

Se eu entender o MO de ataques de força bruta corretamente, então um ou mais nomes de usuário são julgados de forma contínua.

Existem duas sugestões que eu não acho que eu vi aqui ainda:

Eu sempre pensei que a prática padrão era ter um pequeno atraso (um segundo ou mais) após cada login errado para cada usuário. Este Deters de força bruta, mas eu não sei quanto tempo um segundo de atraso possa manter um ataque de dicionário na baía. (Dicionário de 10.000 palavras == 10.000 segundos == cerca de 3 horas. Hmm. Não é bom o suficiente.)
em vez de um site-wide lento, por que não um acelerador de nome de usuário. O acelerador torna-se cada vez mais dura a cada tentativa errada (até um limite, eu acho que o usuário real pode ainda login)

Editar : Em resposta aos comentários sobre um acelerador usuário: este é um acelerador nome de usuário específico sem levar em conta a origem do ataque

Se o nome de usuário é estrangulada, em seguida, até mesmo um ataque nome de usuário coordenada (multi IP, palpite único por IP, mesmo nome de usuário) seria pego. nomes de usuários individuais são protegidos pelo regulador de pressão, mesmo que os atacantes são livres para tentar outro usuário / pass durante o tempo limite.

Do ponto de vista atacantes, durante o tempo limite que você pode ser capaz de dar um primeiro palpite hora em 100 senhas, e rapidamente descobrir uma senha errada por conta. Você só pode ser capaz de fazer 50 segundos palpites para o mesmo período de tempo.

Do ponto de vista conta de usuário, ele ainda tem o mesmo número médio de tentativas para quebrar a senha, mesmo se as suposições são provenientes de várias fontes.

Para os atacantes, na melhor das hipóteses, será o mesmo esforço para quebrar 100 contas de como seria uma conta, mas desde que você não está estrangulamento em um site de base ampla, você pode rampa até o acelerador muito rapidamente.

refinamentos extra:

detectar IPs que são adivinhando várias contas - 408 Request Timeout
detectar IPs que são adivinhando a mesma conta -. 408 Request Timeout depois de um grande (digamos 100) número de suposições

Ideias de interface do usuário (pode não ser adequado neste contexto), que também pode refinar a acima:

Se você está no controle da configuração de senha, em seguida, mostrando o usuário quão forte sua senha é encoraja-os a escolher um melhor.
Se você está no controle do login página , depois de uma pequena (digamos, 10) número de palpites de um único nome de usuário, oferecer um CAPTCHA.

Há três fatores de autenticação:

Um usuário sabe algo (ou seja, uma senha)
Um usuário tem algo (ou seja, um chaveiro)
Um usuário é algo (ou seja, retina scan)

Normalmente, sites só aplicar a política # 1. Mesmo a maioria dos bancos só aplicar a política 1. Eles preferindo recorrer a um "sabe algo mais" abordagem para autenticação de dois fatores. (IE: Um usuário sabe sua senha e nome de solteira de sua mãe.) Se você é capaz, uma maneira de adicionar um segundo fator de autenticação não é muito difícil.

Se você pode gerar em torno de 256 caracteres de aleatoriedade, você poderia estruturar isso em uma mesa de 16 × 16, e, em seguida, pedir ao utilizador para dar-lhe o valor na tabela de células A-14, por exemplo. Quando um usuário se inscrever ou altera sua senha, dar-lhes a mesa e dizer-lhes para imprimi-lo e guardá-lo.

A dificuldade com essa abordagem é que, quando um usuário esquecer sua senha, como eles vão, você não pode apenas oferecer o padrão "responder a esta pergunta e colocar em uma nova senha", já que é vulnerável a de força bruta bem . Além disso, você não pode redefini-la e enviá-las um novo, desde o seu e-mail pode ser comprometida também. (Veja:. Makeuseof.com e seu domínio roubado)

Outra idéia (que envolve gatinhos), é o que BOA chama SiteKey (I acreditar que registrou o nome). Resumidamente, você tem o usuário fazer upload de uma imagem quando eles se inscrever, e quando eles tentam login, pedir-lhes para escolher a sua imagem de 8 ou 15 (ou mais) os aleatórios. Assim, se um usuário carrega uma imagem de seu gatinho, teoricamente, só eles sabem exatamente qual a imagem que é deles, de todos os outros gatinhos (ou flores ou qualquer outro). O vunerability única real esta abordagem tem é o man-in-the-middle ataque.

Mais uma ideia (sem gatinhos embora), é rastrear IPs que os usuários acessar o sistema com, e obrigá-los a realizar a autenticação adicional (captcha, escolher um gatinho, pegar uma chave a partir desta tabela) quando entrar a partir de um abordar eles não têm antes. Além disso, semelhante ao GMail, permitem que o usuário vista onde eles têm logado partir recentemente.

Editar, New Idea:

Outra forma de validar tentativas de login é verificar se ou não o usuário veio de sua página de login. Você não pode verificar referências, uma vez que podem ser facilmente falsificado. O que você precisa é definir uma chave na _SESSION var quando o usuário visualiza a página de login, e, em seguida, certifique-se de que existe chave quando eles apresentarem as suas informações de login. Se bot não apresentar na página de login, ele não será capaz de login. Você também pode facilitar este, envolvendo javascript no processo, usando-o para definir um cookie, ou adicionar algumas informações para o formulário depois ele foi carregado. Ou, você pode dividir o formulário em duas submete diferentes (isto é, o usuário digita seu nome de utilizador, alega, em seguida, em uma nova página entra sua senha e enviar novamente.)

A chave, neste caso, é o aspecto mais importante. Um método comum de gerá-los é uma combinação de dados do usuário, seu IP, e o tempo que foi submetido.

Eu tenho que perguntar se você tem análise feita custo-benefício deste problema; parece que você está tentando proteger-se de um atacante que tenha presença na web o suficiente para adivinhar um número de senhas, enviando talvez 3-5 pedidos por IP (desde que você tenha demitido estrangulamento IP). Quanto (aproximadamente) faria esse tipo de custo ataque? É mais caro do que o valor das contas que você está tentando proteger? Quantos botnets gigantescos querem o que você tem?

A resposta pode ser não - mas se for, eu espero que você está recebendo a ajuda de um profissional de segurança de algum tipo; habilidade de programação (e pontuação StackOverflow) não se correlacionam fortemente com a segurança know-how.

Eu já tinha respondido a uma pergunta muito semelhante sobre a Como Eu posso estrangular tentativas de login de usuário em PHP . Vou reiterar a solução aqui proposta como eu acredito que muitos de vocês irão encontrá-lo informativo e útil para ver alguns código real. Por favor, nua em mente que usando um CAPTCHA pode não ser a melhor solução, devido aos algoritmos cada vez mais precisos sendo usados ??em busters CAPTCHA hoje em dia:

Você não pode simplesmente evitar ataques DoS por encadeamento de estrangulamento para um único IP ou nome de usuário. Inferno, você não pode sequer realmente evitar tentativas de login rápido-fogo usando este método.

Por quê? Porque o ataque pode abranger vários IPs e contas de usuário para o bem dos ignorando suas tentativas de estrangulamento.

Eu vi postado em outro lugar que idealmente você deve estar acompanhando todas as tentativas de login em todo o site e associando-os a um timestamp, talvez:

CREATE TABLE failed_logins(
    id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(16) NOT NULL,
    ip_address INT(11) UNSIGNED NOT NULL,
    attempted DATETIME NOT NULL
) engine=InnoDB charset=UTF8;

Decidir sobre alguns atrasos com base no global número de logins falhos em um determinado período de tempo. Você deve basear esta em dados estatísticos extraídos de sua mesa failed_logins como ele irá mudar ao longo do tempo com base no número de usuários e como muitos deles podem recordar (e tipo) a sua senha.

10 failed attempts = 1 second
20 failed attempts = 2 seconds
30 failed attempts = reCaptcha

consultar a tabela em cada tentativa de login não conseguiu encontrar o número de logins falhos para um determinado período de tempo, digamos 15 minutos:

SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute);

Se o número de tentativas ao longo do período de tempo determinado é o seu limite, quer impor estrangulamento ou forçar todos os usuários de usar um captcha (ie reCaptcha) até que o número de tentativas frustradas ao longo do período de tempo determinado é inferior ao limite .

// array of throttling
$throttle = array(10 => 1, 20 => 2, 30 => 'recaptcha');

// assume query result of $sql is stored in $row
$sql = 'SELECT MAX(attempted) AS attempted FROM failed_logins';
$latest_attempt = (int) date('U', strtotime($row['attempted']));
// get the number of failed attempts
$sql = 'SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute)';
// assume the number of failed attempts was stored in $failed_attempts
krsort($throttle);
foreach ($throttle as $attempts => $delay) {
    if ($failed_attempts > $attempts) {
        // we need to throttle based on delay
        if (is_numeric($delay)) {
            $remaining_delay = time() - $latest_attempt - $delay;
            // output remaining delay
            echo 'You must wait ' . $remaining_delay . ' seconds before your next login attempt';
        } else {
            // code to display recaptcha on login form goes here
        }
        break;
    }
}

Usando reCaptcha em um determinado limiar seria garantir que um ataque de várias frentes seria minimizado e usuários normais do site não iria ocorrer um atraso significativo para tentativas de login legítimos. Eu não posso prevenção gaurantee, como ele já foi expandida que CAPTCHA de pode ser preso. Existem soluções alternativas, talvez uma variante de "Nome este animal", o que poderia funcionar muito bem como um substituto.

Para resumir esquema Jens' em um diagrama de transição de estado pseudo / base de regra:

user + senha -> entrada
user + senha -> negado
user + known_IP (usuário) -> porta da frente, // never throttle
user + unknown_IP (usuário) -> catflap
(# negado> n) via catflaps (local) -> catflaps acelerador (Site) // slow the bots
catflap + acelerador + senha + captcha -> entrada // humans still welcome
catflap + acelerador + senha + captcha -> negado // a correct guess from a bot

Observações:

Nunca estrangule a porta da frente. A polícia estadual Elbonian ter seu computador, em sua casa, mas são incapazes de interrogá-lo. A força bruta é uma abordagem viável a partir do seu computador.
Se você fornecer um "Esquecer sua senha?" link, em seguida, sua conta de e-mail torna-se parte da superfície de ataque.

Estas observações cobrir um tipo diferente de ataque para aqueles que você está tentando balcão.

Parece que você está tentando se defender contra bruta lento distribuídos forçar . Não muito você pode fazer sobre ele. Estamos usando uma PKI e sem logins de senha. Ele ajuda, mas se seus clientes acaso estações de trabalho de vez em quando, isso não é muito aplicável.

Disclaimer: trabalho eu para uma empresa de dois fatores, mas não estou aqui para ligá-lo. Here're algumas observações.

Os cookies podem ser roubados com XSS e vulns navegador. Usuários comumente mudar navegadores ou limpar seus cookies.

endereços IP de origem são simultaneamente dinamicamente variável e spoofable.

CAPTCHA é útil, mas não autentica um ser humano específico.

Vários métodos podem ser combinados com sucesso, mas o bom gosto é certamente em ordem.

complexidade senha é bom, nada de senha baseada em criticamente depende de senhas com entropia suficiente. IMHO, uma senha forte escrito em um local físico seguro é melhor do que uma senha fraca na memória. As pessoas sabem como avaliar a segurança de documentos em papel muito melhor do que eles sabem como calcular a entropia eficaz em nome do seu cão, quando utilizado como uma senha para três sites diferentes. Considere dar aos usuários a capacidade de imprimir uma página de grande ou pequeno cheio de códigos de uso de passagem de uma só vez.

questões de segurança como "qual foi a sua mascote de alta escola" são na maior parte uma outra forma ruim de "algo que você sabe", a maioria deles são facilmente guessable ou totalmente no domínio público.

Como você observou, estrangulamento tentativas de login de volta falhadas é um trade-off entre impedindo ataques de força bruta e facilidade de dosagem uma conta. diretivas de bloqueio agressivos pode refletir uma falta de confiança na entropia senha.

Eu, pessoalmente, não vê o benefício para impor a expiração da senha em um site de qualquer maneira. Atacante recebe sua senha uma vez, ele pode alterá-lo, em seguida, e em conformidade com essa política tão facilmente como você pode. Talvez uma vantagem é que o usuário pode notar mais cedo se o atacante muda a senha da conta. Ainda melhor seria se o usuário de alguma forma foram notificados antes de o atacante ganhou acesso. Mensagens como "N tentativas fracassadas desde o último login" são úteis a este respeito.

A melhor segurança vem de um segundo fator de autenticação que é out-of-band em relação ao primeiro. Como você disse, tokens de hardware no "algo que você tem" são grandes, mas muitos (não todos) têm verdadeiro administrador sobrecarga associada à sua distribuição. Eu não sei de qualquer biométrica "algo que você é" soluções boas para websites. Alguns de dois fatores soluções de trabalho com provedores de OpenID, alguns têm PHP / Perl / Python SDKs.

A minha recomendação mais elevada é simplesmente certificar-se de que você manter os usuários informados de tentativas mal de login para sua accounts-- Os usuários provavelmente vai levar a força de sua senha muito mais a sério se eles são apresentados com evidências de que alguém está realmente tentando entrar em sua conta.

I alguém realmente pegar que invadiu conta myspace do meu irmão, porque eles tinham tentado entrar no gmail configuração da conta I para ele e usou o 'reset minha senha por e-mail' recurso ... que foi para minha caixa de entrada.

E sobre a necessidade de um one-time-password antes de entrar sua senha normal? Isso tornaria muito óbvio que alguém estava atacando antes que eles tem muitas oportunidades para adivinhar a senha principal?
Mantenha uma contagem / taxa global de falhas de login - este é o indicador para um ataque - durante um ataque ser mais rigoroso sobre falhas de login por exemplo proibição IPs mais rapidamente.

Eu não acredito que há uma resposta perfeita, mas eu estaria inclinado a abordá-lo em uma base de tentar confundir os robôs se um ataque é detectado.

Em cima da minha cabeça:

Mudar para uma tela de login alternativo. Ele tem várias username e password espaços em branco que realmente aparecem, mas apenas um deles está no lugar certo. Os nomes dos campos são RANDOM - uma chave de sessão é enviada junto com a tela de login, o servidor pode, então, descobrir o que são campos quê. Sucesso ou fracasso é depois descartado para que você não pode tentar um ataque de repetição -. Se você rejeitar a senha que eles obter um novo ID de sessão

Qualquer formulário que é enviado com os dados em um campo errado é assumido como sendo de um robô - o login falhar, período, e que IP é estrangulada. Certifique-se os nomes dos campos aleatórios não corresponder aos nomes de campo legítimo para que alguém usar algo que lembra as senhas não é enganar.

Em seguida, como sobre um tipo diferente de captcha: Você tem uma série de perguntas que não vai causar problemas para um ser humano. No entanto, eles são não aleatória. Quando o ataque começa todos é dada a pergunta # 1. Depois de uma questão hora # 1 é descartada, para nunca mais ser usado novamente e todo mundo fica a pergunta # 2 e assim por diante.

O atacante não pode sondar para baixar o banco de dados para colocar em seu robô por causa da natureza descartável das perguntas. Ele tem que enviar novas instruções para fora para sua botnet dentro de uma hora para ter qualquer capacidade de fazer qualquer coisa.

Uma vez que várias pessoas incluído CAPTCHA como um mecanismo de fallback humano, eu estou adicionando uma anterior pergunta StackOverflow e linha sobre a eficácia do CAPTCHA.

Tem reCaptcha sido rachado / hackeada / OCR / derrotou / quebrado?

Usando CAPTCHA faz nem melhorias limite do seu estrangulamento e outras sugestões, mas acho que o número de respostas que incluem CAPTCHA como um fallback deve considerar os métodos baseados em humanos disponíveis para as pessoas que olham para quebrar a segurança.

Você também poderia acelerador baseado na força de uma senha de usuários.

Quando um usuário se registra ou altera sua senha que você calcular um rating de força para a sua senha, digamos entre 1 e 10.

Algo como pontuação "password" a 1, enquanto "c6eqapRepe7et * Awr @ ch" pode marcar um 9 ou 10 e quanto maior a pontuação mais tempo demora para estrangular a chutar.

A primeira resposta que eu normalmente ouvido quando esta pergunta é mudar portas, mas esquecer isso e apenas desativar IPv4. Se você permitir que apenas os clientes de redes IPv6 você'r não rezam mais para digitalização em rede simples e atacantes vai recorrer a pesquisas de DNS. Não corra no mesmo endereço como o Apache (AAAA) / Sendmail (MX-> AAAA) / o que você tem dado a toda a gente (AAAA). Certifique-se de sua zona não pode ser xferd, espere você'r permitindo sua zona para ser baixado por qualquer pessoa?

Se os bots encontrar seus configuração do servidor de novos nomes de host, basta preceder alguns rabiscos para seus nomes de host e alterar o seu endereço. Deixar os nomes antigos e até mesmo instalação ** nomes honeypot para a rede bot para tempo limite por diante.

** Teste o seu reverso (PTR) registros (sob ip6.arpa.) Para ver se eles podem ser usados ??para zero em on / 4 do que têm registros VS / 4s que não. OU SEJA Normalmente ip6.arpa teria ~ 32 "" s em um endereço, mas tentando com os últimos desaparecidos pode iludir os blocos de rede que têm registros VS outros que não. Se você levar isso adiante, torna-se possível saltar grandes porções do espaço de endereço.

No pior dos usuários de caso terá que configurar um túnel IPv6, não é como se eles teriam que ir tão longe como VPNing em uma DMZ ... Embora se quer saber porque essa não é a primeira opção.

Além disso Kerberos é legal, mas golpes IMHO LDAP (o que é tecnicamente errado com nisplus? Eu li que a Sun decidiu que os usuários queriam LDAP e por isso eles caíram NIS +). Kerberos não funciona bem sem LDAP ou NIS, apenas tem que gerenciar usuários em um host por base host. Usando Kerberos dá-lhe um fácil de usar, se não automatizado, PKI.

Um pouco tarde aqui, mas eu estava pensando, assumindo um caso difícil - o atacante usa um monte de IPs aleatório, nomes de usuário aleatório e uma senha aleatória seleccionados a partir de dizer uma lista dos 10.000 mais popular

Uma coisa que você poderia fazer, especialmente se o sistema parece sob ataque em que há uma série de tentativas de senha errados no sistema e, especialmente, se a senha for baixa entropia é perguntar uma questão secundária como o que são os seus pais primeiros nomes , por exemplo. Se um atacante atinge um milhão de contas tentando a senha 'password1' há uma boa chance que vai ter um monte, mas suas chances de também obter os nomes à direita reduziria sucessos dramaticamente.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow