Archivio

Archivio per dicembre 2009

analisi delle prestazioni del proxy con sarg e l’utility sarg-report

28 dicembre 2009

La domanda è: è possibile pulire i log di squid in modo che, quando vado a far eun report con sarg non mi riporti l’era dei tempi?

Per i vincoli dovuti alle norme sulla privacy occorre configurare il server proxy in modo che vengano mantenuti i file di log per almeno un anno e nel contempo attivare una procedura di backup e salvataggio degli stessi a livello trimestrale. Il programma da configurare per il salvataggio dei log si chiama logrotate che nel caso di squid sarà configurato come segue:

# /etc/logrotate.d/squid
# Logrotate fragment for squid
/var/log/squid/*.log {
        daily
        compress
        delaycompress
        rotate 400
        missingok
        nocreate
        sharedscripts
        prerotate
                test ! -x /usr/sbin/sarg-maint || /usr/sbin/sarg-maint
        endscript
        postrotate
                test ! -e /var/run/squid.pid || /usr/sbin/squid -k rotate
        endscript
}

Per l’analisi delle prestazioni del proxy tramite il programma sarg è preferibile settare la raccolta differenziata per mese:

# /etc/cron.monthly/squid
#Get current date
TODAY=$(date +%d/%m/%Y)

#Get current date
TD=$(date --date "1 month ago" +%Y-%m)

#Get one month ago today
YESTERDAY=$(date --date "1 month ago" +%d/%m/%Y)

#Get one month ago today (4touch)
YD=$(date --date "1 month ago" +%m/%d/%Y)

touch -d $YD /tmp/a
cat /var/log/squid/access.log.1 > /var/log/squid/monthly/squid-$TD
find /var/log/squid/ -newer /tmp/a -name access.log\*gz | \
  xargs zcat >> /var/log/squid/monthly/squid-$TD

ln -f -s /var/log/squid/monthly/squid-$TD /var/4sarg
sarg -o /var/www/squid-reports/monthly -d $YESTERDAY-$TODAY

Attenzione che i log contengono dati sensibili e quindi quelli relativi agli utenti non possono essere consultati senza infrangere la Legge Italiana.

LOG SQUID con SARG-REPORT

Configurazione di sarg

Cercare in /etc/squid/sarg.conf la direttiva language English e sostituire a English il linguaggio voluto. es.:

language Italian

Assicurarsi che la direttiva access_log punti correttamente al file contenente i logs di squid (solitamente /var/log/squid/access.log) e verificare che coincida con la direttiva access_log presente in /etc/squid.conf.

Configurazione di sarg-reports

La configurazione di /etc/squid/sarg-reports.conf di default dovrebbe andare benone, modificarla eventualmente per rispondere alle proprie esigenze.

sarg e sarg-reports

sarg-report è un shell script che permette di parsare il contenuto dei logs di squid relativi ad un certo periodo di tempo e, utilizzando sarg, generare automaticamente del codice html. Il codice html, di default, viene salvato in /var/www/https/squid-reports/. Sarà necessario dunque modificare la configurazione di apache per assicurarsi che venga pubblicata.

Nota

Si farà riferimento esclusivamente all’uso di sarg-report. I più curiosi, dopo una rapida consultazione del suo help, potranno provare a generare con sarg qualche statistica personalizzata.

L’help di sarg-reports è abbastanza esplicativo:

sarg-reports --help

SARG - Daily / Weekly / Monthly - Squid proxy usage reports creation tool
Written by Ugo Viti <ugo.viti@initzero.it>
Version: 20050202

Usage: /usr/sbin/sarg-reports [OPTIONS]

Allowed options:
    manual,  Create Manual report
     today,  Create Today report
     daily,  Create Daily report
    weekly,  Create Weekly report
    montly,  Create Monthly report

Come riportato dall’help, se volessimo generare logs per una data specifica potremmo usare:

sarg-reports manual 18/12/2008

Tutte le informazioni relative al giorno 18/12/2008 trovate in /var/log/squid/access.log verranno parsate e verrà generato un output html in /vaar/www/squid-reports/

Per verificare il risultato, si potrà provare a puntare con lynx a /var/www/squid-reports/index.html come segue:

lynx /var/www/squid-reports/index.html

Automatizzare la creazione dei logs con Crontab

Aggiungere la creazione dei logs a Cron, per eseguirle in modo automatico alla cadenza voluta:

crontab -e

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
00 00      * * * sarg-reports daily
00 01      * * 1 sarg-reports weekly
30 02      1 * * sarg-reports monthly

Per chi non conoscesse Cron e la sintassi di definizione del tempo: http://www.adminschoice.com/docs/crontab.htm#Crontab%20file

Share

Tips Linux e Microsoft

cron

26 dicembre 2009

Introduzione

Il servizio cron viene utilizzato per eseguire le azioni pianificate. Le informazioni necessarie a programmare ogni singola azione (con relativi tempi e procedure) sono indicate nel file di configurazione crontab.

Creare e modifica un crontab personalizzato

Il sistema ha un suo file di cron (presente in /etc/crontab), ma ogni utente può creare il proprio. Per creare un file di cron è sufficiente digitare il seguente comando in una finestra di terminale:

crontab -e

Il precedente comando apre un editor di testo contenente un documento vuoto nel quale andranno inseriti i comandi desiderati; tale file andrà salvato con il nome e nel percorso suggeriti dall’editor. Se la sintassi dei comandi non è corretta le azioni non verranno eseguite.

Una volta chiuso l’editor, il nuovo file di crontab verrà salvato in /var/spool/cron/crontabs.

I file di crontab possono essere modificati solo con il comando crontab -e.

Per vedere se il sistema ha salvato correttamente il proprio file di cron, digitare il seguente comando:

crontab -l

Verrà stampato l’elenco dei crontab registrati per l’utente corrente; in assenza di file di cron validi il risultato sarà simile al seguente:

no crontab for nomeutente

Esempi di sintassi dei comandi

Il file crontab deve rispettare una sintassi ben precisa, diversamente il sistema non accetterà le impostazioni. Quello che segue è un esempio generico:

5 3 * * * /usr/bin/apt-get update

L’esempio precedente eseguirà il comando apt-get update ogni giorno di ogni mese alle ore 03:05 (l’orario viene indicato nel formato a 24 ore).

La prima parte della voce descrive quando l’azione deve essere effettuata. Ci sono cinque campi (nell’esempio precedente, «5 3 * * *»), separati da uno spazio, ognuno dei quali accetta un numero, un asterisco o un testo appropriato. I campi specificano, in ordine (tra parentesi l’abbreviazione standard):

  • minuti, da 0 a 59 («m»);
  • ore, da 0 a 23 («h»);
  • giorno del mese, da 1 a 31 («dom»);
  • mese, da 1 a 12 («mon»);
  • giorno della settimana, da 0 (domenica) a 6 (sabato) («dow»).
* * * * * comando/da/eseguire
- - - - -
| | | | |
| | | | +----- giorno della settimana (0 - 6) (domenica=0)
| | | +------- mese (1 - 12)
| | +--------- giorno del mese (1 - 31)
| +----------- ora (0 - 23)
+------------- minuti (0 - 59)

Il campo del mese e quello del giorno della settimana permettono di usare un’abbreviazione, come ad esempio «jan» per gennaio (in inglese January) o «thu» per giovedì (in inglese Thursday). Quello che segue è un esempio del contenuto di un crontab di sistema:

m h dom mon dow user    command
17 *    * * *   root    run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily
47 6    * * 7   root    test -x /usr/sbin/anacron || run-parts --report /etc/cron.weekly
52 6    1 * *   root    test -x /usr/sbin/anacron || run-parts --report /etc/cron.monthly

L’asterisco «*» consente di non specificare alcun valore per il campo in cui viene inserito.

Quello che segue è un esempio utile a chiarire l’uso della sintassi:

12 03 * * 1,4 /percorso/script.cgi

Segue la spiegazione dei singoli parametri:

  • 12: minuti;
  • 03: ore;
  • *: giorno del mese (tutti i giorni);
  • *: mese (tutti i mesi);
  • 1,4: giorni della settimana, separati da una virgola (il lunedì e il giovedì);
  • /percorso/comando: comando da eseguire;.

Una volta impostata tale pianificazione, ogni lunedì e giovedì, alle ore 3:12, verrà eseguito il comando /percorso/comando.

Quelle che seguono sono alcune varianti della precedente pianificazione d’esempio:

Stringa Descrizione
«12 03 * * *» tutte le mattine, più o meno alle 3
« 12 03 15 * *» tutti i 15 del mese, alla stessa ora
«12 03 31 * *» 7 volte l’anno, alla stessa ora
«0 12 * * 0» ogni domenica, a mezzogiorno
«2 0 * * *» ogni giorno, più o meno a mezzanotte
«02 03 * * 1,5» ogni lunedì e venerdì, alle 3 del mattino circa

Seguono sono ulteriori esempi:

  • */5 9-17 * * mon,tue,wed,thu,fri wall "Siamo ancora qui?"

    Stampa un messaggio ogni 5 minuti, dalle 9 alle 17 da lunedì a venerdì.

  • 0 9 10 jan * echo "È il compleanno di tua madre oggi!" > ~/readme

    Ricorda un compleanno alle 9 di mattina del 10 gennaio di ogni anno.

