Network Lab

Nel momento stesso in cui mettete una macchina in internet con alcune porte aperte sapete per certo che sarà oggetto di ogni possibile attacco. Spesso i nostri server funzionanao anche da firewall in situazioni “piccole”, ovvero di poche macchine.

In queste occasioni le fonti più comuni di debolezze sono:

1. ssh tramite account troppo semplici (password banali)
2. apache tramite applicazioni poco sicure

per quanto riguarda il primo punto è facile mettere la macchina in sicurezza con ben poca fatica, tramite l’uso delle chiavi crittografiche.

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
PermitRootLogin no

Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120s
PermitRootLogin no
StrictModes yes
MaxAuthTries 4

#RSAAuthentication no
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2

HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes

AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM yes

#l'utente "utente1" si puo' loggare solo da qualunque indirizzo
#AllowUsers utente1@*

#l'utente "utente2" si puo' loggare solo da tutte le postazioni del network
#192.168.0.0 :
#utente2@192.168.0.*

#Solo "utente1" potrà collegarsi a ssh. Questa direttiva escluderà tutti gli
#altri
#AllowUsers utente1

#Per creare un utente guest "localuser" con una password nota a tutti ma
#impedirne l'accesso via ssh da remoto:
#DenyUsers localuser

nnadalca Tips Linux e Microsoft ssh

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

nnadalca Documenti Tecnici ssh

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”.

nnadalca Documenti Tecnici ssh

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:

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 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.

nnadalca Tips Linux e Microsoft ssh

Capita spesso che  per aumentare un pò la sicurezza di poter vedere da quale ip, a quale orario e con quale login è stato effettuato l’accesso alvostro host linux.

Ecco qui , basta inserire questa linea alla fine del  file /etc/profile  ed il gioco è fatto.

Riceverete nella vosta mail un pò di dati. Nella descrizione “Accesso sul server xxxxxx” potete impostare a piacere la descrizione del vostro server, poi basta sostituire in “mail@dominio.it” la vostra e.mail.

echo “$HOSTNAME: $USER loggato in data: `date` (`echo $SSH_CLIENT | awk ‘{print$1}’` su `echo $SSH_TTY`)” | mail -s “Accesso sul server xxxxx”      mail@dominio.it

nnadalca Tips Linux e Microsoft ssh