Archivi tag: ssh

check_arptables: script Nagios per verificare lo stato di arptables_jf

In questo post ho discusso della configurazione di LVS in modalità Direct Routing. Tale configurazione richiedeva l’installazione e la corretta configurazione di arptables_jf per la gestione delle richieste ARP dirette ai frontend. Adesso vedremo come verificare l’effettivo funzionamento del suddetto applicativo attraverso l’NMS open source per eccellenza, Nagios.

nagiosCreazione dell’eseguibile e configurazione dell’NMS

Il codice bash che ho creato per effettuare i controlli sullo status di arptables_jf è il seguente:

#!/bin/bash

host=$1
warning=$2
critical=$3

usage="check_arptables <host> <warning> <critical>"

if [ -n "$host" ]; then

        if [ -n "$warning" ];then

                if [ -n "critical" ];then

                        if [ "$warning" -lt "$critical" ];then

                                echo "UNKNOWN: warning has to be greater than critical"
                                exit 3;

                        else

                                output=`sudo arptables -L | grep -v Chain | grep -v target | wc -l`

                                if [ "$output" -le "$critical" ];then

                                        echo "CRITICAL: total number of rules is $output";
                                        exit 2;

                                elif [ "$output" -gt "$critical"  -a  "$output" -le "$warning" ];then

                                        echo "WARNING: total number of rules is $output";
                                        exit 1;

                                else

                                        echo "OK: total number of rules is $output";
                                        exit 0;

                                fi
                        fi
                else

                        echo "$usage"
                        exit 3;

                fi
        else

                echo "$usage"
                exit 3;

        fi
else

        echo "$usage"
        exit 3;

fi

Il suddetto codice è abbastanza esplicativo: dopo aver verificato la presenza di tutti i parametri richiesti e la loro consistenza (ovvero la soglia di warning deve essere strettamente maggiore di quella di critical), viene effettuato il conteggio delle regole arptables attive sul frontend monitorato. Il comando principale è il seguente:

sudo arptables -L | grep -v Chain | grep -v target | wc -l

Da notare che è presente la direttiva sudo poichè l’applicativo arptables richiede i privilegi di root per essere eseguito. Rendiamo il suddetto codice eseguibile:

[root@NMS ~]# chmod +x check_arptables

e copiamolo nella directory /usr/lib64/nagios/plugins del frontend:

[root@NMS ~]# scp check_arptables root@frontend.dominio.com:/usr/lib64/nagios/plugins

Ora è possibile, all’interno della configurazione di Nagios, definire il comando da lanciare per monitorare arptables sul frontend (all’interno del file /etc/nagios/commands.cfg):

# 'check_remote_arptables' command definition
define command{
        command_name    check_remote_arptables
        command_line    $USER1$/check_by_ssh -H $HOSTADDRESS$ -C "/usr/lib64/nagios/plugins/check_arptables $ARG1$ $ARG2$ $ARG3$"
        }

Tale comando non fa altro che connettersi al frontend via SSH (senza password, mediante un semplice scambio di chiavi RSA) e lanciare l’eseguibile precedentemente creato.

Nella configurazione di Nagios relativa allo specifico frontend, invece, occorre creare un servizio simile al seguente:

define service{
        use                             local-service         ; Name of service template to use
        host_name                       frontend.dominio.com
        service_description             Arptables Rules Status
        check_command                   check_remote_arptables!localhost!3!2
        notifications_enabled           0
        }

Configurazione del frontend

Sul frontend è sufficiente editare il file /etc/sudoers per consentire all’utente nagios di lanciare il comando arptables senza sessione TTY e senza richiesta di inserimento della password. Nella fattispecie, nel primo caso è sufficiente commentare la direttiva:

#Defaults requiretty

mentre nel secondo caso occorre inserire la seguente stringa:

nagios  ALL=(root)      NOPASSWD: /sbin/arptables

A configurazione del frontend terminata possiamo lanciare sull’NMS il comando:

[root@NMS ~]# service nagios reload

ed abbiamo finito.

Ora arptables è correttamente monitorato.

Alla prossima.

Fingerprint SSH su macchine *nix

Mi sono sempre chiesto come venisse generato il fingerprint SSH sulle macchine *nix, grazie al quale è possibile identificare in modo univoco il server al quale ci si sta connettendo (in barba ad eventuali attacchi MITM).

sshIn soldoni, la prima volta che ci si connette al server, sul nostro client (nel file known_hosts) viene salvata una entry contenente FQDN, IP, tipologia di chiave (ad esempio ssh-rsa) e chiave pubblica codificata in base64.