Gestione dei crontab

Per vedere quali crontab sono in esecuzione sul sistema è sufficiente digitare il seguente comando:

crontab -l

Crontab per comandi root

Il file crontab dell’utente contiene comandi che verranno eseguiti con il livello di permessi dell’utente stesso. Se si desidera pianificare un’azione che richiede i privilegi di amministrazione è possibile creare un file di crontab per l’utente root con il seguente comando:

sudo crontab -e

A seconda dei comandi che si desidera utilizzare, potrebbe essere necessario modificare la variabile d’ambiente «PATH», inserendo la seguente linea all’inizio del file di crontab dell’utente:

PATH=/usr/sbin:/usr/bin:/sbin:/bin

Eseguire backup periodici

Uno degli utilizzi più frequenti del comando cron riguarda l’esecuzione periodica del backup dei dati. Nel seguente esempio cron eseguirà un backup giornaliero, alle ore 19:30, della cartella /home/utente/documenti e delle sue sottocartelle, creando un file di archivio dal nome /backup_utente.tgz.

30 19 * * * tar -cvpzf /backup_utente.tgz /home/utente/documenti

Verificare le impostazioni

Per verificare il corretto funzionamento di cron è sufficiente impostare un’azione da eseguire pochi minuti dopo la modifica del file di crontab e osservare il risultato. A tale scopo è utile inserire il comando in un file che terrà traccia del successo o del fallimento dell’esecuzione, come nell’esempio seguente:

echo "Backup riuscito: $(date)" >> /tmp/mybackup.log

Ulteriori risorse

Share

Tips Linux e Microsoft

Ssh sotto windows con OpenSSH

22 dicembre 2009

Sotto linux ssh e il relativo server sshd è fornito di default in tante distribuzioni e comunque è semplice da installare.

E’ possibile usarlo anche sotto windows grazie a OpenSSH sito dal quale potete scaricare gratuitamente il software necessario (in alternativa vedi allegato sotto).

Installare il software scaricato è molto semplice, la cartella di default dovrebbe essere “c:\programmi\OpenSSH“, selezionare tutte le opzioni e portare a termine l’installazione.

A questo punto il programa di installazione di comunicherà che dovranno essere creati gli user account necessari per poter connettersi al server ssh. Aprendo una finestra del DOS, lanciamo i seguenti comandi:

CD \Programmi\OpenSSH\bin
mkgroup -l >> ..\etc\group
mkpasswd -l  >> ..\etc\passwd

Se nel pc abbiamo più utenti ma vogliamo autorizzare un solo utente specifico ad accedere via ssh, la seconda riga va digitata in questo modo:

  mkpasswd -l -u "username" >> ..\etc\passwd

dove sostituiremo “username” con il nome utente da inserire!

Attenzione: per gli utenti di domini windows, potrebbe essere utile inserire gruppi/utenti del dominio, in questo caso i comandi da dare sono diversi: sostituiamo lo switch -l con -d come nell’esempio:

