Ho bisogno di registrazione abilitata nelle mie regole in IPFW per sshguard-ipfw per funzionare / lista nera di ip?

Question

Ho bisogno di registrazione abilitata nelle mie regole in IPFW per sshguard-ipfw per funzionare / lista nera di ip?

#1 da (1 voti)

1

Dal manuale di FreeBSD:

Even with the logging facility enabled, IPFW will not generate any rule logging on its own. The firewall administrator decides which rules in the ruleset will be logged, and adds the log keyword to those rules.

Quindi la mia domanda è: dovrei abilitare la registrazione a qualsiasi regola per IPFW affinché sshguard-ipfw funzioni e sia in grado di inserire nella lista nera gli IP?

Ho solo regole che permettono di entrare e uscire da SSH il 22. Sarebbe logico solo loggare le regole di negazione. Gli errori di autenticazione della Pam per SSH dovrebbero essere sufficienti informazioni per sshguard-ipfw per bloccare e inserire nella lista nera gli IP?

Secondo il sito Web di sshguard puoi usarlo anche senza un firewall, quindi suppongo che i log per ipfw non contengano.

Prima che qualcuno lo dica nelle risposte per abilitare la lista nera, aggiungilo a syslog.conf auth.info;authpriv.info |/usr/local/sbin/sshguard -10:/var/db/sshguard/blacklist.db

Grazie.

authentication unix ssh firewalls

posta user26554 30.05.2013 - 12:38

fonte

1 risposta

Leggi altre domande sui tag authentication unix ssh firewalls

Protezione dei file scaricabili sul sito Web per utente Sandbox AppEngine

score 1 · Answer 1

La registrazione è aperta alla scelta e spiegherò perché. È più facile bloccare TUTTO (eliminare, non rifiutare) e consentire solo indirizzi attendibili. Ciò ti consente di creare una regola contro N quantità di regole che genereresti dalla lista nera. Dai un'occhiata alla lista nera media e troverai che ci può essere ben oltre il segno di 1k in un dato giorno. Ciò che accade è il seguente:

Firewall (essere se IPFW, IPTables, checkpoint FW, SSG, ecc.):

Connection is coming in --> Check against the first rule
Connection is coming in --> Check against the second rule
Connection is coming in --> Check against the ... rule

La tua macchina dovrà elaborare N quantità di regole - dove N è la quantità di indirizzi IP nella tua lista nera. Per non parlare, so di bot basati su ssh che falsificano gli indirizzi, quindi c'è anche la possibilità di spoofing: la macchina stessa, la route predefinita ... 0.0.0.0/0 (tutti). Pensaci per un momento. Se ho fatto quanto segue:

nmap -sS YOUR.IP.ADDRESS -p 80 -D 0.0.0.0,YOURGATEWAYIP,YOURUPSTREAMGWIP

I registri mostreranno le voci da 0.0.0.0, l'IP del gateway, l'IP GW Upstream, creando a sua volta una regola FW per bloccare le connessioni. Per evitare ciò, devi inserire l'indirizzo IP WHITELIST, creando ancora più regole:

Connection is coming in --> Check against the first rule --> WHITELISTED

Questo pacchetto verrà inviato immediatamente in base al posizionamento della regola (dovrebbe essere una delle prime. Altrimenti:

Connection is coming in --> Check against the first rule
Connection is coming in --> Check against the second rule
Connection is coming in --> Check against the ... rule
Connection is coming in --> Check against the first rule --> WHITELISTED

Più grandi diventano le tue regole, più difficile sarà mantenere. Se possibile, è meglio fare quanto segue:

firewall --> this Whitelisted address is allowed all others blocked

Una regola da elaborare rispetto a regole ingombranti. Ora, torniamo al logging; quale sarebbe l'obiettivo del logging. Arrivano gli attacchi, gli attacchi vanno. Internet è come outerspace pieno di spazzatura. Molti degli attacchi ssh provengono da host compromessi, non dal vero aggressore. Molte sono parti di botnet, alcune delle quali sono centinaia di migliaia di persone. Non solo stai sprecando potenza di elaborazione, alla fine, stai anche sprecando spazio sulle unità da quando i registri possono crescere.