Il blog sull'informatica

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:

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.

Il protocollo SSL (Secure Socket Layer) prevede l'uso di alcuni algoritmi di cifratura nell'ambito dell'handshake. Uno di questi è il Diffie-Helman, che può essere adoperato in 3 varianti:

1) Anonymous Diffie-Helman (A_DH): il numero primo p e la radice primitiva a ad esso associata vengono inviati senza autentica. In realtà questa è la modalità di funzionamento "standard" del Diffie-Helman;

2) Fixed Diffie-Helman (F_DH): p ed a del server https vengono firmati mediante un certificato X.509 trusted. La chiave segreta è statica, ovvero è la medesima per ogni sessione.

3) Ephemeral Diffie-Helman (E_DH): viene generata una secret key (relativa al protocollo DH) temporanea (one-time o ephimeral), ovvero valida per una sola sessone, firmata mediante la propria chiave segreta RSA (o DSS). La controparte ne verificherà l'autenticità attraverso la chiave pubblica del mittente. Anche in questo caso si possono utilizzare dei certificati X.509 contenenti i paramentri a e p per semplificare le operazioni di autentica dei due peer.

Fine del post, alla prossima.

Da un po' di tempo a questa parte ho deciso di rendere raggiungibili i miei server Web solo mediante il protocollo HTTPS. Una volta fatto ciò, ho riscontrato (con mio enorme dispiacere) che l'interfaccia Web di ntop (in ascolto sulla porta 3000 TCP) non era più utilizzabile.

Proprio per questo motivo (e per non cambiare la regola di forwarding sul mio router e sui miei 2 firewall), ho deciso di effettuare qualche modifica al demone in questione.

In particolare, ho fatto in modo che ntop rimanesse in ascolto sulla porta 3000, accettando però connessioni HTTPS.

Ecco la modifica nello specifico:

start-stop-daemon --start --quiet --name $NAME --exec $DAEMON --
  -d -L -u $USER -w 0 -W 3000 -P $HOMEDIR

ovvero ho disabilitato l'ascolto su HTTP (-w 0) ed abilitato l'ascolto su HTTPS (-W 3000).

Il file da modificare è /etc/init.d/ntop.

A modifiche completate si può procedere con un riavvio del demone, digitando:

nightfly@nightbox:/etc/init.d$ sudo service ntop restart

ed abbiamo finito.

Enjoy.