Il blog sull'informatica

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

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.

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:

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.

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.

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.