La procedura che descrivo di seguito va utilizzata solo a scopo di debug con una propria applicazione che non sta funzionando come dovrebbe , al fine di capire meglio cosa accade.

Per intercettare, o sniffare, il traffico di un dispositivo nella propria disponibilità, la cosa più semplice è impostare un proxy nella configurazione del dispositivo.

Dato che stiamo facendo debug è necessario che il server proxy ed il client siano nella stessa rete (fermo restando che il server proxy potrebbe anche essere attivo su una rete differente ma comunque raggiungibile dal client).

Per questa procedura voglio parlarvi di mitmproxy, un proxy HTTPS interattivo open-source, disponibili per diverse piattaforme.

Vediamo quindi come installare/configurare mitmproxy su un Mac e configurare un dispositivo iOS come client; entrambe i dispositivi si trovano nella stessa rete wi-fi.

Server proxy

Installare mitmproxy:

brew install mitmproxy

Avviare mitmproxy:

/opt/homebrew/bin/mitmproxy

oppure, per avere un’interfaccia web più pratica da utilizzare:

/opt/homebrew/bin/mitmweb

Questo comando avvia il proxy sulla porta 8080 del Mac. Ora bisogna recuperare anche l’IP del Mac (tra le impostazioni di rete) in modo da avere i parametri da impostare nel client successivamente. In alternativa da CLI si può digitare:

ipconfig getifaddr en0

dove en0 è la prima interfaccia di rete ed è solitamente quella utilizzata.

Contestualmente viene aperta una pagina del browser dove verranno riepilogate le varie chiamate.

Client iOS

Modificare le impostazioni wifi/ ed inserire il riferimento al proxy:
apri Impostazioni -> Wi-Fi -> cliccare sull’icona (i) a destra del nome della rete wi-fi -> in basso scegliere “Configura Proxy“, abilitare “Manuale” ed inserire ip/porta recuperati prima dal server proxy

Aprire l’indirizzo mitm.it nel browser Safari del client iOS e scaricare il certificato relativo ad iOS

Aprire Impostazioni -> Generali -> VPN e gestione dispositivo ed installa il certificato chiamato “mitmproxy“

Aprire Impostazioni -> Generali -> Info -> Attendibilità certificati ed abilita il certificato chiamato mitmproxy

Client MacOS

E’ possibile impostare in modo similare anche la connessione del Mac tramite proxy. Aprire Impostazioni -> Wifi (oppure Rete se connessi con cavo) -> pulsante Dettagli vicino la connessione attiva -> Proxy -> abilitare Proxy web (HTTP) e Proxy web sicuro (HTTPS) -> infine indicare come Server 127.0.0.1 e come Porta 8080.

Verifica finale

Bene, a questo punto bisogna provare adaprire una pagina qualsiasi in Safari, es “www.google.com” e verificare che il browser non mostri errori. Se il sito richiamato si vede, contestualmente si può controllare su mitmproxy verificare che stia inizando a loggare le richieste.

La documentazione è presente all’indirizzo https://docs.mitmproxy.org/stable/ dove sono disponibile anche diversi video esemplificativi.

In alternativa posso consigliare proxyman da installare con:

brew install --cask proxyman

enjoy!

[Service]
Environment="HTTP_PROXY=http://SERVER_PROXY:3128"
Environment="HTTPS_PROXY=http://SERVER_PROXY:3128"

rileggiamo le modifiche effettuate:

systemctl daemon-reload

ed infine ricarichiamo il servizio:

systemctl restart docker

Per verificare che l’impostazione sia stata presa in considerazione:

systemctl show --property=Environment docker

ATTENZIONE: Nel caso si utilizzi docker compose e si modifichino le impostazioni nella sezione environment, ad esempio:

environment:
  HTTP_PROXY: "http://SERVER_PROXY:3128/"
  HTTPS_PROXY: "http://SERVER_PROXY:3128/"
  NO_PROXY: "localhost,127.0.0.1"

bisogna ricordarsi di rileggere le impostazioni:

docker-compose stop && docker-compose up -d --no-deps --build

enjoy!

In questo caso possiamo limitare i danni (nel senso di bloccare le richieste per taluni IP), creando una regola nel file .htaccess posizionato nella nostra webroot che vada a bloccare le richieste se l’IP viene identificato da qualche regola di fail2ban.

