Protezione dei server Linux: iptables vs fail2ban

Vorrei scegliere il cervello della comunità per quanto riguarda la sicurezza del server Linux, in particolare per quanto riguarda gli attacchi di bruta forza e utilizzando fail2ban vs iptables personalizzati.

Ci sono poche domande simili, ma nessuno di loro affronta l'argomento alla mia soddisfazione. Insum cerco di determinare la soluzione migliore per proteggere i server linux esposti a Internet (eseguendo i soliti servizi, ssh, web, mail), da attacchi bruta.

  • ssh_exchange_identification: leggi: Connessione resettata da peer
  • Come si imposta le regole di output con iptables (su Ubuntu)?
  • OpenSSH qualcosa come 'internal-sftp' ma per SCP?
  • Configurare SSH per ascoltare la port 443 su un indirizzo IP specifico
  • MySQL che abilita il log di query solo per l'utente root
  • Sono necessarie chiavi RSA per le configurazioni LAN solo?
  • Ho una maneggevolezza decente sulla sicurezza del server, vale a dire bloccando lo ssh non consentendo l'accesso di root o password, modificando la port predefinita, assicurando che il software sia aggiornato, controllando i file di registro, solo consentendo a determinati host di accedere al server e di utilizzare la sicurezza strumenti di controllo quali Lynis ( https://cisofy.com/lynis/ ), per la conformità generale alla sicurezza, per cui questa domanda non è necessariamente per quanto riguarda anche se l'input e il consiglio sono sempre benvenuti .

    La mia domanda è la soluzione che dovrei usare (fail2ban o iptables) e come devo configurarla, oppure dovrei usare una combinazione di entrambi per proteggere contro gli attacchi di forza bruta?

    C'è una risposta interessante riguardo all'argomento ( Denyhosts vs fail2ban vs iptables – il modo migliore per impedire gli accessi della forza bruciata? ). La risposta più interessante per me personalmente è stata ( https://serverfault.com/a/128964 ) e che il routing iptables si verifica nel kernel in contrasto con fail2ban che utilizza strumenti di modalità utente per analizzare i file di log. Fail2ban utilizza iptables ovviamente, ma deve ancora analizzare i file di registro e corrispondere a un model fino a eseguire un'azione.

    Ha senso quindi usare iptables e utilizzare il limite di tasso ( https://www.rackaid.com/blog/how-to-block-ssh-brute-force-attacks/ ) per abbandonare le richieste da un IP per un periodo del tempo che fa troppi tentativi di connessione durante un determinato periodo, indipendentemente da quale protocollo stava tentando di connettersi? Se è così, allora ci sono alcuni pensieri interessanti sull'utilizzo di drop vs reject per quei pacchetti qui ( http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject ), qualsiasi pensiero su questo?

    Fail2ban consente la configuration personalizzata in forma di essere in grado di scrivere regole personalizzate per i servizi che potrebbero non essere indirizzati nella configuration predefinita. È facile da installare e da configurare ed è potente, ma potrebbe essere un overkill se tutto quello che sto cercando è quello di ' bloccare ' un IP dal server se fanno 2 tentativi di accesso non riusciti su qualsiasi servizio / protocollo su un importo x di tempo?

    L'objective qui è quello di aprire rapporti logger giornalieri e non è necessario scorrere le pagine di tentativi di connessioni fallite al server.

    Grazie per aver preso il tempo.

    3 Solutions collect form web for “Protezione dei server Linux: iptables vs fail2ban”

    dovrei usare fail2ban o iptables?

    Si utilizza fail2ban in aggiunta a una soluzione firewall per estendere su richiesta le regole firewall esistenti con regole per bloccare gli indirizzi IP specifici dei sisthemes che eseguono azioni indesiderate in altri servizi pubblici. Lavorano in concerto tra di loro.

    Semplificato: un firewall vede solo le connessioni di networking e i pacchetti e può avere un certo senso dei templates in esso ma non ha la conoscenza del livello di applicazione per distinguere le richieste desiderate e valide dalle richieste dannose, malformate e indesiderate. Ad esempio il tuo firewall non è in grado di distinguere tra un gruppo di richieste API HTTP e un numero di tentativi di accesso non corretti causati dalla password di forza bruta sulla pagina di amministrazione di WordPress, al firewall entrambi sono solo connessioni TCP alla port 80 o 443.

    Fail2ban è un approccio generico e estensibile per fornire un approccio a livello di applicazione al tuo firewall, anche se in qualche modo indirettamente.
    Frequentemente le applicazioni registreranno e registreranno richieste dannose, malformate e indesiderabili in quanto tali, ma raramente avranno la capacità nativa di prevenire ulteriori abusi. Anche se è leggermente disaccoppiato, Fail2ban può quindi agire su quegli events danneggiati registrati e limitare i danni e impedire ulteriori abusi, in genere riconfigurando dynamicmente il proprio firewall per negare ulteriore accesso. In altre parole, Fail2ban dà le tue applicazioni esistenti, senza modificarle, i mezzi per evitare l'abuso.

    Un metodo diverso per fornire firewall alle intuizioni a livello di applicazione sarebbe tramite un sistema di rilevamento / prevenzione delle intrusioni .


    Ad esempio un webserver è un servizio pubblico comune e nelle tue porte TCP firewall le porte 80 e 443 sono aperte per internet in grande.
    Di solito non si dispone di limitare le tariffe sulle porte HTTP / HTTPS poiché molti utenti validi possono avere un'origine singola quando sono ad esempio dietro un gateway NAT o un proxy web.

    Quando rilevi azioni indesiderate e / o dannose verso il tuo server web, utilizza fail2ban per automatizzare il block di un tale autore (bloccandoli completamente o bloccando solo l'accesso alle porte 80 e 443).

    D'altra parte l'accesso SSH non è un servizio pubblico, ma se non sei in grado di limitare l'accesso SSH nel tuo firewall a solo intervalli di indirizzi IP elencati in bianco, le connessioni in entrata che limitano le tariffe sono un modo per rallentare il bruto – attacchi di forza. Ma il tuo firewall non è ancora in grado di distinguere tra bob utente che accede correttamente a 5 volte perché gestisce playbook e 5 tentativi falliti di accedere come root da un bot.

    dovrei usare fail2ban o iptables?

    Questo è un po 'simile a chiedere "dovrei usare una cintura di sicurezza o una macchina?".

    Innanzitutto, ricorda che fail2ban è veramente solo uno strumento per rilevare automaticamente voci ricorrenti nei file di text e eseguire un command quando quelli soddisfano una soglia specificata.

    Lo usiamo spesso per bloccare gli host che violano alcune politiche come dimostrato da voci di registro ricorrenti che indicano una violazione delle norme, ma non è l'unica cosa per cui è ansible utilizzare.

    È ansible utilizzare fail2ban per aggiungere (e rimuovere) le regole iptables su richiesta. È inoltre ansible aggiungere e rimuovere manualmente le regole iptables, oppure è ansible utilizzare fail2ban per fare qualcosa di completamente diverso in risposta. Tutto su come configurarlo.

    È necessario disporre di firewall generale indipendentemente dal fatto che si esegue fail2ban o less. Tale firewall sarebbe ad esempio bloccato (traffico in entrata o in output) che sapete non sarà mai legittimo. Ad esempio, il server di database ha veramente bisogno di affrontare le connessioni in arrivo sulla port 25 da Internet integer?

    Oltre a questo, essendo fallito rispondere alle violazioni delle norme, tagliando fuori gli IP offensivi per un po ', non farà molto per proteggere il server in (un buon exploit deve solo avere una volta il tuo firewall) ma ridurre il livello di rumore sul sistema, inclusi ma non limitati ai registri di sistema. Il modo semplice per farlo è avere failtaban eseguire iptables per configurare il kernel per abbandonare i pacchetti per un po '. Se è ansible riconfigurare il tuo firewall perimetrale anziché solo il firewall host, allora solo molto meglio.

    In altre parole, nella misura in cui possono essere facilmente separati, si desidera entrambi.

    potrebbe essere un overkill se tutto quello che sto cercando è quello di 'bloccare' un IP dal server se fanno 2 tentativi di accesso non riusciti su qualsiasi servizio / protocollo rispetto alla quantità di tempo di ascia?

    Questo è esattamente il caso di utilizzo fail2ban è progettato per risolvere. L'utilizzo di uno strumento per il suo scopo non è quasi mai overkill.

    L'objective qui è quello di aprire rapporti logger giornalieri e non è necessario scorrere le pagine di tentativi di connessioni fallite al server.

    Un lato, non direttamente correlato alla tua domanda: each volta che filtri i registri per la revisione, consideri cosa farai su una particolare voce. Se tutto quello che dovrai fare su una voce è dire "meh" e passare, allora probabilmente vuoi filtrarlo. Assicurarsi di salvare i registri completi per la revisione se necessario, ma spingere solamente nel tuo normale stream di lavoro di monitoraggio la roba che stai realmente facendo qualcosa con quando viene visualizzato. Se si imposta un fail2ban per bloccare un host dopo alcuni tentativi di connessione non riusciti, le probabilità sono abbastanza buone che non sarà necessario riesaminarle manualmente e potete distriggersrle dalle notifiche di monitoraggio. Se un utente legittimo si lamenta della perdita di accesso, basta estrarre i registri completi e dare un'occhiata.

    Ho risolto la stessa domanda qualche anno fa. Ho deciso di utilizzare iptables con il module più recente a causa della prestazione e dell'installazione facile. Ho dovuto proteggere un sacco di contenitori virtuali sugli host. Tieni sempre presente di non aprire alcun vector DOS con le tue regole. Utilizza anche ipset per abbinare le liste di networking o elenchi di ip nelle regole. Lo uso per liste bianche. Tutte le reti di un paese in una list sono ottimi per la sintonizzazione. E 'molto facile proteggere un altro servizio con le stesse regole solo aggiungendo un'altra port a corrispondenza. Quindi non mi piace cambiare con fail2ban ma forse qualcuno con altre esigenze sarà felice di fail2ban.

    Ecco un esempio:

      # # SSH tracking sample # ################################################################################# iptables -X IN_SSH iptables -N IN_SSH iptables -A IN_SSH -m set --match-set net_blacklist src -p tcp -j REJECT iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp --match limit --limit 5/second -j LOG --log-prefix whitelist_de_prefix iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp -j ACCEPT # filter update iptables -A IN_SSH -m recent --name sshbf --set --rsource # connlimit iptables -A IN_SSH -m connlimit --connlimit-above 4 --match limit --limit 5/second -j LOG --log-prefix ssh_connlimit_per_ip_above_4 iptables -A IN_SSH -m connlimit --connlimit-above 4 -j REJECT # filter iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 --match limit --limit 5/second -j LOG --log-prefix ssh_filtered_13in60sec iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 -j REJECT iptables -A IN_SSH -j ACCEPT iptables -A FORWARD -p tcp --dport ssh --syn --jump IN_SSH # iptables -A INPUT -p tcp --dport ssh --syn --jump IN_SSH 

    L'output dei messaggi di logging potrebbe essere combinato con fail2ban. È ansible utilizzarlo anche per le regole INPUT.

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