Successivamente, ad ogni nuova connessione, verrà comparato il fingerprint restituito dal server remoto con quello calcolato sulla chiave pubblica salvata nel file known_host. Se i due fingerprint corrispondono significa che il server a cui ci si sta collegando è quello lecito.

Ma come viene calcolato questo fingerprint? Semplice, ottenendo il digest MD5 dalla chiave pubblica del server remoto salvata nel file known_hosts (e quindi codificata in base64).

Ecco il comando:

[root@client ~]# echo 'AAAAB3NzaC1yc2EAAAABIwAAAQEA0wpEu8edkvPEXqMw7nzOG/fEGE5sZCbwYnECEzlMuYi6DPSWuPJfq4U/N2Gp8RZjXQCs9TrZM91t8GIxxLuae1cZ6kelx+h1tlbh1Rj/n+qzYtjVF4XH4qHfV7Ch7nOBplKKxsNRPb7VtxYzoqgiQEi9xqN0Fgj2GcgxYAHq79qk1lvXGNVJGkDtHpt2x2/BmRLkceyId+xMflq2D4QIvEp8m4leAbYZ04ZU6/Dt44xkA1HQcpZ9ivs8OGoGclPD4QJn80+hy7E0p+O7sAQ3DeAGkoZi8ufOmYG9r4DtvnQJplTffVQwmU9y8dBH9/zit1kawkZscG6yzW2BdrhrGH==' \
    | base64 -d | md5sum

il cui output sarà:

414bb2dbd1ba63e6b16117a2abc20bb2

ovvero il fingerprint del server remoto senza i : ogni 2 digit (41:4b:b2:db:d1:ba:63:e6:b1:61:17:a2:ab:c2:0b:b2)

Alla prossima.

Server SFTP multiutenza su CentOS 6

Scenario

Server Web su cui N sviluppatori hanno la necessità di caricare i nuovi contenuti. Poichè tale server risulta già raggiungibile via SSH, si vuole utilizzare il protocollo SFTP per il trasferimento dei file, sostanzialmente per due ragioni:

1) Esporre su Internet il minor numero di porte. Infatti, il protocollo SFTP sfrutta la stessa porta TCP del protocollo SSH (ovvero la 22);

2) SFTP è molto più robusto del File Transfer Protocol (FTP), in quanto garantisce alcuni meccanismi di sicurezza quali confidenzialità e soprattutto autenticazione della fonte.

 

sftp,ssh,user,group,chmod

Inoltre, la directory target di ogni sviluppatore è la medesima ed i file caricati da uno devono essere accessibili in lettura/scrittura da tutti gli altri (tenendo sempre traccia di chi-ha-fatto-cosa, ecco spiegato il perchè della necessità di un server SFTP multiutenza).

Preparazione della macchina

La prima cosa da fare è, ovviamente, creare le utenze per ciascun sviluppatore. E’ possibile fare ciò semplicemente utilizzando il comando useradd:

[root@serverWeb ~]# useradd devel1
[root@serverWeb ~]# useradd devel2
[root@serverWeb ~]# useradd devel3

A questo punto, è necessario settare la password di default per ciascuna utenza. Essa potrà essere modificata in un secondo momento dallo sviluppatore stesso:

[root@serverWeb ~]# echo 'devel1:passworddevel1'|chpasswd
[root@serverWeb ~]# echo 'devel2:passworddevel2'|chpasswd
[root@serverWeb ~]# echo 'devel3:passworddevel3'|chpasswd

Notate che ho utilizzato tale sintassi anzichè il classico comando interattivo:

[root@serverWeb ~]# passwd <nomeutente>

in quanto risulta più comoda nel caso in cui si dovessero creare molte utenze.

A questo punto creiamo il gruppo di che identificherà gli sviluppatori

[root@serverWeb ~]# groupadd web

e facciamo in modo che essi ne facciano parte (modificando il loro gruppo di default che è semplicemente uguale al nome utente scelto):

[root@serverWeb ~]# usermod -g web devel1
[root@serverWeb ~]# usermod -g web devel2
[root@serverWeb ~]# usermod -g web devel3

Infine, modifichiamo la home directory degli utenti appena creati, mediante il comando usermod (consentendo loro di atterrare direttamente sulla dir in cui dovranno essere caricati i contenuti Web):

[root@serverWeb ~]# usermod -d /var/www/html devel1
[root@serverWeb ~]# usermod -d /var/www/html devel2
[root@serverWeb ~]# usermod -d /var/www/html devel3