CD \Programmi\OpenSSH\bin
mkgroup -d >> ..\etc\group
mkpasswd -d  >> ..\etc\passwd

A questo punto non ci rimane che avviare il server digitando sempre dal prompt il comando:

net start opensshd
Share

Documenti Tecnici

Creare tunnel con OpenSSH e Tunnel Samba su SSH

20 dicembre 2009

Creare tunnel con OpenSSH

Dal sito di OpenSSH:

OpenSSH è una versione libera del protocollo SSH, suite dei tool per la connettività di rete…. Molti utenti che utilizzano telnet, rlogin, ftp e altri programmi simili forse non sanno che la loro password viene trasmessa attraverso la rete non criptata. OpenSSH cripta tutto il traffico (password compresa) per eliminare a tutti gli effetti l’ascolto passivo, l’hijacking della connessione e altri attacchi a livello di rete. In più, OpenSSH fornisce una miriade di possibilità di tunneling sicuro, così come una varietà di metodi di autenticazione.

Di questo ottimo prodotto open source ne esiste una versione per Win32, che installa il server OpenSSH, senza il bisogno di installare tutto il pacchetto Cygwin. Fornisce i servizi di SSH/SCP/SFTP, e l’accesso via terminale SSH presenta una shell del Prompt dei comandi.
E’ molto semplice installare il pacchetto e creare tunnel sicuri verso la macchina server, vediamo il solito esempio della connessione al desktop remoto(*). Funziona su tutte le versioni di Win32, tranne 95 e 98.
Procuratevi il pacchetto da installare sul server qui, e lanciate l’installazione. Accettate tutti i defaults e procedete fino alla fine. Aprite un prompt dei comandi e portatevi nella cartella di installazione (dovrebbe essere c:\Programmi\OpenSSH). Dovete decidere per quali utenti abilitare l’accesso, di solito è meglio per il solo amministratore. Fate un cd bin, e usate mkgroup e mkpasswd per assegnare i diritti, seguendo la sintassi che trovate nel file quickstart.txt. Terminate facendo partire il servizio: net start opensshd. Ricordate di aprire la porta TCP/22 sul router e/o firewall. Su XP SP2 aggiungete il servizio e la porta al firewall. Inoltre se non usate l’utente administrator e siete su un controller di dominio, ricordate di modificare le Group Policies in modo da permettere l’accesso all’utente desiderato.
A questo punto passiamo al client: procuratevi PuTTY, il client SSH che vi servirà per la connessione e la creazione del tunnel.
Spostatevi sul client, lanciate PuTTY, inserite l’indirizzo IP o il nome del server e nella sezione SSH –> Tunnels —> source port: 3389, destination: 127.0.0.1:3389, tipo: local.
Cliccate su Open, cliccate su Yes, se appare una dialog box che chiede di aggiungere la chiave, inserite poi nome utente e password. Se tutto è andato a buon fine vedrete il prompt dei comandi della macchina remota, sul quale potete lavorare tranquillamente.
Per sfruttare il tunnel creato usiamo la Connessione a Desktop Remoto, modificata come ho scritto qui. Lanciate il programma ed effettuate la connessione verso 127.0.0.1. Ecco il vostro desktop remoto, tunnellato su di una connessione sicura!
Per creare tunnel verso altri servizi è sufficiente aggiungerli prima della connessione, e poi dal client puntare all’indirizzo 127.0.0.1.
OpenSSH installa anche un server sftp, una versione sicura di ftp che non manda le password in chiaro, potete usare diversi client per connettervi, io uso WinSCP, open source. Si usa come un client ftp normalissimo.
Qualora si volesse creare un tunnel verso un PC diverso dal server OpenSSH, ma da lui raggiungibile, basterà creare il tunnel specificando l’indirizzo IP locale della macchina di destinazione.
La cosa bella è che il tunnel viene creato “al volo” sul client ad ogni connessione, e non devo configurare nulla sul server.