Ipotizziamo che la webroot sia /var/www/web1/htdocs e che vogliamo usare la cartella blockedip per contenere i riferimenti per gli IP bloccati.

Scriviamo all’inizio del nel nostro file .htaccess le seguenti direttive (le prime due righe non servono ma le lascio perché a qualcuno possono essere utili per farci altro):

RewriteCond %{DOCUMENT_ROOT}/blockedip/%{REMOTE_ADDR} -f
RewriteRule . - F]
RewriteCond %{DOCUMENT_ROOT}/blockedip/%{HTTP:X-FORWARDED-FOR} -f
RewriteRule . - F]

Dopo aver fatto la classica configurazione di fail2ban in coppia con nftables, bisognerà aprire il file /etc/fail2ban/action.d/nftables.conf e scrivere, sotto la direttiva actionban, la riga:

touch /var/www/web1/htdocs/blockedip/<ip>

e sotto la direttiva actionunban, la riga:

rm /var/www/web1/htdocs/blockedip/<ip>

Bene, ora riavviamo fail2ban e non appena ci saranno IP bloccati, li troverete riepilogati nella cartella /var/www/web1/htdocs e la regola di rewrite nel file .htaccess provvederà a bloccare le richieste per tali IP.

enjoy!

export http_proxy="http://user:pass@10.10.10.10:3180/"
export https_proxy="http://user:pass@10.10.10.10:3180/"
export no_proxy="www.google.it"

Questo file viene “letto” dal sistema al login, quindi gli utenti ssh avranno sicuramente impostato queste informazioni per la navigazione.

Sul sistema Debian GNU/Linux, CRON supporta il modulo pam_env e carica l’ambiente specificato da /etc/environment e /etc/security/pam_env.conf. Legge anche le informazioni sulla localizzazione da /etc/default/locale.

Pertanto, se è necessario far “navigare” uno script richiamato da CRON, i parametri vanno inseriti anche nel file /etc/environment Per evitare di dove gestire eventuali modifiche su più file, consiglio di aggiungere in coda al file di profile la seguente riga dopo la definizione delle variabili relative al proxy:

if [ "id -u" -eq 0 ]; then
  printenv |grep -i proxy>/etc/environment
fi

Per le macchine più vecchie, questa procedura è particolarmente utile quando la variabile no_proxy viene impostata con una classe IP, perché dato che non è possibile usare la classica notazione 10.10.10.10/24 ma nel file di profile possiamo usare comandi bash, in quest’ultimo potremmo scrivere qualcosa tipo:

export no_proxy="echo 10.10.10.{1..255}, echo 10.12.12.{1..255}, www.google.com"

ed automaticamente troveremmo tutti gli IP, delle classi indicate, riportati per esteso nel file environment.

enjoy!

La configurazione è semplice (rif precedenti post), oggi volevo parlarvi di come abilitare il supporto per repository HTTPS. Ci sono diverse modalità per farlo, la cosa più semplice, che però non fa caching dei pacchetti scaricati, è inserire nel file /etc/apt-cacher-ng/acng.conf la direttiva:

PassThroughPattern: .*

e poi riavviare il servizio:

service apt-cacher-ng restart

Lato client invece non va fatto nulla, oltre la classica configurazione iniziale, es la riga:

Acquire::http::Proxy "http://10.0.0.16:3142";

nel caso 10.0.0.16 sia l’IP del server con apt-cacher-ng.

enjoy!

Attivando semplicemente nginx come proxy, si vedrà che apache inizierà a loggare come IP visitatore sempre quello del proxy e non più quello del visitatore vero e proprio.

Ipotizziamo di avere sia nginx che apache sullo stesso nodo, praticamente nei logs di apache si vedrà sempre 127.0.0.1 come IP del visitatore.

Per ovviare a questo, bastano due configurazioni.

Su nginx:

Modificare il file di configurazione del VirtualHost ed inserire nella sezione location:

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

Su apache <2.4:

Installare il modulo rpaf:

apt-get install libapache2-mod-rpaf

Poi modificare il file /etc/apache2/mods-enabled/rpaf.conf e modificare/inserire le direttive:

RPAFproxy_ips 127.0.0.1 ::1 
RPAFheader X-Forwarded-For

Su apache >= 2.4:

Creare il file /etc/apache2/mods-available/remoteip.conf con all’interno:

RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 127.0.0.1

attiva il modulo remoteip:

a2enmod remoteip

Modificare le righe LogFormat nel file /etc/apache2/apache2.conf sostituendo %h con %a, es:

LogFormat "%v:%p %a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%a %l %u %t \"%r\" %>s %O" common

Ora riavviare apache ed nginx e nei files di logs ci saranno i corretti IP.

enjoy!

Installiamo nginx:

apt-get install nginx

Ora spostiamoci nella cartella /etc/nginx/sites-enabled e modifichiamo il file default per gestire la parte proxy, ad esempio per http://pippo.smsoft.it verso il server “interno” 10.10.10.10 ed http://pluto.smsoft.it verso il server “interno” 10.10.10.12 porta 8080. Crediamo queste due sezioni nel file default:

server {
     listen 80;
     server_name pippo.smsoft.it;
     location / {
         proxy_pass http://10.10.10.10:80;
     }
 }
server {
       listen 80;
       server_name pluto.smsoft.it;
       location / {
           proxy_pass http://10.10.10.12:8080;
       }
   }

Inoltre, facciamo in modo che le richieste verso http://topolino.smsoft.it e http://www.topolino.smsoft.it vadano verso https://topolino.smsoft.it:

server {
     listen 80;
     server_name topolino.smsoft.it www.topolino.smsoft.it;
     return 301 https://topolino.smsoft.it$request_uri;
}

Ricarichiamo la configurazione di nginx:

service nginx reload

enjoy!

docker: Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp 34.199.40.84:443: connect: connection refused.

è necessario impostare l’uso del proxy in docker.

Crediamo una cartella in cui salvare le configurazioni:

mkdir -p /etc/systemd/system/docker.service.d

Crediamo un file chiamato /etc/systemd/system/docker.service.d/http-proxy.conf ed inseriamo:

[Service]
Environment="HTTPS_PROXY=https://proxy.example.com:443/"
Environment="HTTPS_PROXY=https://proxy.example.com:443/"
Environment="NO_PROXY=hostname.example.com,172.10.10.10"

Chiaramente le variabili vanno personalizzate in base alle proprie esigenze.

Bene, ora ricarichiamo le modifiche:

systemctl daemon-reload

e riavviamo docker:

systemctl restart docker

Per verificare che il parametro sia stato correttamente impostato, possiamo digitare:

systemctl show --property=Environment docker

e verrà mostrata la riga relativa all’Environment.

enjoy!

Invalid response from proxy: HTTP/1.0 403 CONNECT denied (ask the admin to allow HTTPS tunnels)

La seguente configurazione permette anche di fare caching dei pacchetti scaricati, in modo diverso da quello che accade seguendo questo altro sistema.

Prendiamo ad esempio il repository di jitsi (https://download.jitsi.org) e diamo per scontato che APT nel client sia già configurato per usare il nostro server ap-cacher-ng con l’apposita direttiva nel file /etc/apt/apt.conf, es:

Acquire::http::Proxy "http://XX.XX.XX.XX:3142";

dove XX.XX.XX.XX è l’IP del nostro server apt-cacher-ng

CLIENT:
Nel file /etc/apt/sources.list.d/jitsi-stable.list inseriamo:

deb http://jitsi.cache stable/

e nel file /etc/hosts:

XX.XX.XX.XX    jitsi.cache

dove XX.XX.XX.XX è l’IP del nostro server apt-cacher-ng

SERVER:
Creiamo il file /etc/apt-cacher-ng/backends_jitsi_org e inseriamo:

https://download.jitsi.org

poi modifichiamo il file /etc/apt-cacher-ng/acng.conf ed aggiungiamo:

Remap-jitsiorg http://jitsi.cache ; file:backends_jitsi_org

Bene, ora riavviamo apt-cacher-ng e riproviamo la connessione al repository dal client.

enjoy!

Aprire infine il file di configurazione /etc/apache2/mods-enabled/rpaf.conf ed aggiungere l’IP del server proxy nella riga RPAFproxy_ips, es:
RPAFproxy_ips 127.0.0.1 ::1 10.109.70.60

e decommentare la direttiva:
RPAFheader X-Real-IP

Bene, riavviamo apache e ci siamo:
service apache2 restart

enjoy!