Posizioniamoci adesso nella dir /var/www/ e lanciamo i seguenti comandi:

[root@serverWeb ~]# chown root:web -R html
[root@serverWeb ~]# chmod 775 -R html
[root@serverWeb ~]# chmod g+s -R html

Con il primo comando abbiamo semplicemente modificato il gruppo proprietario della directory html; con il secondo comando abbiamo fatto in modo che tutti i file (e le subdirectory) garantiscano tutte le operazioni (read, write, execute) all’owner (root) ed al gruppo proprietario (web).

Infine, con il terzo comando, stiamo facendo in modo che qualunque nuovo file o directory che verrà creato all’interno di html abbia come proprietario il gruppo Web.

Configurazione di sshd

Questa è sicuramente “la parte facile” della guida, in quanto è sufficiente inserire una piccola flag all’interno del file di configurazione del demone SSH, ovvero /etc/ssh/sshd_config. In particolare, la entry:

Subsystem       sftp    /usr/libexec/openssh/sftp-server

dovrà diventare:

Subsystem       sftp    /usr/libexec/openssh/sftp-server -u 002

dove -u significa umask e rappresenta i permessi di default dei nuovi file e directory che verranno caricati mediante SFTP.

Riavviamo sshd:

[root@serverWeb ~]# service sshd restart

ed abbiamo finito.

Ora gli sviluppatori ci ringrazieranno.

Alla prossima.

Script bash per i port scan su range di IP

Problema

Mancato aggiornamento dell’associazione IP/FQDN (record A DNS) mediante ddclient, che si traduce nell’impossibilità di conoscere il vero indirizzo IP pubblico del server (essendo dinamico).

Possibile soluzione

Conoscendo l’ISP e partendo dal fatto che almeno una porta non standard ( > 1023) è pubblicata all’esterno (ad esempio la TCP 4338) si può procedere con la scansione automatizzata dei netblock appartenenti al nostro Internet Service Provider. Nella fattispecie, l’ISP è Telecom Italia ed alcuni dei netblock ad esso associati sono i seguenti:

79.46.0.0/15
79.56.0.0/16
62.77.32.0/19
62.211.0.0/16
77.238.3.3/19
79.140.80.0/20
80.104.0.0/15
80.116.0.0/15
80.180.0.0/15
80.204.0.0/15
80.241.224.0/20
81.72.0.0/22
81.112.0.0/20
82.48.0.0/20
82.88.0.0/22
82.104.0.0/22
83.175.0.0/18
83.221.96.0/18
89.221.32.0/18
93.186.128.0/20
95.74.0.0/15
95.224.0.0/11
188.8.0.0/13
195.14.96.0/19
195.22.192.0/19
212.171.0.0/16
212.216.0.0/16
213.45.0.0/16
213.144.160.0/19
213.230.128.0/19
217.27.64.0/19
217.169.96.0/20
217.169.112.0/20
217.172.192.0/19
217.200.0.0/14
217.222.0.0/15

E’ possibile inserire la suddetta lista all’interno di un apposito file testuale, chiamandolo semplicemente netblock. Inoltre, i netblock sono oggetto di continui aggiornamenti, ergo prima di procedere sinceratevi che appartengano ancora all’ISP di riferimento (attraverso un semplice whois <netblock>).

Una volta fatto ciò, mediante l’uso di nmap, possiamo realizzare uno script bash che si occupi di scansionare i suddetti range di IP pubblici. Lo script è il seguente:

nightfly@nightbox:~$ cat autoscanner.sh
#!/bin/bash

sourcefile=/home/nightfly/netblock

resfile=/home/nightfly/results

targetfile=/home/nightfly/openports

while read line
do

        nmap -P0 $line -p 4338 >> $resfile

done < $sourcefile

cat $resfile | grep -B2 open >> $targetfile

exit 0;

La logica dello script è questa:

1) viene lanciato uno scan verso ogni singolo range specificato nel file netblock, prendendo in considerazione esclusivamente la porta di destinazione TCP 4338;

2) una volta terminata la scansione vengono cercate tutte le occorrenze del termine open, considerando anche le due righe precedenti ad esso, in modo da ottenere l’IP pubblico degli host su cui la porta in questione risulta in ascolto;

