.:: Maurizio Pelizzone ::.

Questa mattina controllando i report di alcuni server relativi al traffico generato ho visto qualcosa di alquanto anomalo.

Il grafico che vedete rappresente l’attivita del protocollo ssh e come potete osservare dalle 4.30 alla 6.30 qualche simpatico amico a tentato un brute force.

Da una prima analisi non sembra essere successo nulla di grave in quanto dai log si può vedere un banale tentativo di dictionary attacks.

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

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

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:

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 <s>farmi dormire tranquillo</s> rimandare di 24 ore le prossime analisi.

Seguendo alcuni suggerimenti di un essere illuminato, sto lentamente mettendo in pratica quanto ascoltato durante l’ iWordCamp.

Mi appunto quindi i comandi da lanciare in modo non dovermi ricordare la sintassi ed evitare refusi…

In alcune installazioni il nome delle vostra tabelle potrebbe essere diverso… verificate quindi prima se avete usato un prefisso.
(file wp-config var $table_prefix)

Mi verrebbe anche voglia di scrivere un piccolo plugin per rendere il lavoro ancora più veloce, ma mi sembra una roba troppo banale.

N.B.
L’applicazione di questi indici è applicabile solo nel caso abbiate una versione di wordpress 2.3 o superiore.

Già che si sono segnalo anche questo script che suggerisce ulteriori tuning per il vostro database server preferito (via giorgio)

Avete mai provato a cercare su un indice FullText con una stringa sotto i 4 caratteri ?

Bhe, io dopo essere diventato scemo, ho scoperto che per default la lunghezza minima è impostata a 4 caratteri.

Se quindi state cercando stringhe come “php“,”htm” o “css“, e nonostante siate sicuri che ci siano riscontri, la ricerca non vi restituisce nessun record, non è dovuto ad una tabella corrotta, ma molto più semplicemente perché l’indice in condizioni normali non gestisce ricerche di questo tipo.

La soluzione, se siete nelle condizioni di modificare il file di configurazione, fortunatamente c’è, e prevede 3 operazioni

1. E’ necessario definire il valore della variabile ft_min_word_len all’interno del file my.cfg
   ft_min_word_len=3
2. Riavviare il server in modo che valorizzi in modo corretto la nuova impostazione
3. Per finire, è necessario fare il rebuild degli indici, in modo che vengano ricostruiti con tutte le informazioni corrette
   REPAIR TABLE nometabella QUICK;

Facile come bere un chupito… basta saperlo.

Per la documentazione ufficiale basta guardare qui

Ci sono delle volte nella vita di un sistemista dove dopo aver allestito un nuovo Windows Server 2003, aver installato tutto il necessario compresi antivirus e backup giunge il momento di configurare IIS.

Nel caso il server sia adibito ad ospitare nuovi siti, non ci sono altre alternative che la configurazione attraverso l’interfaccia di amministrazione, ma nel caso di un migrazione da un altro server, dove magari sono presenti decine e decine di siti configurati la strada “facciamolo a mano” diventa lunga ma sopratutto la probabilità di fare qualche errore aumenta in modo direttamente proporzionale al numero di siti da configurare.

Diventa quindi lecito domandarsi come importare sulla nuova macchina la configurazione presente sul vecchio server.

Purtroppo dall’interfaccia di amministrazione le uniche operazioni che riguardano la gestione del metabase di IIS sono relative al backup ed relativo ripristino, ma fortunatamente Microsoft non ci lascia completamente a mano vuota, rendendo possibile l’operazione di esportazione e importazione tramite uno script vbs utilizzabile via shell.

Dal titolo del post, avrete capito che sto parlando di iiscnfg

Dopo aver letto un po’ di documentazione ed avendo come obbiettivo l’esportazione completa del metabase del vecchio server e la sua importazione sulla nuova macchina sono stati sufficienti 2 comandi …

Questo è il comando per l’esportazione, che ovviamente va eseguito sul server in cui c’è la configurazione da copiare.

Vediamo insieme i parametri:

• /f indica che l’esportazione deve avvenire su file ( nel mio caso nomefile è c:iisconfig_backup.xml )
• /sp indica il ramo del metabase, che nel mio caso è un semplice slash che indica tutto ma potrebbe anche indicare un singolo sito
• /children consente semplicemente di esportare in maniera ricorsiva tutte le sottochiavi

Se tutto è andato bene dovremmo ritrovaci sotto c un file xml che dobbiamo far arrivare sul nuovo server per poterlo importare.

Prima di procedere all’importazione, nel caso abbiate già modificato qualcosa suggerisco un backup, che potete effettuare o tramite l’interfaccia di amministrazione o via shell con iisback.

Arrivato a questo punto vediamo il comando per l’importazione che è leggermente più complicato …

In questo caso ci sono due parametri in più:

• /dp specifica il percorso della metabase in cui vengono memorizzate le chiavi, discorso simile a quello per /sp e nel mio caso dove voglio importare tutto indico solo lo slash
• /merge consente di combinare le chiavi nel file XML con le chiavi esistenti della metabase. Forse questo parametro nel caso di una configurazione da zero è inutile, ma nel caso abbiate già fatto modificato la configurazione di IIS questo vi permettera di importare solo le chiavi nuove

Questo funziona a patto che i percorsi rimangano gli stessi, ovvero se i siti prima erano sul disco e: dovranno essere su e: anche adesso.

Nel caso non sia possibile ricreare la stessa configurazione, suggerisco la modifica del file xml con il metabase prima dell’importazione, altrimenti vi tocca modificare a mano tramite l’interfaccia di amministrazione sito per sito.

Un ultima cosa; se durante la migrazione i due server si possono “parlare” potrebbe essere più comodo copiare direttamente la configurazione tra un server e l’altro, ma nel mio caso, essendo i due server in due posti fisicamente diversi, ed essendo sotto firewall non è stato possibile praticarlo.

Sperando di non aver dimenticato nulla, e di non aver scritto caz**te, questo è quanto …

Link di riferimento: Gestione di configurazioni di IIS tramite script

[tags]IIS, metabase, iiscnfg, iisback [/tags]

SSH è uno di quei servizi che installo e configuro sempre, sia nel caso di Firewall, che di Web Server, Mail Server, File Server, ecc …

Con il rilascio di debian etch, in caso di un installazione minimale fatta tramite netinst, è necessario installarlo manualmente, ma come di sempre, questa operazione e resa banale da apt …

A differenza di altri servizi che uso come mamma debian li ha preparati, per il sig SSH ho preso l’abitudine di modificare alcuni parametri del suo file di configurazione ( /etc/ssh/sshd_config ) che poi nella pratica si riducono in verità alla “rettifica” di due parametri ed all’inserimento di una terza riga.

La prima rettifica è relativa alla porta che secondo l’ICANN è la 22 ma che quando posso cerco di cambiare.

La seconda modifica blocca l’accesso per l’utente root. In questo modo nel caso riuscissero ad entrare si trovano con un utente con permessi limitati.

Il terzo cambiamento è una conseguenza del secondo in quanto se come root l’accesso non è permesso, e bene garantirlo a qualcun’altro.

Aggiungiamo quindi una riga indicando il nome dell’utente autorizzato.

Il tempo necessario per queste operazioni e al di sotto dei 60 secondi … e personalmente ritengo che i benefici siano pienamente ripagati da cotanto lavoro.

Link per approfondire:

1. Lista di porte standard
2. Uso e configurazione di Secure Shell
3. Getting started with SSH