Tunnel Samba su SSH

Assumiamo che il server SSH sia correttamente funzionante e accetti connessioni dall’esterno.
Tutti la documentazione che ho trovato sostiene che sia necessario, per un client XP, disinstallare la “Condivisione Files e Stampanti”, in realtà non è vero. Ecco i passi necessari, dove supponiamo che l’indirizzo privato del server sia 10.0.0.1, ed il client sia PuTTY su WinXP (la procedura è simile per Win2000). Nessuna operazione è necessaria sul server.

  • Disattivare “Condivisione files e stampanti per reti Microsoft” (basta disattivare la checkbox), nelle proprietà della scheda di rete che si usa per la connessione.
  • Lasciare attivo “Client per reti Microsoft”, poi vi dico perchè.
  • Fermare il servizio “Server”: da riga di comando impartire net stop server, e confermare anche l’arresto del servizio browser.
  • In PuTTY, creare un tunnel che abbia come source “127.0.0.1:139″ (ci sta anche se la casella è piccola) e target 10.0.0.1:139.
  • Connettersi al server e aprire le share su \127.0.0.1.

Se tutto è andato a buon fine si dovrebbero vedere le condivisioni sul server. Si possono navigare o connettere come unità di rete.
Per ragioni di sicurezza, l’utente abilitato alla connessione SSH potrebbe non avere alcun permesso sul filesystem, per questa ragione dopo aver digitato \127.0.0.1, potrebbe apparire la richiesta di login, che va compilata con le credenziali di un utente che abbia accesso alle share. Questo è il motivo per cui bisogna lasciare attivo “Client per reti Microsoft”.
Ho verificato questo metodo con diverse coppie di client/server e ha sempre funzionato.
Attenzione: fermando il servizio server vengono chiuse tutte le eventuali connessioni alle condivisioni presenti sulla macchina, quindi fate attenzione. Per far ripartire il servizio senza riavviare la macchina è sufficiente un net start server e riabilitare “Condivisione files e stampanti per reti Microsoft”.

Share

Documenti Tecnici

Sincronizzazione del tempo con NTP – Linux

17 dicembre 2009

Sincronizzazione del tempo con NTP

Questa pagina descrive i metodi per mantenere l’ora esatta del proprio computer, utile per i server, ma non necessario (o desiderabile) per macchine desktop.

NTP è un protocollo TCP/IP per sincronizzare l’ora attraverso la rete: un client richiede l’ora corrente a un server e usa questa per impostare il proprio orologio.

Dietro questa semplice descrizione, c’è molta complessità. Ci sono vari livelli di server NTP, con il primo livello di server NTP collegati a orologi atomici (spesso tramite GPS) e il secondo e terzo livello di server che si dividono il carico delle attuali richieste. Anche il programma client è molto più complesso di quanto si possa pensare: deve considerare i ritardi di comunicazione e correggere l’ora in modo tale da non invalidare tutti gli altri processi che sono in esecuzione sul server. Fortunatamente tutta questa complessità è nascosta all’utente.

Ubuntu ha due metodi per impostare automaticamente l’orologio: ntpdate e ntpd.

ntpdate

Ubuntu dispone, in modo predefinito, di ntpdate, che viene eseguito ad ogni avvio, per impostare l’ora con il server NTP di Ubuntu. L’orologio di un server, comunque, è soggetto a cambiamenti di orario anche considerevoli tra due riavvii. È quindi utile correggere l’ora occasionalmente. Il modo più facile per farlo, è impostare cron per eseguire ntpdate giornalmente. Con un editor di testo, con i permessi di amministratore, creare il file /etc/cron.daily/ntpdate con il seguente contenuto:

ntpdate ntp.ubuntu.com

Il file /etc/cron.daily/ntpdate deve essere eseguibile.

sudo chmod 755 /etc/cron.daily/ntpdate

ntpd

ntpdate è uno strumento abbastanza semplice. Può regolare l’ora una sola volta al giorno in un’unica modifica. Il demone di ntp (ntpd) è molto più raffinato. Calcola lo spostamento dell’orologio del proprio sistema e lo regola continuamente, così non ci sono mai grandi modifiche che possono portare a file di log inconsistenti. Il costo di questo è un leggero uso di processore e memoria, ma trascurabili per un server moderno.

Per usare ntpd:

sudo apt-get install ntp-simple
Share

Tips Linux e Microsoft

Controllo degli accessi su SSH

12 dicembre 2009

Spesso, osservando il file auth.log,  possiamo notare tentativi di accesso alla porta ssh nella nostra distribuzione linux.

Sotto potete vedere una parte del log restituito da questo comando:

# cat /var/log/auth.log | grep ssh | grep “invalid user”

Nello stesso modo ho poi verificato gli accessi “autorizzati” e fortunatamente non ne risultano altri oltre a quelli fatti dal sottoscritto:

# cat /var/log/auth.log | grep ssh | grep Accepted

E’ anche vero che nel caso in cui il nostro hackers fosse riuscito ad accedere avrebbe potuto eliminare una parte dei log ma voglio pensare che avrebbe eliminato tutti i riferimenti al suo ip.

Anche se considero l’attacco fallito ho cercato in rete come evitare questo tipo di attacchi e come in tante altre occasioni la ricerca è durata meno di un minuto: Preventing SSH Dictionary Attacks With DenyHosts

DenyHosts è un tool di sicurezza scritto in Python per server SSH. È pensato per prevenire attacchi brute force verso server SSH monitorando i tentativi di login invalidi nel log di autenticazione e bloccando gli indirizzi IP. (via wikipedia)

Dopo aver verificato se il pacchetto fosse già presente nei repository debian ho provveduto al solito:

# apt-get install denyhosts

Una veloce occhiata al file di configurazione per modificare la mail a cui inviare gli avvisi sui nuovi hosts bloccati ed un controllo lo script fosse in funzione come servizio sono al momento sufficenti per stare tranquiloo e rimandare di 24 ore le prossime analisi.

Configurazione di denyhosts.cfg

Prendo paro paro il mio file di configurazione con una spiegazione tutta mia. Le FAQ sul sito e i commenti su denyhosts.cfg sono molto esaustivi ma degli esempi in più non fanno mai male e non vi faranno sicuramente schifo (vero?). Comunque sia sto usando la versione 2.6 di denyhosts.

SECURE_LOG = /var/log/auth.log Ovviamente questo è il file che denyhosts parsa per andare a pescarsi gli IP da bannare.

HOSTS_DENY = /etc/hosts.deny In un sistema Linux è qui che ci sono le regole per il TCP Wrapper degli IP a cui è vietato l’ingresso nel sistema.

PURGE_DENY = 2d Ricordo che stiamo parlando di uso domestico, quindi abbiamo un indirizzo dinamico raggiungibile magari, con l’ausilio di dyndns come ho fatto io, con un URL www. Ma abbiamo sempre un indirizzo dinamico e ad ogni caduta di connessione (grazie Telecom) cambiamo spesso IP. Quindi gli script-kiddies non punteranno sempre a noi pensando che siamo sempre noi cambiando, magari, gli username e password. Insomma non siamo un bersaglio fisso! Quindi è inutile riempire /etc/hosts.deny di IP. Anche perché magari pure gli script-kiddies hanno IP dinamici come tutti i comuni mortali (a parte i compuer zombie ma si spera di no). Quindi è meglio ripulire /etc/hosts.deny abbastanza spesso. 2d infatti sta per 2 day: due giorni.