3) a questo punto, supponendo che dietro la porta TCP 4338 vi sia in ascolto un demone SSH, è possibile lanciare delle sessioni Secure SHell verso ciascun IP specificato nel file /home/nightfly/openports. Se a tali tentativi di connessione seguirà una richiesta di login, è molto probabile che il nostro server sia stato effettivamente identificato. Ovviamente, se il login non andrà a buon fine, la macchina che stiamo cercando è un’altra.

Buona scansione.

PS: il port scan, di per se, non è reato, ma potrebbe diventarlo se lo associerete a più tentativi di login non autorizzati. Inoltre, essendo i netblock in questione piuttosto ampi, la scansione richiederà molto tempo.

Rkhunter e le email di allarme

Rkhunter è un valido tool per identificare eventuali rootkit presenti sulla nostra macchina. In particolare, esso effettua una scansione ogni giorno, alla ricerca dei suddetti malware e se nota qualcosa di “anomalo” procede con l’invio di un’opportuna email di notifica.

rkhunter, warning, ssh, root access, email, fake alarms

Detto ciò, qualche giorno fa ho ricevuto la seguente email (proveniente da ben 4 macchine che gestisco, tutte sotto il medesimo dominio):

Oggetto: [rkhunter] Warnings found for hostname

Messaggio: Please inspect this machine, because it may be infected.

A differenza degli altri “falsi allarmi”, questa volta non ho fatto nessun balzo dalla sedia, ma ho deciso di identificare la causa delle suddette email.

Per prima cosa ho deciso di spulciare il file di log dell’applicativo in questione, ovvero /var/log/rkhunter/rkhunter.log, facendo un grep sulla keyword Warning.

Ecco l’output (parziale) del suddetto comando:

[04:02:45]   Checking if SSH root access is allowed          [ Warning ]
[04:02:45] Warning: The SSH and rkhunter configuration options should be the same:

Ok, problema identificato: se disabilito l’accesso root via SSH, devo specificare tale modifica anche all’interno del file di configurazione di rkhunter:

[root@hostname ~]$ nano /etc/rkhunter.conf

sostituendo

ALLOW_SSH_ROOT_USER=unset

con

ALLOW_SSH_ROOT_USER=no

Fine dei falsi allarmi.

Alla prossima.

Idle timeout sulle sessioni SSH con i router di Alice Telecom

Il mio lavoro consiste principalmente nella gestione di server *nix. Potrebbe accadere che, mentre sono a casa, debba connettermi ad uno dei suddetti server perchè qualcosa non funziona (o funziona male).

Quindi, oltre a sbattermi per cercare di risolvere il problema, devo anche imprecare contro il router Pirelli di Alice Telecom, che come tutti ben sanno ha il firmware bloccato e droppa le sessioni SSH (ma credo anche altri tipi di connessione) dopo un certo idle.

alice-router.jpg

Esistono comunque diversi workaround, tra i quali:

1) rimuovere il firmware di casa Telecom ed abilitare quello nativo di casa Pirelli (su Internet esiste una documentazione ben dettagliata che descrive questa procedura);

oppure:

2) cambiare le impostazioni del demone sshd, imponendo l’invio di keepalive ai client che si connettono.

La seconda opzione, ovviamente, è praticabile solo dagli utenti che hanno accesso alle impostazioni del suddetto demone.

Per abilitare i keepalive occorre semplicemente aggiungere le seguenti direttive al file di configurazione sshd_config che trovate nella dir /etc/ssh:

ClientAliveInterval 45
ClientAliveCountMax 1000

Riavviate il suddetto demone con un:

[root@bqweb1 ssh]# service sshd restart

E finalmente avete “risolto” il problema degli idle timeout su SSH.

Alla prossima.

File Transfer Protocol in tutte le salse

Chiunque abbia un background sistemistico avrà sentito parlare del File Transfer Protocol (FTP). Esso si basa sul protocollo TCP (lato trasporto) e dunque implica dei collegamenti di tipo affidabile. Inoltre, sfrutta le porte 20 e 21 (dette rispettivamente Data e Command), la prima per il trasferimento dei dati e la seconda per l’invio dei comandi.

Ma andiamo con ordine. Il suddetto protocollo può funzionare in 2 modalità:

1) attiva;

2) passiva.

Nel primo caso il client contatta il server sulla porta 21, inviandogli il comando PORT, in cui specifica appunto la porta ( >1023) su cui il server potrà provare a connettersi. A questo punto, dato che il server conosce la suddetta porta, lancerà un tentativo di connessione proveniente dalla porta 20 e diretta a quella precedentemente specificata dal client.

activeftp.gif

