Ssh Tunnel

04net1-ccli-net2-cssh-chhtp

Due reti, server HTTP su seconda rete.

Solo server SSH visibile da prima rete.

Scaffolding

Directory di progetto:

mkdir -p ~/ex/04net1-ccli-net2-cssh-chhtp
cd ~/ex/04net1-ccli-net2-cssh-chhtp

Copiare il progetto precedente:

cp -Rv ../03net1-ccli-net2-cssh/* .

Creare gli elementi nuovi:

mkdir chttp
touch chttp/entrypoint.sh
touch chttp/Dockerfile

L’albero risultante è:

.
├── ccli
│   ├── Dockerfile
│   └── entrypoint.sh
├── cfw
│   └── Dockerfile
├── chttp
│   ├── Dockerfile
│   └── entrypoint.sh
├── cssh
│   ├── Dockerfile
│   └── entrypoint.sh
└── docker-compose.yml

Files

chttp/entrypoint.sh

vim chttp/entrypoint.sh

#! /bin/sh
  
echo "Waiting 2 seconds for router"
sleep 2
ip route add 192.168.101.0/24 via 192.168.102.10 || true

exec "$@"

chttp/Dockerfile

vim chttp/Dockerfile

FROM httpd:2.4-alpine
LABEL Maintainer "John Smith <john@stormforce.ac>"

COPY entrypoint.sh /
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

CMD ["httpd-foreground"]

docker-compose.yml

vim docker-compose.yml

......
  four:
    build: chttp
    image: chttp
    container_name: four
    hostname: four
    depends_on:
      - three
    cap_add:
      - ALL
    networks:
      net2:
        ipv4_address: 192.168.102.14
.......

NOTA

L'esercizio è disponibile in formato Tar a 04net1-ccli-net2-cssh-chhtp-senza-fw.tar

Generare il Gnome terminal four.

Prova intermedia

Compiere una pulizia delle vecchie immagini:

docker rmi ccli:latest cssh:latest cfw:latest

Partenza del progetto:

docker compose up -d

Aprire il terminale one.

Provare il collegamento al server HTTP:

curl -v http://192.168.102.14

Dovrebbe collegarsi.

Provare il collegamento al server SSH:

ssh pippo@192.168.102.12

Dovrebbe funzionare.

Terminiamo il progetto:

docker compose down

Firewall

Decidiamo, per sicurezza, che dall’esterno della rete 192.168.102.0/24 si possa raggiungere solo il server SSH, non quindi il server HTTP.

Occorre usare iptables su cfw e introdurre regole:

• tutti i collegamenti sono di default proibiti
• i collegamenti in corso possono continuare
• è consentito un nuovo collegamento alla porta SSH di cssh

Anche questo è realizzato con un entrypoint.sh, ricostruendo l’immagine cfw.

cfw/entrypoint.sh

vim cfw/entrypoint.sh

#! /bin/sh

# tutti i collegamenti sono di default proibiti  
iptables -P FORWARD DROP
# i collegamenti in corso possono continuare
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# è consentito un nuovo collegamento alla porta SSH
iptables -A FORWARD -d 192.168.102.0/24 -p tcp --dport 22 -m state --state NEW -j ACCEPT

# ritorna successo anche se vi sono stati degli errori
true

exec "$@"

cfw/Dockerfile

vim cfw/Dockerfile

FROM alpine:3.7
MAINTAINER John Smith <john@stormforce.ac>

RUN apk --update add --no-cache openssh tcpdump curl iptables

COPY entrypoint.sh /
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
CMD ["/bin/sleep","1000000"]

Prova Finale

Rimuovere la vecchia immagine di cfw:

docker rmi cfw:latest

Lanciare il progetto:

docker compose up -d

Aprire il terminale one.

Provare il collegamento al server HTTP:

curl -v http://192.168.102.14

Non dovrebbe collegarsi.

Provare il collegamento al server SSH:

ssh pippo@192.168.102.12

Dovrebbe sempre funzionare.

Esercizio 4A

Due reti, server HTTP su seconda rete.

Tunnel da client HTTP a server HTTP via server SSH.

Chiunque si collega ad un server SSH può aprire un tunnel ad un altro server.

Da one:

ssh -L 1111:192.168.102.14:80 pippo@192.168.102.12

Questo crea un tunnel dalla porta locale 1111 alla porta 80 della macchina 192.168.102.14.

In un altro tab di terminale dare il comando:

curl -v http://localhost:1111

Si collega al server HTTP remoto.

Questo è un baco di sicurezza.

Tappare il Baco

Nella terminologia di sicurezza si distingue tra Vulnerabilità ed Esposizioni:

• Vulnerabilità: debolezza intrinseca del software
• Esposizione: cattiva configurazione (o comportamento improprio)

Questa è una Espozizione.

Nel file di configurazione /etc/ssh/sshd_config trovare e modificare il parametro:

AllowTcpForwarding no

Naturalmente in un Dockerfile questo viene fatto con giudiziosa applicazione del comando sed.