Come posso combattere tutti questi attacchi di forza?

Ho 3 server dedicati, tutti CentOS funzionanti che sono fisicamente situati in Canada.

Sul nuovo server, cPHulk ha iniziato a rilevare i tentativi di accesso non riusciti (e la blacklist). È iniziato il giorno in cui il server è stato messo in linea. Da allora, ho 15-30 email each giorno da cPHulk facendomi sapere che c'è stato un "grande numero di tentativi di login falliti".

  • Apache non si avvia dopo l'installazione di mod_ssl su CentOS
  • su authorization negata
  • Dove posizionare Web Root in CentOS? / var / www / o / home / user / public_html /?
  • CentOS colors nelle applicazioni php-cli
  • Consenti SSH solo su uno degli indirizzi IP dei server
  • Come faccio ad aggiungere olcAuditLogConfig a openldap su Centos 6
  • Ho notato che tutti i tentativi sono venuti dalla Cina, quindi ho installato CSF ​​e bloccato completamente la Cina. Un paio di giorni dopo, gli attacchi sono tornati ma da diversi paesi. Finora ho bloccato quattro paesi dalla disperazione, ma so che non è una riparazione legittima. Ora stanno provenienti da paesi che non posso permettermi di bloccare perché posso prevedere traffico legittimo da questi paesi.

    Ricevo anche degli attacchi da IP che non sembrano essere associati a un Paese, come in questo screenshot:

    http://i.imgur.com/LN6qmfK.png

    Non sono preoccupato di poter indovinare la password poiché la password che uso è molto forte.

    Quindi le mie domande sono, perché stanno puntando sul mio server e come hanno trovato così in fretta? Come posso mitigare questi tentativi di accesso senza bloccare intere nazioni? E da where è l'IP nello screenshot? La mia sola ipotesi è che in qualche modo mi sia stato assegnato un IP con una reputazione terribile, ma la mia esperienza di amministrazione del server e la conoscenza sono un po 'limitate, quindi non so neanche la plausibilità.

    3 Solutions collect form web for “Come posso combattere tutti questi attacchi di forza?”

    Come ha detto Michael Hampton, [TM] lo fanno a tutti. I loro script hanno rilevato un indirizzo IP in ascolto su una port e stanno lanciando nomi di utenti e password per vedere se qualcosa si blocca. Questa è una mappa di attacchi dal vivo.

    Se i messaggi di posta elettronica vi preoccupano, puoi abilitare innanzitutto gli IP di accesso consentiti e inviarti un'e-mail quando qualcuno accede da un sito che non è nel whitelist.

    Per quanto riguarda l'IP nello screenshot, 0.42.0.0 :

    L'indirizzo 0.0.0.0 può essere utilizzato solo come indirizzo di un pacchetto in output quando un computer sta imparando l'indirizzo IP da utilizzare. Non viene mai utilizzato come indirizzo di destinazione. Indirizzi che iniziano con "0." sono talvolta usati per le trasmissioni a dispositivi direttamente collegati.

    Se vedi gli indirizzi che iniziano con un "0." in log è probabilmente in uso nella tua networking, che potrebbe essere piccola come un computer collegato a un gateway di casa.

    Questo block è stato assegnato dall'IETF, l'organizzazione che sviluppa protocolli Internet, nel documento standard RFC 1122 e viene ulteriormente documentato nel documento Best Practice Current RFC 6890. IANA è elencato come dichiarante per chiarire che questa networking è non assegnato a nessuna organizzazione.

    Questi documenti possono essere trovati all'indirizzo http://datatracker.ietf.org/doc/rfc1122 http://datatracker.ietf.org/doc/rfc6890

    Sono sorpreso che nessuno lo ha portto, ma un modo drastico per uscire da questi attacchi molto comuni di bruta è quello di mettere in atto un demone che knockd demone come knockd . Pertanto, a less che l'attaccante non esegua la scansione della propria macchina con una specifica sequenza di porte nell'ordine corretto, non troverà neppure aperta una port SSH. Per utenti legittimi, molti client SSH lo supportno e sono in grado di triggersre la sequenza di porte corretta prima di connettersi al server ssh.

    Ma ovviamente, in quasi tutti i casi non è sufficiente l'authentication non banale con un carcere in esecuzione fail2ban e tempi appropriati di ricerca e di arresto.

    Se si tratta solo di sshd – vedere ad esempio qui https://unix.stackexchange.com/questions/21639/internet-ssh-server-security-considerations .

    Devo contare sull'utilizzo di username e password, non chiavi. Per essere più sicuri, iniziano la sshd ad una port non standard, che sembra ostacolare circa il 99% circa degli attacchi. Quindi, impostare LoginGraceTime nei tuoi configs di sshd, per esempio 10 Questo significa che, dopo 3 errori, il tentativo successivo può essere eseguito solo dopo 10 secondi che fornisce un tentativo di authentication 10 secondi prima di chiudere la connessione. Così, la forza bruta non è più così forzosa 🙂 Inoltre, assicurarsi di impostare PermitRootLogin no .

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.