Nel secondo caso, invece, il client invia al server (sempre mediante la porta 21), il comando PASV (tentativo di connessione in modalità passiva) a cui il server risponde con il comando PORT (specificando una porta >1023). A questo punto sarà il client a tentare di instaurare la connessione dati verso la porta specificata dal server (a differenza di quanto avveniva nella modalità attiva).

passiveftp.gif

Ma quando utilizzare una o l’altra modalità? Semplice. Potrebbe accadere che il client si trovi dietro un firewall e che quindi i tentativi di connessione provenienti dal server vengano droppati. In questo caso è necessario utilizzare la modalità passiva, poichè in questo modo sarà sempre il client ad effettuare i tentativi di connessione, aggirando le restrizioni imposte dal suddetto firewall (essi, salvo eccezioni, solitamente non filtrano i tentativi di connessione in uscita da porte “alte”).

Avrete notato che la denominazione delle modalità avviene prendendo come punto di riferimento il server: se il traffico dati avviene mediante connessione instaurata dal server verso il client parliamo di modalità attiva; viceversa, se è il client ad effettuare la connessione dati verso il server parliamo di modalità passiva.

Ora, poichè il protocollo FTP è piuttosto datato, esso risulta abbastanza vulnerabile, soprattutto nei confronti operazioni di sniffing del traffico (poichè il trasferimento dati e l’invio di comandi viaggiano in chiaro).

Poprio per questo motivo negli anni si è cercato di correre ai ripari, creando dei meccanismi di cifratura che potessero garantire:

1) autenticazione della fonte;

2) confidenzialità.

Il primo tentativo di questo tipo prese il nome di SFTP (che sta per SSH File Transfer Protocol), ovvero un protocollo basato su SSH versione 2 (anche se esistono delle varianti basate su SSHv1, ma non tutti i client sono compatibili). Esso, più che un protocollo di trasferimento file, rappresenta una sorta di “file system remoto”, consentendo dunque di effettuare operazioni quali la creazione di nuove directory, la cancellazione dei file, ecc. Una restrizione del suddetto protocollo è rappresentata da SCP (Secure Copy), che consente solo il trasferimento dei file.

Entrambi i protocolli menzionati in precedenza, però, presentano una limitazione: necessitano di shell account per funzionare.

Proprio per evitare ciò è stato creato FTPS (FTP over SSL), che sfrutta i meccanismi di cifratura messi a disposizione dai protocolli SSL/TLS.

Esso può essere di due tipologie:

1) implicito;

2) esplicito.

Nel primo caso il server è in ascolto su una porta diversa dalla 21 (solitamente la 990) e tale tipologia è stata creata soprattutto per questioni di retrocompatibilità.

Nel secondo caso, invece, il server è in ascolto sulla classica porta 21 (FTP Command), ed accetta il comando esplicito AUTH <meccanismo di cifratura>, ad esempio AUTH TLS.

Dopo questa piccola premessa, prossimamente vedremo come abilitare FTPS su vsftpd.

A presto.

Nagios: monitoraggio degli host senza ricorrere ai ping

Come misura (molto blanda) di protezione per i server che gestisco (esposti su Internet), ho deciso di inibire le risposte ai ping (in gergo tecnico ICMP echo reply).

 

nag.jpg

Però, poichè ho la necessità di monitorare l’effettiva raggiungibilità di tali host, ho pensato di implementare un ckeck basato esclusivamente sul protocollo SSH. In particolare, ho effettuato le seguenti operazioni:

1) ho creato un gruppo nagios specifico, che ho chiamato noping-host. Per fare ciò mi sono posizionato nella directory /etc/nagios3/conf.d ed ho lanciato il comando:

nightfly@nightbox:/etc/nagios3/conf.d$ sudo nano noping-host_nagios2.cfg

il contenuto del suddetto file è il seguente:

define host{
        name                            noping-host    ; The name of this host template
        notifications_enabled           1       ; Host notifications are enabled
        event_handler_enabled           1       ; Host event handler is enabled
        flap_detection_enabled          1       ; Flap detection is enabled
        failure_prediction_enabled      1       ; Failure prediction is enabled
        process_perf_data               1       ; Process performance data
        retain_status_information       1       ; Retain status information across program restarts
        retain_nonstatus_information    1       ; Retain non-status information across program restarts
                check_command                   check_ssh_port!2293
                max_check_attempts              10
                notification_interval           0
                notification_period             24x7
                notification_options            d,u,r
                contact_groups                  admins
        register                        0       ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE!
        }