BLOCK_SERVICE = ALL Ok, abbiamo solo sshd attivo come servizio. Sarebbe più logico mettere BLOCK_SERVICE = sshd. De gustibus. Questo cambia ovviamente le occorrenze di /etc/hosts.deny che dal mio esempio precedente diventerebbero

# DenyHosts: Sat Nov 21 13:05:13 2009 | sshd: 123.123.123.123
sshd: 123.123.123.123

Denyhosts è molto configurabile, può controllare o tutti i servizi o solo quello che vogliamo noi.

DENY_THRESHOLD_INVALID = 2 Ogni due tentativi da parte di un username invalido (che non esiste sul sistema o che non è specificato in AllowUsers o AllowGroups in /etc/ssh/sshd_config) l’IP viene bannato. Metti che uno al posto di scrivere cicciobanza scrive cicciobnza…lo banniamo subito? Diamogli una seconda possibilità.

DENY_THRESHOLD_VALID = 3 Diamo invece tre tentativi a un user valido nel sistema, magari ha la giornata storta e sbaglia la password (che comunque, siamo stati bravi, è un’autenticazione chiave pubblica/privata).

DENY_THRESHOLD_ROOT = 1 Diciamo che se uno tenta subito root lo banniamo immediatamente..vero?

DENY_THRESHOLD_RESTRICTED = 1 Questa è una sboronata. Possiamo specificare degli username (in /var/lib/denyhosts/restricted-usernames) a cui possiamo dare tot tentativi. Io ho messo 1 perché ci metto i classici: mysql, test, user…i soliti username che non andrebbero mai usati…

WORK_DIR = /var/lib/denyhosts Si commenta da sola, io la lascio così di default e consiglio di fare altrettanto!

SUSPICIOUS_LOGIN_REPORT_ALLOWED_HOSTS=YES A dire la verità non ho ben capito. Sembra che denyhosts si faccia dei sospetti di attacco anche sugli hosts della nostra sottorete e ci avverta di questo. Ho lasciato YES ma approfondirò in seguito…

HOSTNAME_LOOKUP=NO A dire la verità non ho capito molto questo. Non ho capito cosa se ne faccia denyhosts del nome host dell’IP associato che blocca. Approfondirò anche questo…

LOCK_FILE = /var/run/denyhosts.pid Si commenta da solo, lasciamolo così com’è.

ADMIN_EMAIL = Lo lascio vuoto, non ho nessun Postfix o simili installato sul sistema che invii mail di avvertimento quindi…

AGE_RESET_VALID=1m Resetta i tentativi, dopo un minuto di inattività, di un utente valido. Del tipo, scannate password, aspettate un minuto: avete ancora 3 tentativi (riguardate DENY_THRESHOLD_VALID).

AGE_RESET_ROOT= Se uno tenta root non gli diamo altre possibilità.

AGE_RESET_RESTRICTED= Se uno tenta mysql non gli diamo altre possibilità.

AGE_RESET_INVALID= Se uno tenta un utente invalido non gli diamo altre possibilità.

DAEMON_LOG = /var/log/denyhosts Si commenta da solo. Comunque è meglio aggiungere /var/log/denyhosts in /etc/logrotate.d/syslog-ng in modo che logrotate faccia la rotazione anche dei log di denyhosts.

DAEMON_SLEEP = 1m Ogni minuto denhyhosts controlla i file di log. Ci saranno comunque dei tentativi, in un minuto, gli script kiddies provano circa 5-10 username al colpo.

DAEMON_PURGE = 1h Il periodo, quando denyhosts è daemonizzato, con il quale controlla le occorrenze di /etc/hosts.deny e le toglie (in base ovviamente a PURGE_DENY)

Queste sono configurazioni base e utili per un sistema casalingo.

Share

Tips Linux e Microsoft