Come potete notare, alla direttiva check_command è associato il comando da lanciare per verificare la raggiungibilità dell’host, ovvero check_ssh_port!2293, dove 2293 è la porta su cui è in ascolto SSH.

2) ho creato il file relativo all’host da monitorare, lanciando il comando:

nightfly@nightbox:/etc/nagios3/conf.d$ sudo nano host-remoteserver_nagios3.cfg

il cui contenuto è il seguente:

define host {
        host_name   remoteserver
        alias       remoteserver
        address     remoteserver.homeip.net
        use         noping-host
        }

dove remoteserver.homeip.net è l’hostname pubblico della macchina che vogliamo monitorare.

Infine riavviamo nagios:

nightfly@nightbox:/etc/nagios3/conf.d$ sudo service nagios3 restart

ed abbiamo finito.

Alla prossima.

Aggirare il proxy mediante un tunnel SSH

Premesso che sia possibile fare questo, vediamo qual è la tecnica per bypassare il proxy aziendale (e le relative restrizioni).

Per prima cosa occorre configurare PuTTy affinchè riesca ad aprire un socket su localhost, possibilmente su una porta alta (fuori dal range delle well known, ovvero 1-1023), poichè è proprio da una di queste porte che solitamente partono le richieste HTTP/HTTPS dei client verso i server Web.

Per fare ciò occorre posizionarsi su SSH -> Tunnels, impostare come source port ad esempio la 4021 e quindi selezionare Dynamic ed Auto. Infine, è necessario cliccare su Add.

Ecco uno screenshot abbastanza esplicativo:

 

tunnel.jpg

Per verificare che la porta sia effettivamente in bind occorre lanciare il seguente comando da prompt:

netstat -ano | find "4021"

Ok, ora non ci resta che configurare Firefox affinchè sfrutti il tunnel SSH per navigare.

Per fare ciò occorre posizionarsi si Strumenti -> Opzioni -> Avanzate -> Rete -> Impostazioni e settare come socks4 localhost avente come porta di ascolto la 4021.

 

socks4.jpg

Ora, poichè solitamente i nameserver locali consentono la risoluzione diretta solo dei nomi di dominio, è necessario fare in modo che Firefox utilizzi la macchina remota (ovvero il server SSH) come nameserver.

Per fare questo si deve accedere alle configurazioni avanzate del suddetto browser, digitando sulla barra degli indirizzi about:config.

Il parametro che ci interessa è network.proxy.socks_remote_dns, da settare su true.

A questo punto aprite la connessione SSH verso il server remoto ed enjoy!

Alla prossima.

Sessioni SSH mediante proxy HTTP

Ultimamente mi è capitato di dover accedere via SSH su un server remoto. Peccato però che il firewall non consentisse traffico TCP sulla porta 22 in uscita. Proprio per questo motivo ho spulciato la configurazione di PuTTY ed ho individuato un’interessantissima funzionalità, ovvero Connection -> Proxy.

Una volta impostati i diversi parametri quali tipologia di proxy (HTTP), porta del proxy (8080) e credenziali (Username e Password), sono riuscito ad ottenere accesso alla shell, “aggirando” il firewall.

Ecco uno screenshot esplicativo:

ssh_proxy.jpg

Ma perchè è stato possibile fare ciò? Semplicemente perchè il proxy non riesce a distinguere (se non opportunamente configurato) il traffico HTTPS da quello SSH.

Occorre precisare, però, che tale trucchetto non funziona con Squid. Infatti, per default, il proxy in questione forwarda solo il traffico destinato e proveniente da determinate porte (tale operazione è possibile mediante la definizione di opportune ACL). Ad esempio:

 acl SSL_ports port 443          # https
 acl SSL_ports port 563          # snews
 acl SSL_ports port 873          # rsync
 acl Safe_ports port 80          # http
 acl Safe_ports port 21          # ftp
 acl Safe_ports port 443         # https
 acl Safe_ports port 70          # gopher
 acl Safe_ports port 210         # wais
 acl Safe_ports port 1025-65535  # unregistered ports
 acl Safe_ports port 280         # http-mgmt
 acl Safe_ports port 488         # gss-http
 acl Safe_ports port 591         # filemaker
 acl Safe_ports port 777         # multiling http
 acl Safe_ports port 631         # cups
 acl Safe_ports port 873         # rsync
 acl Safe_ports port 901         # SWAT

Come potete notare, la porta 22 non è listata tra le safe ports.

Ergo se utilizzate Squid come proxy potete stare certi che per default è impossibile utilizzarlo come proxy per le sessioni SSH.

A presto.