Introduzione

Questo corso si occupa di descrivere, con un dettaglio superiore a quello elementare ma inferiore a quello approfondito, la struttura, l'architettura e l'uso dei protocolli di Networking.

Viene dedicata particolare attenzione ai cosiddetti Protocolli TCP/IP, che sono alla base di Internet.

Il corso ha una componente teorica ed esplicativa, una componente esemplificativa e una componente pratica,

Vengono coperti i principali concetti e termini nell'ambito del networking.

Vengono mostrati strutture e comandi relativi al networking in ambiente Linux.

Vengono poi realizzate delle reti emulate, per esercizi pratici, utilizzando l'ambiente Docker.

Una particolare attenzione è dedicata ai problemi di sicurezza: le vulnerabilità intrinseche dei protocolli TCP/IP possono essere sfruttate in attacchi hacker, noti, meno noti e ancora sconosciuti.

Licenza

La presente documentazione è distribuita secondo i termini della GNU Free Documentation License Versione 1.3, 3 novembre 200t8.

Ne è garantita assoluta libertà di copia, ridistribuzione e modifica, sia a scopi commerciali che non.

L'autore detiene il credito per il lavoro originale ma nè credito nè responsabilità per le modifiche.

Qualsiasi lavoro derivato deve essere conforme a questa stessa licenza.

Il testo pieno della licenza è a:

https://www.gnu.org/licenses/fdl.txt

Docker

La mera esposizione teorica non è didatticamente sufficiente.

Vogliamo compiere degli esercizi che coprano i seguenti argomenti:

• connessione tra un client e un server sulla stessa rete
• analisi del traffico durante una connessione
• connessione tra un client e un server su una rete vicina - il problema del routing
• regole di firewall perimetrale e personale
• enumerazione di servizi su un server

e tanto altro ancora.

Per questi esercizi ci occorrono clients, servers, reti.

Avere hardware fisico che copre le varie configurazioni è in pratica impossibile. Configurare gli host di rete con macchine virtuali è molto pesante di risorse per la macchina ospite.

La soluzione è di usare contenitori anzichè macchine virtuali, con la tecnologia Docker.

I contenitori sono molto più leggeri quanto a richiesta di risorse di CPU e memoria. Si può velocemente compiere il deployment di numerosi nodi di una o più reti collegando tra loro componenti Docker come fossero mattoncini da costruzione.

Il risultato emula sufficientemente la realtà per i nostri scopi didattici.

Evoluzione e componenti

Docker è un ambiente di isolamento delle risorse necessarie ad un applicativo all'interno di un contenitore

• Da circa 2013, ideato da Solomon Hykes
• Contributo di Red Hat
• Richiede Linux a 64 bit Kernel 2.6+
• Versione corrente: 20.10 (12/20)
• Licenza Apache (open)
• Scritto in linguaggio Go
• Virtualizzazione entro il sistema operativo
• Direzione: software indipendente dal sistema operativo

Macchine Virtuali e Contenitori

Macchine Virtuali: Virtualizzazione dell'Hardware

• Più sistemi operativi diversi
• Più flessibile
• Più maturo

Contenitori: Virtualizzazione dell'Ambiente Operativo

• Più efficienza
• Meno manutenzione di sistema
• Partenza molto più veloce
• Migliaia di immagini disponibili, con documentazione

NB: Il Kernel è quello dello host Linux

Tipi di Contenitori

• Process container - l’ambiente di esecuzione di un processo principale e possibilmente altri processi
• Network container - fornisce connettività, indirizzamento e risoluzione nomi ai contenitori di processo
• Data container - mantiene i dati in volumi e li persiste quando i contenitori di processo non sono attivi

Tutte le immagini da cui derivano i contenitori sono mantenuti in un repository sul computer locale

Proprietà di Docker

Docker è scritto nel linguaggio di programmazione Go

Molti dei suoi comportamenti sono dovuti al linguaggio Go

E’ distribuito da docker.com (o docker.io)

Ne esistono due versioni:

• enterprise - a sottoscrizione di licenza
• community - gratuito ed Open Source

Docker si basa su features architettoniche di Linux:

• cgroups - supporto kernel all’isolamento processi
• Union File System - FS composto da layers

La docker.com supporta il prodotto solo su Linux

Il Linux di riferimento è Ubuntu

E’ in fase di sviluppo un Linux di riferimento specifico per Docker indipendente dalle distribuzioni correnti

Immagini

Un contenitore è l'istanza run-time di un'immagine.

Un'immagine è la combinazione di un certo numero, variabile a seconda della specifica immagine, di strati software (Layers), integrati all'interno di uno Union File System.

Cgroups

Un cgroup (control group) è una feature che limita, traccia ed isola l’uso di risorse di una collezione di processi.

I Cgroups sono una parte integrale del kernel Linux

Forniscono l’implementazione nel system space dei contenitori dello user space

Componenti di Docker

• Dockerfile: specifica dei componenti necessari. File testuale di specifiche
• Image: risultato della compilazione del docker file. Serie di layers in un repository locale o remoto
• Container: istanza di realizzazione di una image

Più containers della stessa image sono istanze separate e indipendenti

Client-Server

Docker segue l'architettura Client-Server. Vi sono un eseguinile client e due server.

docker - client, Command Line Interface. Interfaccia con l’utente tramite comandi shell

dockerd - high-level server, interagisce con il client. Implementa il comportamento di Docker

containerd - low-level server, gestisce i container. Usato anche con contenitori non Docker, p.es. Kubernetes

Il server è gestito come servizio standard di Linux e si può controllare con il comando amministrativo:

sudo systemctl azione docker

ove azione può essere:

• status - stato del servizio e processi attivi
• start - far partire il servizio
• stop - fermare il servizio
• enable - configurare lo start automatico al boot
• disable - disabilitare lo start automatico al boot

Due componenti del server:

• docker.service - il servizio
• docker.socket - il socket Unix di collegamento

Il collegamento tra client e server avviene tramite un socket. In locale (default) questo è un socket Unix.

Installazione di Docker

Su Hardware o su VM VirtualBox, requisiti:

• Linux Ubuntu o simile (p.es. Mint), recente, 64 bit
• 4 GB RAM
• 100+ GB HD
• Connessione a Internet

Ultima Versione dal Repository Ufficiale

Installare dal repository di docker.io.

Versione più recente, e permette la successiva estensione con plugins.

Occorre configurare la locazione del repository ed scaricare il necessario certificato. Questo si compie al meglio, preparando la seguente procedura shell, docker-repo.sh:

vim ~/docker-repo.sh

#! /bin/bash
# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$UBUNTU_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
# Install the Docker packages:
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Rendere la procedura eseguibile e lanciarla:

chmod +x ~/docker-repo.sh
cd
./docker-repo.sh

Dopo l'installazione

Solo i membri del gruppo docker possono usare l'ambiente.

Configurare l’utente corrente:

sudo usermod -aG docker $USER

Reboot del sistema. In teoria un relogin è sufficiente, ma la VM Ubuntu vuole proprio un reboot

Test:

docker info

Package dal Repository di Release Linux

Alternativa al metodo precedente, In Ubuntu o simili:

sudo apt upgrade
sudo apt install docker.io

Questa versione di Docker così installata può essere non molto recente.

Docker Compose

Docker Compose è uno strumento per l’orchestrazione di più contenitori sulla stessa macchina host

Installare Docker Compose su Ubuntu:

sudo curl -SL https://github.com/docker/compose/releases/download/v2.23.3/docker-compose-linux-x86_64 -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
docker-compose version

Esiste anche una versione pacchettizzata di release, installabile con:

sudo apt install docker-compose

Ma è una versione relativamente vecchia, e sconsigliata.

Nuova Versione di Docker Compose

Il Docker Compose originale è una utility sviluppata da un gruppo indipendente da Docker.io

• scritta in Python
• comando con trattino separatore
  • docker-compose comando [opzioni] [argomenti]

Docker.io ha di recente aggiunto la sua versione di Docker Compose scritta in Go e parte del comando docker

• comando senza trattino separatore
  • docker compose comando [opzioni] [argomenti]
• La sintassi non è cambiata
• Usano entrambi il file docker-compose.yml

Installazione del Plugin

Docker Compose è un plugin scaricabile dal repository software di Docker.io.

Se è stata installata l'ultima versione di Docker tramite il repository della docker.io, allora il plugin Docker Compose è già installato.

Altrimenti si può scrivere la procedura shell docker-compose.sh:

#! /bin/bash
# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$UBUNTU_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
# Install the Docker Compose plugin:
sudo apt install docker-compose-plugin

Renderla eseguibile e lanciarla. Questo installa il plugin.

Docker: Connessione Client-Server

Introduzione agli Esercizi

Questo primo esempio introduce l'utilizzo degli strument Docker e Docker Compose nel realizzare una rete semplice.

Come primo esempio è prolisso e vengono descritti tutti i componenti della rete e come generarli.

Per quanto sia possibile seguire passo passo le istruzioni e preparare manualmente ogni componente (copiando il codice dalla documentazione e incollandolo nel proprio personale ambiente di esercizio), questo non è necessario.

Ogni esercizio è corredato di un file in formato TAR, che si può scaricare e scompattare.

Installazione di un Esercizio

Per esempio a questo esercizio è collegato il file 01net1-ccli-cssh.tar.

Scaricarlo in una directory che conterrà tutti gli esercizi e che deve venire creata:

mkdir -p ~/ex
cd ~/ex

Scompattarlo:

tar xvf 01net1-ccli-cssh.tar

Andare nella directory creata:

cd 01net1-ccli-cssh.tar

Creare fli oggetti dell'esercizio, o progetto specifico, col comando.

Se si usa il Docker Compose come plugin interno di Docker:

docker compose up -d

Se si usa l'utility Docker Compose scritta in Python:

docker-compose up -d

I dettagli di esecuzione dell'esercizio sono poi specifici all'esercizio stesso.

Pulizia dell'Esercizio

Al termine rimuovere tutti i contenitori di processo, di rete e di dati coinvolti nell'esercizio.

Se si usa il Docker Compose come plugin interno di Docker:

docker compose down

Se si usa l'utility Docker Compose scritta in Python:

docker-compose down

Una rete: 01net1-ccli-cssh

Descrizione concisa: Una rete, client e server SSH.

E' importante preparare un diagramma del progetto.

Non esiste uno specifico linguaggio di diagrammazione, ciascuno può scegliersi il suo. L'importante è rimanere consistemti in diagrammi di più progetti.

Il diagramma deve specificare tutti i componenti del progetto. Lo scopo è di passarlo ad un programmatore, che deve comprendere subito quello che deve preparare.

La rete si chiamerà net1 e il suo indirizzo CIDR sarà 192.160.100.0/24.

Sulla rete vi saranno due container: one e two, con indirizzi di host 11 e 12.

Il container one sarà generato dall'immagine ccli e sarà un client SSH, two dall'immagine cssh, un server SSH.

Il container two avrà un utente pippo, con password pluto.

Scaffolding

E' importante avere un nome distintivo del progetto, che suggerisca la struttura e le intenzioni di ciò che si vuole compiere.

Creare la directory di progetto:

mkdir -p ~/ex
cd ~/ex
mkdir 01net1-ccli-cssh
cd 01net1-ccli-cssh

L'albero dei files che comporranno il progetto è preparato prima, con i files vuoti. Questo è lo scaffolding (impalcatura) del progetto.

L'approccio è top-down.

Preparare lo scaffolding:

mkdir ccli cssh
touch ccli/Dockerfile cssh/Dockerfile
touch docker-compose.yml

Ogni immagine da generare ha una sottodirectory col nome dell'immagine, e contiene il suo Dockerfile, più ogni altro eventuale file necessario nal build.

A livello progetto vi è il file docker-compose.yml.

Il risultato è:

tree .

.
├── ccli
│   └── Dockerfile
├── cssh
│   └── Dockerfile
└── docker-compose.yml

Files del Progetto

ccli/Dockerfile

vim ccli/Dockerfile

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

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

CMD ["/bin/sleep","1000000"]

cssh/Dockerfile

vim cssh/Dockerfile

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

# Installazione del software
RUN apk --update add --no-cache openssh tcpdump \
openssh bash && rm -rf /var/cache/apk/*

# ‘root’ può fare login
RUN sed -i s/#PermitRootLogin.*/PermitRootLogin\ yes/ /etc/ssh/sshd_config \
  && echo "root:root" | chpasswd 
# Abilitare la porta 22
RUN sed -ie 's/#Port 22/Port 22/g' /etc/ssh/sshd_config

# Abilitare le chiavi crittografiche
RUN sed -ri 's/#HostKey \/etc\/ssh\/ssh_host_key/HostKey \/etc\/ssh\/ssh_host_key/g' /etc/ssh/sshd_config
RUN sed -ir 's/#HostKey \/etc\/ssh\/ssh_host_rsa_key/HostKey \/etc\/ssh\/ssh_host_rsa_key/g' /etc/ssh/sshd_config
RUN sed -ir 's/#HostKey \/etc\/ssh\/ssh_host_dsa_key/HostKey \/etc\/ssh\/ssh_host_dsa_key/g' /etc/ssh/sshd_config
RUN sed -ir 's/#HostKey \/etc\/ssh\/ssh_host_ecdsa_key/HostKey \/etc\/ssh\/ssh_host_ecdsa_key/g' /etc/ssh/sshd_config
RUN sed -ir 's/#HostKey \/etc\/ssh\/ssh_host_ed25519_key/HostKey \/etc\/ssh\/ssh_host_ed25519_key/g' /etc/ssh/sshd_config


# Generare le chiavi crittografiche
RUN /usr/bin/ssh-keygen -A
RUN ssh-keygen -t rsa -b 4096 -f  /etc/ssh/ssh_host_key

# Generazione dell’utente ‘pippo’ con password ‘pluto’
RUN adduser -D pippo && echo "pippo:pluto" | chpasswd

# Porta da esporre al port mapping
EXPOSE 22

# Comando da lanciare
CMD ["/usr/sbin/sshd","-D"]

docker-compose.yml

vim docker-compose.yml

version: '3.6'

services:
  one:
    build: ccli
    image: ccli
    container_name: one
    hostname: one
    cap_add:
      - ALL
    networks:
      net1:
        ipv4_address: 192.168.101.11
  two:
    build: cssh
    image: cssh
    container_name: two
    hostname: two
    cap_add:
      - ALL
    networks:
      net1:
        ipv4_address: 192.168.101.12
networks:
  net1:
    name: net1
    ipam:
      driver: default
      config:
        - subnet: 192.168.101.0/24

Esecuzione

Lancio del progetto:

docker compose up -d

Vengono create le immagini ccli e cssh.

Vengono attivate la rete net1 e i containers one e two.

Test

Collegarsi a one:

docker exec -ti one sh

Aprire una sessione SSH a two:

ssh pippo@two

• Accettare la chiave pubblica
• La password è pluto

Chiudere il collegamento ssh con exit.

Uscire da one con exit.

Pulizia

Da host, directory di progetto:

docker compose down

Vengono fermati i contenitori, poi rimossi i contenitori e la rete.

Esercizio 1A

Accedere ad un contenitore di processo con il comando, p.es. docker exec -ti one sh è fattibile ma pesante, e occupa una finestra di terminale.

Un'alternativa per chi dispone di un Linux con grafica è di configurare una finestra di terminale per l'accesso ad uno specifico contenitore di processo.

Questo lo faremo creando, nelle Preferenze di terminale, un nuovo profilo. In questo esercizio chiameremo il profilo one.

Dato che i vari contenitori di processo nei vari esercizi si chiamano one, two, three, ecc., possiamo creare un numero di profili di terminale con gli stessi nomi, ciascuno che accede al corrispondente contenitore di processo.

Nuovo Profilo di terminale

Nuovo profilo: one.

1. Cliccare sul menù di terminale
2. Selezionare Preferences
3. Aggiungere un profilo, cliccando il simbolo + accanto a Profiles
4. Dare al profilo il nome one

Custom Command

1. Nella nuova configurazione del profilo one, selezionare il tab Command
2. Spuntare "Run a custom command instead of my shell"
3. Nella finestra "Custom command" digitare:

bash -c "docker exec -ti one sh -c \"export PS1='\h:\W\# ' && sh -\""

Viene eseguito sul terminale one

• una prima shell che cambia il pronto primario PS1
• una shell figlia sh - e il simbolo - fa si che sia una shell di login, che quindi esegue il file .profile

Personalizzazione Colori

Per renderlo distintivo, cambiamo i colori del terminale.

1. Selezioniamo il tab "Colors"
2. Togliamo la spunta a "Use transparency"
3. Togliamo la spunta a "Use colors from system theme"
4. Nel menù a tendina di "Built in schemes" selezioniamo lo schema di colori, p.es. "Black on light yellow"
5. Chiudiamo la finestra di configurazione del profilo

Uso del Terminale

1. Menà "New Terminal" o "New Window"
2. Scegliere il profilo one

Nota - Occorre che il nostro esercizio sia attivo, cioè che sia stato dato in precedenza il comando docker compose up -d.

Profilo per two

Ripetere per un nuovo profilo two.

Il comando custom è naturalmente:

bash -c "docker exec -ti two sh -c \"export PS1='\h:\W\# ' && sh -\""

Schema di colori, per esempio, : Green on black.

Protocolli di Networking

Concetti di Base

Protocollo

Un Protocollo di Comunicazione è definito da due aspetti:

• Formato dei dati interscambiati
• Regole di interscambio

Tutto deve essere implementato in software su un sistema operativo di riferimento.

Storicamente, a partire da circa il 1980, il linguaggio di implementazione dei protocolli di rete è stato il Linguaggio C, e la piattaforma di sistema operativo di riferimento è stata Unix.

I discendenti diretti sono il C++, in cui è scritto Windows, e Linux.

Abbiamo quindi le puntualizzazioni seguenti.

Formato Dati

E' definito da struct in linguaggio C.

Regole di Interscambio

Sono definite da un algoritmo della categoria Macchine a Stati Finiti (Finite State Machines - FSM).

Questi sono algoritmi deterministici, che prima vengono descritti in pseudocodice poi implementati in Linguaggio C. Una buona specifica di un FSM è immediatamente rendibile in codice.

Esempio: TCP FSM

Data Communication

Interscambio di dati fra DTE tramite DCE:

• DTE - Data Terminal Equipment
• DCE - Data Communication Equipment

Commutazione

Commutazione di Circuito

• Sincrono
• Tre fasi: stabilimento, uso e abbattimento del circuito
• La comunicazione è un unico flusso e passa necessariamente attraverso il circuito stabilito, anche se la qualità degradasse
• In caso di malfunzionamenti gravi, occorre ristabilire il circuito
• Telefonia tradizionale

Commutazione di Messaggio

• Store and Forward - ogni messaggio transita per intero dal nodo trasmittente a quello ricevente di un link; il ricevente lo accumula localmente; quando il messggio è tutto presente lo invia al prossimo destinatario
• UUCP - Unix to Unix Communication Programs era una serie di programmi per posta e newsgroups (posta a sottoscrizione), che usavano questo metodo

Commutazione di Pacchetto

• Il messaggio è suddiviso in segmenti, che vengono incapsulati in pacchetti
• Similitudine con la Posta Tradizionale, i pacchetti si chiamano anche datagrammi
• i pacchetti sono smistati separatamente
• Internet, ma non solo

Evoluzione di Internet

ARPAnet

(Defense) Advanced Research Project Agency

• Molti progetti finanziati, anche la telepatia; conseguentemente molti sprechi
• Complesso Militare/Civile/Universitario
• Scopo: supremazia tecnologica degli USA

ARPAnet - dal 1969

• Comunicazione dati a lunga distanza
  • US continentali, esteso a (poche) basi estere
• Parte del Command & Control in caso di conflitto
  • Progettata per essere resilente
• Basata su commutazione di pacchetto
• Inizialmente software e hardware dedicati su Host
  • Computer della Bolt, Beranek & Newman
  • Codice “Fuzzball”, OS dedicato, CPU 32 bit
• Poi riscritto in Linguaggio C per BSD Unix

Arpanet 1974

Contrariamente a quello che si pensa, la prima rete ARPAnet non era a molte maglie, non esistevano molti percorsi alternativi, e non sarebbe stata resiliente in caso di attacco atomico.

Fuori dagli Stati Uniti continentali vi era il nodo delle Hawaii, quello di Londra, e un terzo nodo in una base americana nella Norvegia del nord, con un radar di ascolto puntato sull'Unione Sovietica.

ARPAnet era comunque in attiva espansione, quindi sarebbe in seguito diventata resiliente.

ARPAnet ha tre caratteristiche di nota:

• Commutazione di pacchetto
  • Il ricevente ricompone i pacchetti, poichè frammenti di pacchetto possono aver compiuto percorsi diversi
  • Eventualmente richiede ritrasmissione
• Routing dinamico
  • Ciascun pacchetto, o suo frammento, segue il link migliore nell’istante di smistamento
  • Se nodi falliscono il routing successivo sceglie altri link
  • Notevole resilienza
• Device di smistamento intelligenti
  • Host non switch
  • Ciascuno mantiene una Tabella di Routing

Simile a Store and Forward ma per pacchetti, non interi messaggi

Un pacchetto = max pochi kilobytes

Limite massimo di dimensione di un pacchetto: 64 kilobytes

Ma le librerie interne implementative della Berkeley consentivano una dimensione massima di 8 kilobytes

Modello ISO/OSI

Fino a circa 1984 un produttore di soluzioni di rete doveva offrire tutta la catasta software necessaria, dall'accesso fisico alla rete ai programmi per utente.

C'erano offerte disponibili, ma evidentemente con variabilità dei componenti e flessibilità limitate. IBM ha sempre fatto così: Total Solutions, leggi Vendor Lock-In.

Occorre che componenti diverse della catasta di software di rete possano essere offerte da Vendor diversi: occorre interoperabilità.

Modello Software di Rete

• Visione gerarchica dei livelli di problemi
• Delegazione dei dettagli ai livelli sottostanti
• Importanza della definizione delle interfacce
  • L’interfaccia è un contratto
  • Come con le funzioni: parametri passati, risultato ricevuto, si ignora il comportamento interno della funzione

I livelli sono indipendenti

• Un livello ignora cosa compiano i livelli sottostanti e soprastanti
• Vendor differenti possono codificare livelli differenti
• Il software di un livello può essere sostituito

International Standards Organisation / Open System Interconnection

1. Livello Fisico

• Dettagli di comunicazione col mezzo fisico
• Legge e scrive bytes dalle schede di rete

2. Livello Data Link

• Gestisce il collegamento tra due nodi

3. Livello Rete

Meglio detto Livello di Internetworking

• Incapsula le unità trasmissive del livello soprastante in pacchetti dati
• Decide lo smistamento (routing) dei pacchetti dati a nodi remoti tramite nodi prossimi
• Ha un modello operativo della topologia di rete
  • Non conosce l’intera rete, ma abbastanza da compiere operazioni di smistamento pacchetti

4. Livello Trasporto

• Suddivide i messaggi dei livelli superiori in unità trasmissive in partenza
• Ricompone i messaggi dalle unità trasmissive in ricezione
• Si assicura di:
  • sequenzialità delle unità trasmesse e ricevute
  • assenza di errori, con eventuale richiesta di ritrasmissione

5. Livello Sessione

• Gestisce insiemi di messaggi che insieme delineano una sessione
  • Si assicura della consistenza e appropriatezza dei messaggi
  • Inizia, traccia e termina le sessioni
• Gestisce fattori di sicurezza trasmissiva
  • Identificazione e autorizzazione (autenticazione)
  • Crittografazione dei messaggi

6. Livello Presentazione

• Rappresentazione dei tipi di dati trasmessi
  • Interi a 16, 32 o 64 bit
  • Interi Big Endian o Small Endian
  • Stringhe US ASCII, ISO o Unicode

1986: Sun Microsystem regala al mondo le librerie Open Network Computing (ONC)

XDR diviene il Network Order - formato dei dati trasmessi in rete

Coincide col formato dati usato dalla Sun

Genere dei Byte

Direzione di storaggio degli interi (32 bit) in memoria

Esempio: 4A693E7F

Big Endian: byte più significativo per primo

Little Endian: byte meno significativo per primo

• Motorola: Big Endian
• Intel: Little Endian

Il Network Order TCP/IP è Big Endian

7. Livello Applicazione

• Interagisce con l’utente tramite software (client):
  • di terminale - linea di comando (Command Line Interface - CLI)
  • di grafica (Graphical User Interface - GUI)
• Fornisce dati o compie operazioni (server)
• Interopera con altre librerie del Sistema Operativo

Due modelli distribuiti:

• Peer-to-Peer
  • Assume indifferentemente il ruolo di client o di server a seconda delle circostanze
  • Un singolo programma

• Client-Server
  • Un nodo è sempre nel ruolo di server e l’altro nodo è sempre nel ruolo di client
  • Due programmi separati

Dispositivi di Rete

Modello DoD

Evoluzione Modelli di Rete

ISO/OSI è usato da pochi vendors: Sun, Digital, ...

ARPAnet formalizza i protocolli Internet alla Univerity of California, Berkeley

• Si chiamano genericamente i protocolli TCP/IP
• Implementazione di riferimento in BSD UNIX

Il modello a livelli sottostante è chiamato modello del Dipartimento della Difesa (Department of Defense - DoD)

• E’ di qualità inferiore rispetto a ISO/OSI
• Ha una vasta infrastruttura di rete già dispiegata
• Soprassiede lentamente a ISO/OSI
• Il successo di Internet degli anni ‘90 affossa ISO/OSI

Lo switch da ISO/OSI a DoD è come standardizzare formalmente l'industria sul Sistema Metrico Decimale, poi avere le industrie che in pratica richiedono design col sistema Imperiale. E le industrie americane fanno tutt'ora proprio così.

Tutti sappiamo che la pressione marina aumenta di 14,7 libbre per pollice quadrro ogni 33 piedi di profondità, e che la densità dell'acqua dolce è di 62 libbre per piede cubo.

Ma l'America è forte e potente e ha la sesta flotta e fa quello che vuole. Come lo chiami un orang-utan da due tonnellate? "Signore".

Tre livelli vendor-independent:

• Interfacce Fisiche: delegate ai costruttore di device drivers
• Protocolli di Rete: il cuore del modello, i protocolli TCP/IP
• Applicativi: programmabili con librerie in linguaggio C

Corrispondenza non precisa coi livelli ISO/OSI

Protocolli di Rete è diviso in due sottolivelli funzionali ma non tra loro indipendenti:

• Internetworking: routing e funzionalità a basso livello
• Controllo End-to-End: sequenzializzazione, recupero errori, interazione tra nodi comunicanti

Due interfacce:

• Device Driver Interface: specifica di UNIX o altri sistemi
• Berkeley ‘Socket’ Interface (BSI): implementazione UNIX del concetto astratto di Porta (port) di accesso ai servizi

Paragone degli Stack di Comunicazione:

Concetti del Modello DoD

Incapsulamento

internet

• LAN – Local Area Network

  • Dimensione locale
  • Singola tecnologia di link

• WAN – Wide Area Network

  • Dimensione geografica anche mondiale
  • Anche più tecnologie di link

• MAN – Metropolitan Area Network

  • Dimensione geografica limitata

• PAN - Personal Area Network

  • Dimensione limitata alla prossimità con l’utente

• BAN – Body Area Network

  • Nodi su wearable devices o impiantati nel corpo

• Intranet

  • Devices e connessioni sotto il controllo di un unico ente

Una internet con la *i minuscola è semplicamente una rete di reti, con topologie varie: a bus, a stella, ad anello, a singoli link.

Quando la rete di reti di reti inizia ad avere ambito globale, allora la si chiama Internet con la I maiuscola, per antonomasia.

Modello di Connessione

Orientato alla Connessione

• Il percorso dei pacchetti è prestabilito prima dell’invio
• Tre fasi della connessione:
  • Stabilimento
  • Uso
  • Abbattimento
• TCP: Transmission Control Protocol
• Simile a telefonata

Connectionless

• I pacchetti sono inviati subito quando sono pronti e il loro percorso in rete non è prestabilito
• UDP: User Datagram Protocol
• Simile a posta tradizionale

Sotto sotto, a livello internetworking, il modello è connectionless: ciascun datagramma va dove è meglio nel momento che passa, potenzialmente perdendosi o scompigliando la sequenza trasmissiva.

E' compito del protocollo Connection Oriented mantenere stato (stateful): ricomporre la sequenza e richiedere la ritrasmissione dei datagrammi persi. Il prodotto utente richiede che i dati vengano trasferiti tutti e nella sequenza giusta.

I protocolli Connectionless sono adatti invece a situazioni in cui l'informazione trasferita è poca, oppure quando la perdita di un certo numero di datagrammi non influisce sulla fruibilità utente del prodotto.

Modello di Comunicazione

Message Based - interscambio di messaggi

Remote Procedure Call - funzioni di sistema eseguite su macchina remota per conto di quella locale

Flussi di Comunicazione

• Sincrono
  • Bloccante, continuo, con controllo errori e ritrasmissione
• Asincrono
  • Non bloccante, non continuo, può avere controllo errori
• Streaming
  • Non bloccante, continuo, senza controllo errori
• Publish/Subscribe
  • Asincrono estremo, non continuo, controllo errori da parte dei livelli applicativi

Parametri di Comunicazione

Alla fine la velocità della luce è finita e la comunicazione impiega un lasso di tempo discreto. Il mezzo trasmissivo non ha qualità costante, ha rumore, e il suo utilizzo costa.

Presunzioni Errate

I programmatori di applicativi di rete hanno delle aspettative implicite sul comportamento della rete. Presumono i seguenti punti:

1. La rete è affidabile
2. La latenza è zero
3. La larghezza di banda è infinita
4. La rete è sicura
5. La topologia di rete non cambia
6. C’è un amministratore di rete
7. Il costo è zero
8. La rete è omogenea

Ciascuna di queste apettative può non essere vera, e introdurre problemi.

Principali Protocolli TCP/IP

Vi sono letteralmente decine di protocolli TCP/IP, proposti in ancora più documenti RFC. Solo alcuni di loro hanno una certa importanza.

Internetworking

Indispensabili:

• IP - Internet Protocol
  • evolutosi nel tempo, cambiamenti e patch guidati soprattutto da problemi di sicurezza ed efficienza

Ausiliari, raccomandati:

• ICMP - Internet Control Message Protocol
• ARP - Address Resolution Protocol
• praticamente nessun altro

Opzionali:

• RIP - Routing Information Protocol
• OSPF - Open Shortest Path First
• BGP - Border Gateway Protocol
• molti altri, specialmente nel campo del routing

End-to-End Control

Indispensabili:

• TCP - Transmission Control Protocol
• UDP - User Datagram Protocol
• altri protocolli sono stati proposti e provati, ma sono praticamente caduti nel dimenticatoio

Documentazione di TCP/IP

Originariamente i tecnici e i progettisti dei protocolli erano relativamente pochi, e si riunivano regolarmente per discutere proposte innovative e di miglioramenti.

Il rapporto di questi meeting veniva pubblicato in bacheca, con la scritta Request For Comments (RFC). La sigla è rimasta anche quando i documenti tecnici non erano più il risultato di una riunione.

I documenti RFC sono ora formalmente accettati come ufficiali dalla governance del progetto TCP/IP. La governance è la Internet Engineering Task Force (IETF). Dettagli sui processi e prodotti di governance si trovano sul sito della IETF,

Il loro contenuto varia dall'altamente tecnica definizione di protocolli, a considerazioni pratiche d'uso, fino al faceto e al pesce d'aprile.

Una lista deli RFC come pesce d'aprile si trova su Wikipedia alla voce "April Fools' Day Request for Comments".
Rimane famoso quello del 1999, " IP over Avian Carriers with Quality of Service", che propone l'uso di piccioni viaggiatori per recapitare i datagrammi

Sono catalogati con un numero di protocollo sequenziale, anche se non tutti i numeri sono stati assegnati. Sono circa 10.000. Una lista parziale si trova, p.es. su Wikipedia.

Livelli TCP/IP

I livelli TCP/IP sono quattro, anzi veramente tre poichè Transport e Network sono strettamente connessi: ciascuno conosce ed usa dettadli dell'altro.

Livelli Fisici

Il Modello DoD si preoccupa poco del suo livello inferiore, Physical Interfaces, e ne lascia la formalizzazione ad altri organi di standardizzazione.

IEEE 802.x

IEEE: Institute for Electrics and Electronics Engineers

Serie di protocolli standard che coprono il livello di Data Link

Sviluppato indipendentemente dai modelli ISO/OSI e DoD

Internetworking e Indirizzamento

Indirizzo IP

• Identifica una terminazione di connessione

• Se due nodi sono potenzialmente raggiungibili tra loro, non possono avere lo stesso Indirizzo IP

• E’ a 32 bit in IP Versione 4

  • Dimensione registro di CPU delle macchine ARPA storiche

• Espresso in Notazione Punto

  • 4 bytes in decimale, separati da punti
  • Esempio: 167.19.230.45

Tre tipi tradizionali:

• Indirizzo di Host
  • Singola interfaccia di una macchina in rete
• Indirizzo di Rete
  • La rete come entità
• Indirizzo di Broadcast
  • Tutti gli host di una rete

Evoluzione degli Indirizzi

Inizialmente vi era una sola rete e gli indirizzi degli host sulla rete erano semplici numeri interi.

Gli host erano macchine col sistema operativo Fuzzball della ditta Bolt, Beranek and Newman. Il loro registro di CPU era a 32 bit e lo storaggio di tipo MSB (Most Significat Byte first), quindi i numeri bassi cadevano nell'ultimo byte e i primi byte erano vuoti.

Quando altre reti, con governance autonoma, si sono agganciate alla originale ARPAnet vi è stata la necessità di identificare la rete oltre che lo host.

E' stato deciso di porre l'indirizzo di rete nel primo byte. Chi mai avrebbe pensato che vi sarebbero state più di 255 reti in futuro?

Incidentalmente a questo punto è sorto anche il concetto di gateway: lo host particolare collegato a due reti contemporaneamente.

Il percorso di smistamento veniva indicato con una opzione del datagramma IP, chiamata source routing: la lista di indirizzi di gateways attraverso cui il pacchetto doveva passare.

Classi di Indirizzamento

Con l'aumentare del numero di reti connesse la soluzione originale non era più praticabile.

Si è constatato che vi erano reti grandi, medie e piccole, e si è deciso di chiamarle rispettivamente reti di classe A, B e C.

Se in un indirizzo il primo bit è 0 allora è un classe A. Se il primo bit è 1 e il secondo è 0, allora è in classe B. Se i primi due bit sono 1 e il terzo è 0 allora è in classe C. (Incidentalmente, il terzo bit non può mai essere un 1).

• Lunghezza variabile dell’indirizzo di rete
• Separazione al confine di byte
• Possibile costruire sottoreti, ma lo smistamento Internet avviene a livello di rete

Le classi di indirizzamento non sono più la norma nel moderno uso di attribuzione di indirizzi. La rete a cui appartiene un indirizzo viene esplicitamente indicata come parametro di asswgnazione di un indirizzo IP. Con certe utility, se tale parametro di indicazione di rete manca, viene assegnata di default una rete conforme alla classe di indirizzamento tradizionale.

Per esempio, a meno di ulteriori specifiche, l'indirizzo IP 192.168.12.27 è in classe B, l'indirizzo IP 10.12.240.18 è in classe A.

CIDR

Problemi col passare del tempo (circa 1995):

• Problema del numero delle classi - gli indirizzi in classe A sono quasi finiti, in classe B scarseggiano, in classe C sono ancora molti.
• Problema dello spreco: circa il 90% degli indirizzi in classe B non sono assegnati a host, circa il 98% di quelli in classe A
• Problema del routing: al proliferare delle reti, le tabelle di routing dei gateway principali diventano enormi

Occorre una maggiore granularità nell'assegnare reti.

Classless InterDomain Routing (CIDR)

Indirizzi non devono più essere in Classi:

• Suddivisione Classi in Sottoclassi
• Aggregazione Classi in Superclassi
• Semplificazione delle Tabelle di Routing

Un terminatore di connessione (indirizzo) ha sempre associati due registri di 32 bit:

• registro di indirizzo (I)
• registro di maschera (M)

Entrambi sono divisi da un setto separatore nello stesso punto.

Prima del separatore il registro di maschera ha tutti i bit a 1, dopo il separatore tutti i bit a 0.

La parte del registro di indirizzo prima del separatore si chiama prefisso di rete, quella dopo il separatore indirizzo di host. La lunghezza del prefisso di rete P può andare da 0 a 32, e non è più necessariamente un multiplo di 8 come con le classi di indirizzamento.

La notazione CIDR per indicare un indirizzo è:

indirizzo_completo_a_32_bit / lunghezza_del_prefisso

Per la parte indirizzo completo si usa la notazione punto: i 4 byte dell'indirizzo a 32 bit ciascuno indicato come intero, separati da un punto. Ogni byte, essendo di 8 bit, ha naturalmente un valore compreso tra 0 e 255.

La parte lunghezza del prefisso, dopo la barra (slash) si indica semplicemente come valore intero.

Un indirizzo conseguente è l'indirizzo di rete (N), che si ottiene ponendo dopo il prefisso di rete tanti 0 quanto necessari per arrivare a 32 bit.

Il numero teorico di indirizzi host disponibili in quella rete è quindi 2 elevato alla diferenza 32-P.

Un secondo indirizzo derivato è l'Indirizzo di Broadcast (B), che si ottiene completando il prefisso di rete a 32 bit con degli 1. Un pacchetto con l'indirizzo di broadcast nel campo di destinazione viene inviato a tutti gli host di quella rete.

Il numero di host effettivamente disponibili in una rete è quindi il numero teorico meno i due indirizzi speciali di rete e di broadcast.

Logicamente possiamo dire che:

N = I .and. M
B = I .or. ( .not. M )

Routing CIDR

La vera, e più sottile e recondita, innovazione del CIDR è nelle tabelle di routing. Non per niente il CIDR è stato fortemente voluto da Cisco.

Una tabella di routing non contiene indirizzi di reti vere, e la maschera non si chiama più Netmask, ma Genmask. Rappresenta una aggregazione di reti, volendo, una superrete, raggiungibile tramite lo stesso gateway, ovvero il prossimo hop a cui inviare il pacchetto smistato.

Man mano che il pacchetto smistato procede verso destinazione, trverà nella tabella di routing degli hop successivi delle Genmask più precise, meno generiche, fino ad arrivare a destinazione finale.

I due limiti sono:

• un Genmask di lunghezza di prefisso 32 rappresenta un singolo host
• un Genmask di lunghezza di prefisso 0 rappresenta l'intera Internet

Per i router le reti vere non esistono, solo regole di snistamento

Utility ipcalc

Un indirizzo CIDR, espresso in notazione punto, non ha la parte di rete che necessariamente termina con byte a zero, come avveniva per gli indirizzi in classi di indirizzamento.

Semplicemente guardando un indirizzo generico, è arduo dedurre se si tratti di un indirizzo di una rete o di uno host, e nell'ultimo caso quale sia l'indirizzo di rete corrispondente e l'indirizzo di broadcast.

L'utility Linux ipcalc aiuta molto nei calcoli.

Esempio: ipcalc 110.142.226.37/27

Indirizzi IP non per Internet

I primi tre range di indirizzi sono definiti dallo RFC 1918. Qualsiasi router esterno si veda arrivare un pacchetto con questi indirizzi nel campo mittente o destinatario è pregato di buttare il pacchetto. Sono indirizzi destinati al traffico Intranet.

Ci sono molti altri range di indirizzi che non sono mai stati assegnati dallo IANA - Internet Assigned Numbers Authorities. Un pacchetto con questi indirizzi nel campo mittente viene regolarmente smistato. Sono idealmente Indirizzi di Spoofing.

iproute2

Nuovi comandi per la gestione rete in Linux ( Alexey Kuznetsov - Kernel 2.6+). Disponibile ormai da 20 anni.

E' una revisione radicale degli algoritmi di routing nello spazio sys, ovvero nel kernel Linux, basata sul concetto geberico di tabella di snistamento. La tradizionale tabella di routing non è che uba delle tante tabelle gestite dal nuovo ambiente.

Iproute2, anche chiamato Netfilter, è gestito dallo spazio usr da tre comandi:

ip

• Gestione indirizzi e routing
• Esempi di comandi sostituiti da ip:

tc

• traffic control - gestione aspetti avanzati dell’indirizzamento
• code, limitazione del traffico, multipath, ecc.

iptables

• filtraggio e trasformazione pacchetti
• base di un firewall

Documentazione completa e guida all'uso si trova in PDF al link Linux Advanced Routing & Traffic Control HOWTO

Routing

Azioni da intraprendere per lo smistamento di un pacchetto (datagramma) dal nodo di rete corrente ad un altro nodo di rete generico

Compiuto da IP: Internetworking Protocol

• In cooperazione con altri protocolli di rete: TCP o UDP, ICMP, ARP, RIP o OSPF, ecc.

Due filosofie interoperanti:

• Destination driven routing
  • Scelte determinate dall’indirizzo IP del destinatario
  • Tradizionale
• Policy driven routing
  • Scelte determinate da più fattori, anche indirizzo IP del mittente, porte, metrica, tipi di link, ...
  • In generale: Quality of Service

Tabella di Routing

Tabella del kernel con le informazioni necessarie per lo smistamento dei pacchetti

Tutti i nodi hanno una tabella di routing

Esempio di host connesso solo ad un gateway (Linux):

route -een

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface    MSS   Window irtt
0.0.0.0         192.168.0.1     0.0.0.0         UG    600    0        0 wlp3s0   0     0      0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlp3s0   0     0      0
192.168.0.0     0.0.0.0         255.255.0.0     U     600    0        0 wlp3s0   0     0      0

I nodi con multiple connessioni hanno una tabella di routing molto più complessa

Tabella di routing di Linux:

Superreti e Sottoreti

Operazioni Binarie

Data una rete net di maschera mask, un indirizzo ind appartiene a tale rete se:

(ind AND mask) == net

• Un pacchetto in arrivo, che deve essere smistato, non ha maschera
• Si considera a quali delle reti della tabella di routing appartiene
• Se ve ne è più di una viene scelta quella con lunghezza di maschera maggiore
• Viene smistato al gateway corrispondente

La tabella di routing associa reti generiche a gateways.

La maschera è generica. Non implica che esista una rete con quella maschera.

Quando arriva un pacchetto da smistare:

• Il pacchetto viene smistato al gateway della superrete meno generica disponibile che lo contiene

• Se vi sono più reti con la stessa genericità viene smistato al gateway della rete con metrica minore

• Se non vi sono reti a cui il pacchetto appartiene, il pacchetto viene scartato, senza ulteriori azioni

• La rete 0.0.0.0/0 è la più generica possibile e corrisponde al default

• Dovrebbe sempre esserci in una tabella di routing

Popolare la Tabella di Routing

Due modi:

• Manualmente
  • Per reti semplici
  • Configurazione statica e poco flessibile
• Tramite un protocollo di Route Update
  • Per reti più complesse
  • Dinamicamente
  • Necessita installazione e configurazione
  • Richiede CPU e RAM
  • Sente e si adatta ai cambiamenti di rete

Protocolli Vector Distance

Ogni nodo sa quanti hops mancano a destinazione

• Lo comunica ai nodi vicini
• La metrica di ogni link è 1

Protocolli State Link

Ogni nodo possiede una mappa della rete

• Più o meno completa e aggiornata
• Ogni link ha una metrica diversa

Unreliable, Best Effort

Il routing IP non è formalmente affidabile:

• Non vi è alcuna garanzia che un pacchetto arrivi a destinazione
• Un pacchetto non smistabile è semplicemente scartato
• Anche in altre occasioni un pacchetto può venire scartato:
  • Filtraggio pacchetti
  • Saturazione del router
• A volte il mittente viene avvertito, altre volte no
• Tocca ai protocolli a più alto livello preoccuparsi della conferma di ricezione o della richiesta di trasmissione

Protocolli ausiliari aiutano IP a mantenere la tabella di routing efficiente:

• ICMP: Internet Control Message Protocol
  • Messaggi di servizio sullo stato della rete
• Protocolli vari di Route Update

Esempio di Routing Statico

03net1-ccli-net2-cssh

Due reti, client e server SSH su reti diverse.

Problema del routing.

Scaffolding

Creare la directory di progetto:

mkdir 03net1-ccli-net2-cssh
cd 03net1-ccli-net2-cssh

Lo scaffolding è:

mkdir ccli cfw cssh
touch ccli/Dockerfile cfw/Dockerfile cssh/Dockerfile
touch docker-compose.yml
tree

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

I Dockerfile di ccli e cssh sono gli stessi dell’esercizio 01net1-ccli-cssh.

cp ../01net1-ccli-cssh/ccli/Dockerfile ccli/Dockerfile
cp ../01net1-ccli-cssh/cssh/Dockerfile cssh/Dockerfile

Creare uno Gnome-terminal per two e three se non esistono.

Files

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

CMD ["/bin/sleep","1000000"]

docker-compose.yml

vim docker-compose.yml

version: '3.6'

services:
  one:
    build: ccli
    image: ccli
    container_name: one
    hostname: one
    cap_add:
      - ALL
    networks:
      net1:
        ipv4_address: 192.168.101.11
  two:
    build: cssh
    image: cssh
    container_name: two
    hostname: two
    cap_add:
      - ALL
    networks:
      net2:
        ipv4_address: 192.168.102.12
  three:
    build: cfw
    image: cfw
    container_name: three
    hostname: three
    cap_add:
      - ALL
    networks:
      net1:
        ipv4_address: 192.168.101.10
      net2:
        ipv4_address: 192.168.102.10
networks:
  net1:
    name: net1
    ipam:
      driver: default
      config:
        - subnet: 192.168.101.0/24
  net2:
    name: net2
    ipam:
      driver: default
      config:
        - subnet: 192.168.102.0/24

NOTA

L'esercizio è scaricabile come file tar 03net1-ccli-net2-cssh-senza-routing.tar

Raggiungibilità

Lanciare il progetto:

docker compose up -d

Aprire i terminali one, two, three.

Su one (192.168.101.11):

ping 192.168.101.10 - funziona

ping 192.168.102.12 - non funziona

Su two (192.168.102.12):

ping 192.168.102.10 - funziona

ping 192.168.101.11 - non funziona

Manca il routing. Aggiungerlo manualmente.

Su one:

ip route add 192.168.102.0/24 via 192.168.101.10

Su two:

ip route add 192.168.101.0/24 via 192.168.102.10

Riprovare la raggiungibilità. Ora funziona.

Ma vogliamo che vi sia in automatico al lancio dei containers, non aggiungerla a mano.

Useremo degli entrypoints.

Prima chiudere il progetto:

docker compose down

Modifica al Client

Modifica a one (ccli).

vi ccli/entrypoint.sh

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

exec "$@"

vi ccli/Dockerfile

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

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

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

Modifica al Server

Modifica a two (cssh).

vi cssh/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 "$@"

vi cssh/Dockerfile

....
RUN ssh-keygen -t rsa -b 4096 -f  /etc/ssh/ssh_host_key
RUN adduser -D pippo && echo "pippo:pluto" | chpasswd

# Porta da esporre al port mapping
EXPOSE 22

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

# Comando da lanciare
CMD ["/usr/sbin/sshd","-D"]

Modifica a docker-compose.yml

vim docker-compose.yml

version: '3.6'

services:
  one:
    build: ccli
    image: ccli
    container_name: one
    hostname: one
    depends_on:
      - three
    cap_add:
      - ALL
    networks:
      net1:
        ipv4_address: 192.168.101.11
  two:
    build: cssh
    image: cssh
    container_name: two
    hostname: two
    depends_on:
      - three
    cap_add:
      - ALL
    networks:
      net2:
        ipv4_address: 192.168.102.12
  three:
    build: cfw
    image: cfw
    container_name: three
    hostname: three
    cap_add:
      - ALL
    networks:
      net1:
        ipv4_address: 192.168.101.10
      net2:
        ipv4_address: 192.168.102.10
networks:
  net1:
    name: net1
    ipam:
      driver: default
      config:
        - subnet: 192.168.101.0/24
  net2:
    name: net2
    ipam:
      driver: default
      config:
        - subnet: 192.168.102.0/24

NOTA

L'esercizio è scaricabile come file tar 03net1-ccli-net2-cssh-con-routing.tar

Riprova

Cancellare le immagini ccli e cssh:

docker rmi ccli:latest cssh:latest

Questo è importante. Le immagini devono venir ricreate.

Lanciare il progetto:

docker compose up -d

Vengono ricreate le immagini ccli e csh.

Aprire i terminali one e two che si pingano a vicenda. Dovrebbero vedersi.

Alla fine terminare il progetto:

docker compose down

Internetworking Protocol

Formato Datagramma IP

• version - 4 oppure 6
• hdr lnth - header length in parole - min 5 max 15
• tipo di servizio - maschera binaria
• lunghezza totale - del pacchetto, in bytes
• identificativo - aumentato di uno a ogni nuovo pacchetto
• R - riservato - non in uso
• DF - Don’t Fragment - non frammentare il pacchetto
• MF - More Fragments - altri frammenti seguono
• Time-to-Live - decrementato di uno da ogni router
• Protocol - ID del protocollo di trasporto
• Header checksum - della testata
• Source IP address - del mittente
• Destination IP address - del destinatario
• Options - opzioni facoltative

Type of Service

ToS: tipo di servizio richiesto e priorità

Si presumeva di attribuire ad ogni link fino a quattro proprietà (espandibili a cinque):

• Delay
• Throughput
• Reliability
• Cost

In realtà una tale rete non è stata sviluppata e il campo ToS è caduto in disuso

Il campo è stato di recente riciclato come:

• Differentiated Services Code Point (DSCP)
  • richiesta di qualità di servizio per real-time streaming
• Explicit Congestion Notification (ECN)
  • notifica di congestione senza perdita di pacchetti
  • richiede che tutti i nodi di rete lo supportino

Lunghezza Totale

La lunghezza totale potenziale di un datagramma è 65535 bytes inclusa la testata

• In realtà un pacchetto è al massimo lungo quanto la capacità trasmissiva massima del link fisico: MTU - maximum Transfer Unit
• Esempio: Ethernet circa 1450 bytes

Attenzione a non presumere che il payload sia onesto

• Esempio 1: ping ha un payload e può essere modificato
• Il payload può essere crittografato
• Il payload può avere contenuto steganografico

Identificativo del Pacchetto

Campo di 16 bit -> max 65535

• Assegnazione semplice: incremento di 1
• Quando è in overflow si ritorna a 1 (rollover)

Non ci devono essere due pacchetti diversi con lo stesso identificativo

Ma: i pacchetti possono essere ricevuti fuori sequenza

• Parcheggiati temporaneamente in un buffer di ricezione in attesa dei pacchetti mancanti
• Timeout se il pacchetto non arriva

Il timeout deve essere inferiore al tempo di rollover

Timeouts sempre più piccoli con reti sempre più veloci

Time to Live (TTL)

• Ogni nodo intermedio che smista un pacchetto (router) lo decrementa di 1
  • Quando il valore arriva a zero il pacchetto è scartato
    • per impedire loop di routing infiniti
• Solitamente (non sempre) viene inviato al mittente un messaggio ICMP per avvertire del fatto
  • se c’è un loop di routing anche il messaggio è perso
  • non si mandano mai messaggi ICMP per informare della perdita di un messaggio ICMP

traceroute

Serve a scoprire il percorso compiuto dai pacchetti

• Si invia un pacchetto iniziale (sonda) con TTL=1 poi pacchetti successivi sonda col TTL incrementato di 1
• Il router che scarta il pacchetto ritorna un messaggio ICMP TTL Time Exceeded
• Quando il pacchetto arriva a destinazione risponde con un altro messaggio

Non funziona sempre:

• Un router può non inviare un messaggio ICMP
• Il percorso può cambiare tra una sonda e l’altra
• Un firewall può semplicemente scartare la sonda e non avvertire (buco nero)

Comportamenti diversi Windows e Linux

• Windows invia una sonda ICMP Echo Request (ping) e riceve un ICMP Echo Reply (pong)
• Linux invia una sonda UDP a porta improbabile e riceve un ICMP Port Unreachable

Opzioni IP

Struttura delle opzioni IP:

Alcune opzioni IP:

• loose source routing (codice 0x83)
  • specifica una lista di indirizzi IP che il datagramma dovrebbe attraversare
• strict source routing (codice 0x89)
  • specifica una lista di indirizzi IP che il datagramma deve obbligatoriamente attraversare
• record route (codice 0x07)
  • ogni router indica il suo indirizzo IP sul pacchetto
• timestamp (codice 0x44)
  • ogni router indica il suo indirizzo IP sul pacchetto e l’istante di transito

All’inizio non vi erano protocolli ausiliari come DNS. Si pensava che numerose opzioni diverse potessero aiutare nello smistamento.

• 255 opzioni possibili
• solo una decina veramente implementate

Source routing contiene una lista di indirizzi IP da cui il pacchetto deve (strict) o può (loose) passare. Questo può forzare un percorso alternativo, p.es. tramite uno hacker.

I sistemi operativi moderni non usano il source routing.

In generale le opzioni IP sono deprecate:

• Firewall che scarta tutti i pacchetti che contengono opzioni
• Ma molti router fanno transitare pacchetti con opzioni

Problemi di Sicurezza di IP

• Tutti i campi possono essere scritti da un programma
  • Packet crafting
  • Possono essere invalidi e causare problemi: pacchetti maeziani
• I campi non sono autenticati
  • Fidarsi o no
  • L'indirizzo mittente può essere falso: spoofing
• Alcuni campi non sono in uso
  • Si possono usare per informazioni coperte
  • Se non sono vuoti e il valore dipebde dal sistema operativo sono usati nel passive fingerprinting

Packet Crafting

I protocolli TCP/IP sono scritti in C

• Chiunque puà scrivere programmi o usare strumenti che scrivono pacchetti (packet crafting) -- esempio hping3
• Il ricevente non sa se il pacchetto è genuino o generato

Motivi:

• Canali di comunicazione stealth
• Attacchi diDenial of Service

Marziani:

• Pacchetti crafted con campi errati o assurdi che possono indurre il programma ricevente a compiere operaziomi pericolose
  • Esempio: header length = 3 (Windows NT pre Service Pack 3 si piantava)
  • Tutti i sistemi operativi controllano se i paccheti sono marziani, li loggano e li scartano
  • Ma l'inventiva degli hacker è grande

Passive Fingerprinting

Ispezionare un pacchetto in transito può dare un idea del sistema operativo del mittente

• Valore TTL iniziale
• Se la sonda è un ping o UDP
• Payload del ping
• Valore del campo ToS
• Numero dei pings inviati
  • Windows: 4, Linux: infiniti
• Opzioni e il loro valore

Nè il mittente nè il destinatario si accorgono che il pacchetto è stato ispezionato in transito

Canali Stealth

Comunicazione fuori banda in campi non usati

Esempio: un'opzione che non esiste

• Inviare un pacchetto con l'opzione p.es.. 0x42 (non esiste)
• bbiamo 38 byte di payload stealth

Principio d Umiltà dei router:

• "Se non riconosco un'ozione, puà darsi che l'abbiano inventata di recente". Il pacchetto passa.

Sicurezza più forte:

• Se un'opzione non è riconosciuta il pacchetto è scartato

Canali stealth più difficili da riconoscere:

• Uso del campo ToS
• Uso dei bit alti del campo TTL (default 32 o 64)

I canali stealth possono permettere ad uno hacker remoto di controllare il computer compromesso

Il programma malefico sul computer compromesso è stato probabilmente installato dall'utente stesso tramite tecniche di Ingegneria Sociale

Circuit Level Gateway

Transport Layer.

Contrasta i marziano e i canali stealth:

• Estrae il payload del pacchetto IP in arrivo
• Scarta la testata originale
• Crea una nuova testata pulita e la antepone al payload originale
• Fa proseguire il pacchetto

Frammentazione di Pacchetti

La frammentazione è necessaria:

• Ogni link ha una MTU: Maximum Tranfer Unit - dimensione massima del pacchetto trasferito
• Se la dimensione del pacchetto è superiore alla MTU, il pacchetto è frammentato

Ciascun frammenyo:

• Ha lo stesso ID del pacchetto originario
• Ha un campo di offset: bytes dall'inizio del pacchetto originale
• IL campo MF (more fragments) è settato a 1 se non è l'ultimo frammento
• Viene smistato indipendentemente dagli altri frammenti
• Può seguire un percorso diverso
• Può essere frammentato ulteriormente

Solo il ricevente è in grado di ricomporre i pacchetti frammentati

• Se dopo un timeot qualche frammento ancora manca, l'intero pacchetto viene scartato

Flag DF

Path MTU

Il mittente intende inviare un pacchetto di dimensione inferiore alla MTU più piccola dell'intero percorso.

I pacchetti non devono essere frammentati.

Il mittente invia un pacchetto di una certa dimensione iniziale con DF=1.

Se riceve un messaggio ICMP di errore:

• dimezza la dimensione del pacchetto
• lo rinvia con DF=1

Se la destinazione conferma la ricezione del pacchetto:

• Il mittente conosce la MTU minima
• PMTU: Path Maximum Transfer Unit
• Tutti gli altri pacchetti avranno questa dimensione

Non funziona sempre (quasi sempre): le condizioni di routing della rete variano nel tempo

Attacchi a Frammentazione

Ping of Death

Attacco Teardrop

Problemy con il Source Address

32 bits - non esiste la maschera

La maschera è un concetto di routing, non una proprietà del pacchetto

Non vi è alcuna assicurazione che il pacchetto provenga veramente dall'indirizzo mittente specificato.

Se l'indirizzo sorgente è falso, è un caso di spoofing (packet forgery), e quasi certamente un attacco hacker.

Spoofing

L'indirizzo IP sorgente è falso:

• nascondere l'identità del mittente vero
• impersonare un terzo, che spesso ha relazioni di fiducia col destinatario

Alcuni servizi compiono autenticazione solo sulla base del Source Address

Ottenere informazioni riservate è più complessp e necessita una modifica del routing, p.es. con falsi messaggi di Route Update messages o col Source Routing

Protocolli Ausiliari

ICMP

Internet Control Message Protocol

Protocollo ausiliario ma obbligatorio

Messaggi in datagrammi IP - su Socket Raw

Compiti:

• Feedback per problemi di recapito
• Incrementare l'efficienza globale di rete

Utilizzato in molti attacchi hacker

• Molti messaggi ICMP sono di solito disabilitati
• Alcuni messaggi ICMP sono ormai obsoleti
• Altri metodi per ottenere gli stessi servizi
• Riflettono l'entusiasmo iniziale per lo sviluppo della rete

Formato Messaggi ICMP

Identificativi Messaggi ICMP

Vari tipi di messaggi ICMP, identificati dallo ICMP message type

ICMP Source Quench

Uno hacker può causare il rallentamento del traffico fin quasi a zero (Diniego di Servizio)

ICMP Redirect

Uno hacker può modificare il percorso dei pacchetti, quindi leggerli o modificarli (Man in the Middle - MITM)

ICMP Echo Request/Reply

• Il firewall fa passare i ping in uscita e i pong in ingresso
• Il traffico è sbilanciato
• Il contenuto dei datagrammi non è ispezionato

Può essere un canale di comunicazione stealth (subdolo)

Trasferimento file su ICMP

Il controller remoto che ha infettato una macchina locale deve poter comunicare con essa, per esempio per trasferire files di materiale confidenziale.

Spesso il ping ha il permesso di transito dal firewall. Questo corrisponde ai tipi ICMP (Internet Control Message Protocol):

• 8 - Echo Request (“ping”)
• 0 - Echo Reply (“pong”)

Purtroppo il payload del ping arriva a 64 Kbyte. Usandone 500 per pacchetto per non causare sospetti si può comunque trasferire un file.

Occorre avere nella rete un Intrusion Detection System ben calibrato.

Uso di hping3

Lato server (hacker):

hping3 192.168.10.66 --listen signature --safe --icmp

• Output su standard output

Lato client (complice oltre il firewall):

hping3 192.168.10.44 --icmp –icmptype 8 -d 100 \
  --sign signature --file /etc/passwd --safe

• -d dimensione del corpo del pacchetto
• --listen signature accetta solo i pacchetti firmati 'signature'
• --sign signature invia oacchetti firmati 'signature' (La firma è una stringa all'inizio del corpo del pacchetto)
• --file nome del file trasferito
• --safe ritrasmissione dei pacchetti persi

Attacco Smurf

Distributed Denial of Service

Problema Generico di ICMP

Non vi è garanzia che il mittente sia vero.

Il primo ICMP ricevuto è considerato valido.

Ma ignorare gli ICMP può rallentare le operazioni.

• Destination Unreachable
  • Il mittente continua a provare e attende un timeout prima di arrendersi
• Time To Live Exceeded
  • Il mittente continua a inviare pacchetti, li perde poichè è un possibile loop di routing, e continua ad intasare la rete
• Source Quench
  • La perdita di pacchetti genera ritrasmissioni ed ulteriore intasamento

Man In The Middle

Man On The Side

Un nodo non sa se riceverà responsi duplicati.

Il comportamento è:

• accetta il primo responso
• ignora eventuali altri

Il mezzo trasmissivo è broadcast (es. WiFi).

K non può impedire che il server risponda, ma può rispondere per primo.

Address Resolution Protocol

Esempio:

• Richiesta: Qual’è l’indirizzo MAC corrispondente ad IP=161.27.112.34 ? (who-has)
• Responso: L’indirizzo è 00:0A:F2:54:15:A1 (is-at)

ARP Cache Poisoning

• ARP pone il risultato ottenuto in una cache
  • Durata: 2 minuti
• Malware può fornire un falso messaggio di responso ARP
  • MAC di un altro nodo di rete
  • MAC inesistente
• Se anche il nodo vero risponde il richiedente tiene il primo responso che riceve
• Soluzione: tabella /etc/ethers

In generale mai affidare la sicurezza sull’indirizzo MAC

Linux lo può cambiare: macchanger

Analisi di Protocollo

Per comprendere bene il funzionamento dei protocolli abbiamo bisogno di un Analizzatore di Protocollo.

Tale strumento cattura i pacchetti che transitano sulla rete corrente aprendo la scgeda di rete in Modalità Promiscua. Questo richiede i permessi di root.

In modalità promiscua vengono catturati tutti i pacchetti sentiti, non solo quelli destinati alla scheda di rete corrente.

In contenitori Docker l'utente root non ha tutte le capabilities, per esempio non ha il permesso di usare la modalità promiscua. Per abilitare tutti i permessi di un contenitore Docker, occorre lanciarlo con l'0pzione --privileged.

In altre parole un analizzatore di protocollo non è altro che uno Sniffer glorificato.

Lo analizzatore di protocollo permette quindi l'ispezione del pacchetto e aiuta nella comprensione dei vari campi del pacchetto. Se è uno strumento grafico l'interazione è più facilmente comprensibile.

Spesso gli analizzatori in grafica permettono un drilldown: andare ad un livello più dettagliato nell'esame di proprietà del pacchetto.

Tcpdump

Analizzatore di traffico da linea di comando.

Più veloce dei prodotti grafici.

Basato sulla libreria pcap (Promiscuous Capabilities) - necessita permessi di root.

• Potente linguaggio di filtro simile al linguaggio C
• Standard de facto per i linguaggi filtro
• Si può salvare ad un file e analizzare in seguito
• Disponibile per Unix e Windows

Sintassi:

tcpdump -i interfaccia [ opzioni ] [ filtro ]

Alcune opzioni:

• -w | -r file - scrive in | legge da file
• -v -vv -vvv - verbosità a vari livelli
• -x -xx -X - anche il contenuto in hex

Esempi

Le opzioni sono decine. Queste sono le più importanti.

Cattura pacchetti da interfaccia specifica:

tcpdump -i eth0

Cattura numero limitato di pacchetti:

tcpdump -c 5 -i eth0

Stampa i pacchetti in ASCII:

tcpdump -A -i eth0

Stampa i pacchetti in Hex e ASCII:

tcpdump -XX -i eth0

Mostra le interfacce disponibili:

tcpdump -D

Salva i pacchetti in un file:

tcpdump -w 0001.pcap -i eth0

Leggi i pacchetti da un file:

tcpdump -r 0001.pcap

Non risolvere nomi con DNS:

tcpdump -n -i eth0

Cattura solo il protocollo TCP:

tcpdump -i eth0 tcp

Cattura da una porta specifica:

tcpdump -i eth0 port 22

Cattura da sorgente specifica:

tcpdump -i eth0 src 192.168.20.151

Cattura pacchetti a destinazione specifica:

tcpdump -i eth0 dst 10.10.10.10

Filtraggio Pacchetti

Il linguaggio di filtraggio pacchetti basato su pcap è complesso e potente.

Vi è solitamente sulla rete una grande quantità di traffico, molto del quale di nessun interesse. Vogliamo catturare solo il traffico che ci interessa sviluppando un filtro adeguato.

Se l'espressione del filtro è complessa può essere scritta in un file e passata al tcpdump con l'opzione -F. Esempio:

tcpdump -F file-filtro

Se non vi è un filtro, tcpdump cattura tutti i pacchetti.

Wireshark

Wireshsrk è un analizzatore di protocollo grafico, disponibile sia per Linux che per Windows, dalle grandi possibilità.

E' in pratica un'interfaccia grafica alla cattura pacchetti basata su un sottostante tcpdump.

Permette anche l'analisi di pacchetti già catturati in un file. Se il file è lo standard input consente di analizzare pacchetti catturati da un tcpdump o altro analizzatore separato.

Installazione di Wireshark

In Linux è solitamente disponibile nei repositories di distribuzione. Per esempio in Ubuntu o simili, viene installato con:

sudo apt update
sudo apt install-qt

Wireshark è costruito con l'interfaccia grafica QT delle librerie del desktop manager KDE. Ha molti pacchetti di dipendenza, quando il desktop manager in uso è Gnome.

Lancio di Wireshark

Occorrono i permessi di root. Non basta un semplice sudo wireshark, poichè il tool lancia anche dei processi figli di cattura e questi non avrebbero i permessi di root.

Con solo:

sudo wireshark

la cattura pacchetti può solo essere fornita da un analizzatore esterno.

Per una cattura pacchetti locale è necessario procedere come segue:

su
wireshark

Selezionare l'interfaccia di cattura pacchetti tra quelle automaticamente sentite sullo host corrente.

Poi procedere col menù Capture -> Start. Si apre la finestra di cattura pacchetti.

Nel riquadro superiore è la lista di pacchetti catturati. Nel riquadro inferiore i dettagli del pacchetto in evidenza.

E' possibile un drilldown a vari livelli.

Esempio di Wireshark in Docker

02net1-ccli-chttp

Una rete, client e server HTTP.

Collegamento a server HTTP dal browser dello host.

Scaffolding

Creare la directory di progetto:

cd ~/ex
mkdir -p 02net1-ccli-chttp
cd 02net1-ccli-chttp

Preparare lo scaffolding:

mkdir ccli chttp
touch ccli/Dockerfile docker-compose.yml

Il risultato è:

tree

.
├── ccli
│   └── Dockerfile
├── chttp
└── docker-compose.yml

Il file ccli/Dockerfile è lo stesso di un esercizio precedente:

cp ../01net1-ccli-cssh/ccli/Dockerfile ccli

Il server HTTP userà un’immagine dal Docker Hub, non vi sarà bisogno di costruirne una.

docker-compose.yml

vim docker-compose.yml

version: '3.6'

services:
  one:
    build: ccli
    image: ccli
    container_name: one
    hostname: one
    cap_add:
      - ALL
    networks:
      net1:
        ipv4_address: 192.168.101.11
  two:
    image: httpd:2.4-alpine
    container_name: two
    hostname: two
    cap_add:
      - ALL
    ports:
      - 8888:80
    networks:
      net1:
        ipv4_address: 192.168.101.12
networks:
  net1:
    name: net1
    ipam:
      driver: default
      config:
        - subnet: 192.168.101.0/24

NOTA

Il progetto è disponibile come file tar al link 02net1-ccli-chttp.tar

Lancio

Partenza del progetto:

docker compose up -d

Aprire un browser sulla macchina virtuale.

Collegarsi a http://localhost:8888 e verificare.

Terminare il progetto:

docker compose down

Cooperazione tra Host e Container

Una rete, client e server HTTP.

Da tcpdump di un container a Wireshark sullo host.

Installare Wireshark sulla macchina host:

sudo apt install wireshark-qt

Richiede tempo.

Far partire il progetto:

docker compose up -d

Dalla macchina host:

Lanciare Wireshark che si collega al tcpdump del container one

sudo wireshark -i <(docker exec one tcpdump -i eth0)

Qualsiasi interfaccia vethxxx va bene.

Su one:

Aprire un terminale.

Collegarsi al server HTTP con curl:

curl -v http://two

Monitorare il traffico su Wireshark.

Terminare il progetto:

docker compose down

Protocolli di Trasporto

Socket

Un socket normale è un terminatore di rete elettrica.

• Quando si inserisce un plug ne esce corrente
• Si ignorano i dettagli della rete elettrica
• Vi sono più tipi di prese e spine

Un socket di rete è un terminatore di rete dati.

• Quando ci si collega fluiscono i dati
• Si ignorano i dettagli della rete dati
• Vi sono più tipi di socket di rete

Vi sono due prncipali tipi di socket.

Socket UNIX (in Windows: Socket Local):

• Per IPC (Inter Process Communication) tra processi locali
• Simile ad una pipe, ma può essere asincrono
• Implementato da un file speciale a file system e da un buffer nel kernel
• Molto usato in Linux

Socket Inet:

• Per comunicazioni con i protocolli TCP/IP
• Implementato tramite un record (struct sockaddr) che contiene i parametri di comunicazione

Vi sono moltissimi altri tipi di socket, per altre cataste di protocolli

Visualizzare tutti i socket in uso:

netstat -an

System Call socket

Chiamata di sistema per avere un socket:

int s;
s=socket(int domain, int type, int protocol);

• domain - Addressing Format - formato indirizzi
  • AF_UNIX - un parametro: nome file
  • AF_INET - struct con 4 parametri
    • IP sorgente
    • IP destinazione
    • Porta sorgente
    • Porta destinazione
• type - tipo di servizio richiesto - per AF_INET:
  • SOCK_STREAM - trasporto TCP
  • SOCK_DGRAM - trasporto UDP
  • SOCK_RAW - nessun trasporto (p.es. ICMP)
• protocol - protocollo internetworking da /etc/protocols
  • 0 - IP

Funzioni per socket

Dopo l’apertura del socket s sono disponibili le funzioni (alcune):

• int bind(int s, const struct sockaddr *addr, socklen_t addrlen);
  • associa un indirizzo ad un socket (server)
  • serve a settare la porta (p.es.80 per HTTP)
• int listen(int s, int backlog);
  • ascolta passivamente su un socket (server)
  • backlog è la lunghezza di una coda (tipicamente 5)
• int accept(int s, struct sockaddr *addr, socklen_t *addrlen);
  • gestisce la richiesta di connessione (TCP, server)
• int connect(int s, const struct sockaddr *addr, socklen_t addrlen);
  • richiede una connessione (TCP, client)
• ssize_t read(int s, void *buf, size_t count);
  • legge dal socket in un buffer (TCP)
• ssize_t write(int s, const void *buf, size_t count);
  • scrive dal buffer ad un socket (TCP)
• ssize_t sendto(int s, const void *buf, size_t len, int flags, const struct sockaddr *dest_addr, socklen_t addrlen);
  • invia un buffer ad un indirizzo di destinazione (UDP)
• ssize_t recvfrom(int s, void *buf, size_t len, int flags, struct sockaddr *src_addr, socklen_t *addrlen);
  • riceve in un buffer da un indirizzo sorgente (UDP)
• int close(int s);
  • chiude il socket

Schema di connessione

Prima parte il server, poi il client.

Più clients: wait

Un secondo client trova il server occupato e viene posto in coda.

Più clients: nowait

Non è il server si ascolto, ma quello di servizio a gestire la connessione.

Port multiplexing

Un server di ascolto può gestire più porte.

TCP

Testata TCP

• Porta sorgente
  • Assegnata (pseudo)casualmente dal client
• Porta destinazione
  • Ben nota sul server (/etc/services) - argomento di bind()
• Numero di sequenza
  • Inizia da un numero casuale
  • Aumentato del numero di bytes inviati
• Numero di conferma
  • Indica l’ultimo numero di sequenza ricevuto correttamente
• Dimensione della finestra
  • Quanti bytes sono inviati prima che si attenda conferma
• Flags TCP
  • U - URG - Urgent
    • Il campo urgent contiene un valore valido
    • All’inizio del payload vi sono dati urgenti (fuori banda)
    • Offset dall’inizio di dati non più urgenti
  • A - ACK - Acknowledge
    • Il campo acknowledgment contiene un dato valido
  • P - PSH - Push
    • Push - non bufferizzare i dati, ma inviare subito
  • R - RST - Reset *Errore generico: pacchetto invalido per lo stato corrente
  • S - SYN
    • Inizio della connessione
  • F - FIN *Chiusura: non trasmetterò altri dati

TCP Handshake

• NSC - Numero di sequenza del client
• NSS - Numero di sequenza del server
• NAC - Numero di acknowledgement del client
• NAS - Numero di acknowledgement del server

Stealth Scan

Impersonazioni

Tipi di Trasferimento

Trasferimento Mass Transfer

Viene inviata una finestra di molti pacchetti.

• Il campo Sequence indica l’ultimo byte inviato
• Il campo di Acknowledgment indica l’ultimo byte ricevuto correttamente
• Simultaneamente si invia la propria finestra
• Le dimensioni delle finestre possono essere diverse
• La dimensione è negoziata dalle opzioni

Mass Transfer è usato quando serve un grosso Throughput, per esempio nei file transfer.

Slow Start

La finestra iniziale è piccola.

• Viene aumentata progressivamente col tempo
• Fino a finestra massima accettabile dall’altro
• In caso di troppi errori la dimensione della finestra è dimezzata

La dimensione iniziale varia da sistema operativo

• Windows: 2 pacchetti
• Altri: 1 pacchetto

Recupero errori

Go-Back-N

Viene richiesta la ritrasmissione dall'ultimo byte ricevuto correttamente.

Questa era la modalità di recupero della versione originale di TCP.

Selective Retransmission

Molto più complessa e richiede bufferizzazione da parte del ricevente.

Viene richiesta la ritrasmissione solo di un range di byte ricevuti male, anche intermedio.

Trasferimento Interactive

Il flag Push indica di non raccogliere i dati ricevuti in un buffer ma di passarli subito all’applicativo.

E’ possibile che l’altro flusso non sia Push, ma è improbabile.

Mass Transfer e Interactive interferiscono tra loro sullo stesso canale trasmissivo: è difficile avere Interactive quando vi è una grossa quantità di byte in transito col metodo Mass Transfer.

Interactive è usato quando serve una bassa latenza, per esempio con programmi per terminale remoto.

Porte TCP Interessanti

Tutte le porte dei servizi ben noti, assegnate dallo IANA, sono configurate in Linux nel file /etc/services,

Strumenti TCP

netcat

nc [opzioni] [hostname] [porte]

Il coltellino svizzero delle utilities di rete. Capace di:

• Aprire connessioni TCP
• Ascoltare su porte TCP e UDP
• Inviare datagrammi UDP
• Eseguire scansioni di porte
• Gestire IPv4 ed IPv6

Il client legge da standard input, il server scrive a standard output

Genera errori su standard error

Esempi d'uso

Porta locale, 5 secondi di timeout connessione:

nc -p 31337 -w 5 host.example.com 42

Usa protocollo UDP:

nc -u host.example.com 53

Spoofing dell'idirizzo sorgente:

nc -s 10.1.2.3 host.example.com 42

Ascolta su socket Unix:

nc -lU /var/tmp/dsocket

Proxy HTTPS e utente indicato:

nc -x10.2.3.4:8080 -Xconnect -Pruser host.example.com 42

Scansione porte:

nc -z host.example.com 20-30

Packet Crafting con hping3

Autore: Salvatore Sanfilippo.

Costruzione di pacchetti con riempimento dei campi.

Invia un pacchetto con flag SYN alla porta 80:

hping3 -I eth0 -S 192.168.10.1 -p 80

Opzioni per flag:

-F FIN		-R RST	 	-S SYN
-P PUSH		-A ACK		-U URG 
-X Xmas(1st unused)		-Y Ymas(2nd unused)

Scansione dalla porta 79 in poi:

hping3 -I eth0 -S 192.168.10.1 -p ++79

Ritorna flags=SA per porta aperta e flags=RA per porta chiusa

Altre opzioni:

• -s --baseport - porta sorgente base (default random) – incrementata di 1 ad ogni invio
• -p --destport[+][+]<port> - porta destinazione (default 0)
• -k --keep - mantiene porta sorgente
• -w --win - dimensione finestra (default 64)
• -O --tcpoff - offset dati (invece di tcphdrlen / 4)
• -Q --seqnum - mostra solo il numero di sequenza
• -b --badcksum - invia checksum sbagliato (non sempre funziona)
• -M --setseq - setta il numero di sequenza TCP
• -L --setack - setta il numero di acknoledge TCP

Idle Scan

Richiede una macchina Zombie con sequenza prevedibile di generazione di ID di pacchetto.

• P.es. Windows, Stampanti

Testare uno Zombie:

hping3 -I eth0 -SA 192.168.10.1

Se lo id incrementa di 1 va bene

Scansione. Finestra 1 con intervallo di 5 secondi:

hping3 -I eth0 -i 5 -a 192.168.10.1 -S 192.168.10.33 -p ++20

Finestra 2:

hping3 -I eth0 -r -S 192.168.10.1 -p 2000

-r display degli incrementi, non degli id interi; se +1: porta server chiusa, se +2: porta server aperta

Attacco SYN

Acquisizione Informazioni

Fingerprinting

Determinare il sistema operativo dei target. A volte anche versioni e implementazioni specifiche.

• Fingerprinting attivo
  • Invia stimoli e riceve responsi
  • Comportamento target allo stimolo con pacchetti errati
  • Database di responsi possibili
• Fingerprinting passivo
  • Ispezionare i dettagli interni dei pacchetti ricevuti
  • Campi inutilizzati delle testate TCP/IP
  • Presenza e tipo di opzioni
  • Uso dei flag TCP - Push, Urgent, Fin *Frequenza di vari tipi di traffico

Scanning

Fondamento dello Intelligence Gathering Attivo.

Enumerazione di:

• Indirizzi IP
• Nomi host
• Porte e servizi
• Sistemi operativi
• Numeri di sequenza IP
• Vulnerabilità palesi

Può essere più o meno rumoroso o Stealth:

• Il sistema operativo target non compie il logging delle sonde di scansione
• Lo Intrusion Detection System di rete non nota anomalie di traffico, per composizione o frequnze

nmap

Gordon “Fyodor” Lyon, dal 1997.

nmap [tipi] [opzioni] target

Opzioni:

• -g - porta sorgente
• --spoof-mac - MAC sorgente falso
• -S - indirizzo sorgente
• -e - seleziona interfaccia ethernet
• -F - fast scan alle 100 porte più importanti
• -p - specifica range di porte
• -R - forza il reverse lookup
• -N - risoluzione DNS
• -n - disabilita risoluzione DNS
• -O - informazioni sul sistema operativo
• -h - help
• -6 - abilita IPv6
• -A - aggressivo – usare con cautela
• -T(0-5) - livello di aggressività
• --scan_delay - aggiunge un ritardo tra le sonde
• -sV - sonda le versioni del software
• -P0 - disabilita il ping della vittima
• -A- compie un traceroute
• --max_hostgroup - limita il numero delle vittime scandite simultaneamente
• --max_retries . setta il numero di tentativi aggiuntivi di contatto porte
• --max_parallelism - setta il numero massimo di sonde in parallelo

Tipi di scansioni

• -sA - ACK
• -sP - ping
• -sS - SYN – scansione half open
• -sT - connessione TCP completa
• -sU - UDP
• -sX - XMAS – buono per i sistemi Unix
• -sL - list scan – lista gli indirizzi IP
• -sO - protocolli supportati dalle vittime
• -sM - FIN/ACK – buono per i sistemi Unix
• -sI - idle scan – usa zombie
• -sW - scan della finestra TCP dei pacchetti RST

Tipi di output:

• -oA - tutti
• -oG - che può essere usato con grep
• -oX - XML
• -oN - normale

Esempi di nmap

nmap -A 10.10.10.2

• Rileva porte e informazioni sulla vittima. Compie un traceroute.
• Provare con firewall e senza

nmap -P0 -n -sS --max_hostgroup 1 --max_retries 0 --max_parallelism 10 10.10.10.0/24 | grep -v Warning

• Scan stealth di un'intera rete con accorgimenti per basso carico e intrusività
• Il grep toglie i messaggi di Warning per eccesso di retries su vittime non esistenti

nmap-D10.10.10.18,10.10.10.27,10.10.10.44,ME -p 80,21,22,25,443 -Pn 10.10.10.3

• Uso di Decoys: randomizza l'indirizzo sorgente tra gli indirizzi indicati dall'opzione -D

Esempio di Strumenti TCP

net1-util-metasploitable

Viene preparata una rete Docker con due contenitori:

• one - un client derivato da Alpine con qualche utility extra, incluso hping3 ed nmap
• two - un'istanza di Metasploitable versione 2, con numerose vulnerabilità

Preparazione dello scaffolding:

mkdir -p ~/ex/net1-util-metasploitable
cd ~/ex/net1-util-metasploitable
mkdir meta util
touch util Dockerfile docker-compose.yml
tree

.
├── docker-compose.yml
├── meta
└── util
    └── Dockerfile

Il Dockerfile del client è:

vim util/Dockerfile

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

RUN echo "http://dl-cdn.alpinelinux.org/alpine/edge/testing" >> /etc/apk/repositories
RUN apk update --allow-untrusted
RUN apk add --no-cache --allow-untrusted openssh tcpdump curl hping3 nmap

CMD ["/bin/sleep","1000000"]

• Aggiungiamo il repository http://dl-cdn.alpinelinux.org/alpine/edge/testing alla lista dei repositories
  • E' qui che si trova hping3
• Compiamo l'update del software
• Installiamo i pacchetti

L'opzione --allow-untrusted è necessaria perchè il nuovo repository non ha pacchetti firmati.

Prepariamo quindi il docker-compose.yml.

vim docker-compose.yml

version: '3.6'

services:
  one:
    build: util
    image: util
    container_name: one
    hostname: one
    cap_add:
      - ALL
    networks:
      net1:
        ipv4_address: 192.168.101.11
  two:
    image: tleemcjr/metasploitable2
    container_name: two
    hostname: two
    cap_add:
      - ALL
    tty: true
    networks:
      net1:
        ipv4_address: 192.168.101.12
networks:
  net1:
    name: net1
    ipam:
      driver: default
      config:
        - subnet: 192.168.101.0/24

Note:

• Verrà costruita la nuova immagine util:latest se non esiste.
• L'immagine di Metasploitable, tleemcjr/metasploitable2 verrà scaricata dalla rete.
• Il contenitore di Metasploitable passerà qualche minuto a generare tutta una serie di servizi, per ciascuno generando dei messaggi a /dev/console. Il parametro tty: true genera /dev/console.

NOTA

L'esercizio è disponibile in formato tar al link net1-util-metasploitable.tar

Esecuzione dell'Esercizio

Lanciamo il progetto con:

docker compose up -d

Monitoriamo il progresso con:

docker logs -f two

finchè si ferma. Quindi Ctrl-C.

Apriamo un terminale one. Diamo il comando:

nmap two

Il risultato è simile a:

Starting Nmap 7.60 ( https://nmap.org ) at 2024-02-22 19:24 UTC
Nmap scan report for two (192.168.101.12)
Host is up (0.000036s latency).
rDNS record for 192.168.101.12: two.net1
Not shown: 979 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
23/tcp   open  telnet
25/tcp   open  smtp
80/tcp   open  http
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
512/tcp  open  exec
513/tcp  open  login
514/tcp  open  shell
1099/tcp open  rmiregistry
1524/tcp open  ingreslock
2121/tcp open  ccproxy-ftp
3306/tcp open  mysql
5432/tcp open  postgresql
5900/tcp open  vnc
6000/tcp open  X11
6667/tcp open  irc
8009/tcp open  ajp13
8180/tcp open  unknown
MAC Address: 02:42:C0:A8:65:0C (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 3.11 seconds

Al termine fermiamo e smantelliamo il progetto con:

docker compose down

UDP

UDP è non affidabile (volutamente): non vi è garanzia che i datagrammi arrivino a destinazione.

Port numbers identificano i processi mittente e destinatario.

UDP viene principalmente usato in tre casi:

• il payload è piccolo - non conviene l'esecuzione di uno hanshake a tre vie per poi trasferire pochi dati
• l'invio di dati è casuale, non prevedibile e stateless
• vengono inviate vaste quantità di dati ma è accettabile una perdita parziale del traffico
  • un essere umano che guarda un film in streaming
  • il degrado potenziale dipende dalla codifica dei dati

Molti servizi che una volta usavano UDP, p.es. DNS, sono stati ora reimplementati su TCP, che offre maggiori caratteristiche di affidabilità al costo di un piccolo overhead.

Formato Datagramma UDP

Porte UDP Interessanti

Attacchi a UDP

Remote Administration Trojans

Impiantare 'server' su computer o rete vittima

• Metodi di ingegneria sociale

Collegarsi al server della vittima con un client remoto

• Acquisire poteri amministrativi
• Visualizzare e modificare files, dischi, registry
• Installare sniffer ed altro malware

I RAT possono essere sofisticati

• Manifestano attivamente la loro presenza - beaconing
• Usano tecniche di port hopping
• Incapsulamento del traffico in protocolli permessi dal firewall

Back Orifice – esempio storico

Applicativo Client/Server: Il client ottiene il controllo pieno del server.

• lancio e controlla applicazioni
• gestione di directory e file
• gestione di connessioni di rete e share
• compressione e decompressione
• manipolare il server HTTP
• keystroke log
• screen capture
• generare segnali acustici
• gestione processi
• redirezione di porte
• gestione del registry
• recupero password dalla cache di memoria
• lockup or reboot del server
• inviare e ricevere file TCP

La versione originale usa di default la porta UDP 31337 (ELEET)

Usa crittografazione (semplice XOR, plugin più potenti sono disponibili)

Comunicazioni Nascoste

I computer infetti P delle varie reti (powned) sono gestiti dal Command & Control Centre (CCC).

Nello stabilire il canale si notano due tipi di attività:

• Trolling
  • Il CCC cerca i P delle varie reti
• Beaconing
  • Il P cerca il CCC
  • Detto anche “telefono casa”

Occorre impedire qualsiasi contatto dei computer interni con l’esterno che non sia mediato da Proxy e monitorato.

Livelli Utente

I protocolli dello strato Applications del modello DoD girano nello spazio utente di Unix/Linux.

Richiedono i servizi di rete TCP/IP sottostanti tramite l'accesso ad un Socket Inet.

I servizi sono innumerevoli, ma si possono identificare quattro categorie principali, storicamente evolute da un servizio capostipite.

Telnet:

Il primo scopo della rete ARPAnet era di permettere l'accesso e l'uso di supercomputer (per quei tempi) da remoto. Il primo programma in tal senso è stato Telnet. (circa 1971)

Telnet ha introdotto il convetto di Network Virtual Terminal e ha riprodotto in gran parte il comportamento di un terminale locale di allora, ma in rete.

FTP:

I file di output prodotti su computer remoto rimanevano sfortunatamente su tale computer. Per trasferirli al computer locale è stato inventato il protocollo FTP - File Transfer Protocol. (circa 1972)

FTP ha introdotto un concetto importante: la differenziazione tra un canale comandi, su cui istruire il computer remoto, e un canale dati, su cui compiere il trasferimento file

FTP è un protocollo a dir poco bizantino, e ha causato numerosi problemi corretti in seguito da programmi di file transfer migliorati.

SMTP:

Un'attività frequente degli umani era di interscambiarsi files a contenuto informale, anzichè lavorativo.

Nonostante la contrarietà iniziale del management della rete, quest'attività si è formalizzata nella possibilità di interscambio di messaggi di posta, col protocollo SNTP - *Simple Mail Transfer Protocol. (circa dal 1974)

SMTP ha soprattutto formalizzato la struttura di un messaggio, aggiungendo, prima del corpo del messaggio, una testata di metadati.

Ulteriori migliorie, non tecnicamente fattibili nell'immediato, sono arrivate con la possibilità di aggiungere allegati al messaggio.

E' da notare che la posta elettronica esisteva già prima di Internet, in ambiente Unix, e così pure i cosiddetti newsgroups - bacheca pubblica a sottoscrizione.

SMTP ha soltanto esteso la possibilità di interscambio posta elettronica dalle previe reti store-and-forward alla moderna commutazione di pacchetto.

La posta elettronica ha introdotto il concetto di indirizzo di posta (inizialmente per pochi fortunati), che è una vera identità digitale univoca in rete. Quindi ha incoraggiato una postura sociale e partecipativa all'uso della rete - tendenze anarchiche avversate dal management.

HTTP:

Abbiamo dovuto attendere circa il 1990 prima della vera rivoluzione democratica di Internet: il World Wide Web.

Il Prof. Tim Bernars-Lee del CERN di Ginevra ci ha dato un prodotto costituito da:

• un server per la distribuzione a richiesta di pagine Web
• il linguaggio di redazione delle Pagine Web: HTML - Hyper Text Markup Language
• la possibilità di collegare pagine ad altre pagine, anche su altri server, tramite degli Hyperlink
• un client per accedere al server, in realtà sviluppato più da altri che non dall'originatore iniziale
• il protocollo di comunicazione tra il client e il server: HTTP - Hyper Text Transfer Protocol

HTTP si è naturalmente molto evoluto, tecnicamente e socialmente, dagli albori, come tutto il mondo WWW.

Un'osservazione nostalgica. Così come non diciamo doppiavu-doppiavu-doppiavu, ma vu-vu-vu, anche in inglese c'è o c'era uno slang: dub-dub-dub. E la sigla http:// si pronunciava hitip.

HTTP ha una notevole importanza moderna come protocollo di accesso ad un servizio distribuito in rete, con tecnologie come Docker, Kubernetes, e altre simili.

Il server HTTP è diventato un punto di accesso e smistamento di richieste client ai vari componenti di un servizio distribuito, spesso a dei microservizi. A quale microservizio specifico è una route specificato da parte della stringa URL inviata al server.

I Verbi di HTTP (GET, HEAD, PUT, POST, ...) indicano azioni che il servizio deve compiere. I dati interscambiati col servizio di backend sono spesso in formato JSON - JavaScript Object Notation.

L'intera interfaccia è una API - Application Programming Interface e il metodo è detto REST - REpresentational State Transfer.

HTTP è quindi diventato un metodo standard di comunicazione per microservizi.

Telnet

Da hardware di terminale locale permette il collegamento ad una shell remota.

CLI terminal server.

RFC 854-855

Proprietà

• Nessuna differenza comportamentale umana tra una connessione di terminale locale e una da remoto tramite telnet
• L’echo dei caratteri è (quasi sempre) da remoto
  • Implicita conferma di ricezione
  • Potenziali problemi di latenza
• Usa TCP Interactive (Push)
• Caratteri di controllo di telnet inseriti nel traffico normale come sequenza di escape
• Il refresh del video impiega molto tempo
  • Adattati i programmi (es. “vi”) per compierlo poco
• L’autenticazione di accesso è la stessa
  • username e password

Problema

• Tutto il traffico è in chiaro
  • anche username e password

Terminali tradizionali

Network Virtual Terminal

Terminale generico standard e vendor independent:

• Un NVT ha tastiera e “printer” (display)
• La tastiera produce output, la printer riceve input
• Si usa la codifica US ASCII a 7 bit
• L’echo è remoto ma può essere locale

Sono supportati i caratteri speciali ASCII:

• NUL - no operation
• CR - carriage return
• LF - line feed
• BEL - segnale sonoro
• BS - backspace con cancellazione
• HT - horizontal tab (settabile in locale)
• VT - vertical tab (settabile in locale)
• FF - form feed (nuovo foglio o pulizia schermo

Controllo

Tre fasi:

• Negoziazione dei parametri e delle opzioni
• Interscambio caratteri tra utente e shell
• Terminazione di connessione

Telnet ha svariati caratteri di controllo fuori banda.

Sono inviati in negoziazione o durante la trasmissione, p.es. AYT (Are You There) - keepalive.

La terminazione può essere guidata

• da remoto: la shell ha terminato
• da locale
  • carattere di escape Ctrl-[
  • seguito da comando quit

FTP

Problemi di telnet:

I dati prodotti rimangono sul server remoto

• La stampa locale è lenta e non è rivedibile: necessità di download
• Lo entry manuale dei dati online è lento e costoso: necessità di upload

Principio della massima località di trattamento:

• I dati devono essere trasferiti dove è più conveniente (comodo, economico, ...) trattarli

Per questo è stato introdotto il File Transfer Protocol (FTP) - RFC 959

Proprietà

• I comandi su connessione di Controllo sono TCP Interactive
• I dati trasferiti su connessione Dati sono TCP Mass Transfer
• La connessione Dati è a rovescio
  • Con modalità Passive può essere normale
• Default ASCII 7 bit, possibile ASCII 8 bit (Binary)

SMTP

Posta Elettronica

Simple Mail Transfer Protocol (SMTP)

Derivato originariamente da FTP.

Trasferisce messaggi composti da:

• header - campi di testata (RFC 822)
• linea vuota separatrice
• body - corpo del messaggio

Il trasferimento è a 7 bit (US ASCII)

Ruoli:

• Mail Transfer Agent (MTA) - comunica con altri server tramite SMTP
• Mail Delivery Agent (MDA) - distribuisce i messaggi in arrivo alle caselle postali del server
  • vi sono diversi standard di struttura delle caselle postali
• Mail User Agent (MUA) - interagisce con l’utente e lo MDA, tramite protocolli di lettura posta

Organizzazione

Tutti i nodi di rete possono in teoria avere un server SMTP.

Se visibile ci si può connettere direttamente al server, p.es.:

nc 10.0.1.3 25

E’ un normale interscambio di messaggi con variante di protocollo determinata dal primo messaggio:

• di base - semplici, meno sicuri
  • HELO stormforce.ac
• avanzati - complessi, più sicuri, timeout breve
  • EHLO stormforce.ac
  • L’argomento indica il dominio di provenienza

Ostacoli:

• L’uso di URL di posta, p.es. mailto:john@stormforce.ac passa necessariamente dal DNS
  • viene contattato il Mail Exchanger (MX) del dominio
  • i firewall di solito bloccano l’accesso diretto

Porte:

• 25 - non crittografata
• 445 - crittografata

Encoding

Il traffico è a 7 bit per byte.

Traffico a 8 bit per byte deve essere trascodificato.

Due algoritmi:

• uuencode - antico e obsoleto
• Base64 - moderno e corrente

Più parti possono essere inserite nello stesso messaggio come allegati: testo, immagini, ecc.

Standard MIME - Multimedia Internet Mail Extensions. MIME usa Base64.

Protocolli di Consultazione Posta

POP - Post Office Protocol - Versione 3

• Il client scarica i messaggi dal server al client locale
• Può poi decidere se cancellare i messaggi dal server
• Porte
  • 110 - non crittografata
  • 995 - crittografata

IMAP - Internet Mail Access Protocol - Versione 4

• I messaggi sono mantenuti sul server remoto
• Accessibili da clients diversi
• Porte:
  • 143 - non crittografata
  • 993 - crittografata

HTTP

Messaggi HTTP

Simili a messaggi di posta elettronica.

• Testata + Corpo (corpo opzionale)
• Richieste
  • Testata ha tipo richiesta
• Responsi
  • Testata ha codice responso

Testata ha altri campi contestuali

Richieste

Richiesta GET

Richiesta HEAD

Richiesta PUT

Molti server non implementano la richiesta PUT: Problemi di Sicurezza

Server Side Includes

Considerati obsoleti.

Comandi inseriti nel testo HTML, scanditi ed eseguiti dal server prima dell’invio pagina:

• Inclusi in commenti e preceduti da ‘#’
• Il server deve tipicamente essere abilitato a scandire le pagine contenenti SSI
• Suffisso .shtml

Esempi:

La Specifica CGI

Common Gateway Interface

• Il client invia dati al server
  • Dati spesso generati da un FORM
• Il Server attiva un programma esterno
  • Il programma riceve in input i dati del client
  • Metodi GET e POST
• Il programma esegue
  • p.es. Query di Database
• Il programma genera in output una pagina HTML
• La pagina viene inviata al client

Il Metodo GET

Il Metodo POST

Esercizio Docker con HTTP

Va bene come base l'esercizio 01net1-ccli-cssh. Posizionarsi nella ditectory e far partire il progetto:

cd ~/ex/01net1-ccli-cssh
docker compose up -d

Collegarsi al contenitore two col terminale.

Installare il software necessario:

apk add apache2
apk add apache2-utils

Per partire, apache2 ha bisogno di scrivere il suo PID in una directory che al momento non esiste. Creiamola:

mkdir -p /run/apache2

E' opportuno anche dare un ServerName al servizio, Editiamo il file di configurazione di Apache2, cerchiamo il parametro e modifichiamolo:

vi /etc/apache2/httpd.conf

ServerName 192.168.101.12

Lanciamo il server:

httpd -k start

Verifichiamo la partenza con:

ps wax

Prroviamo la connessione dalla macchina host. Apriamo un browser a 192.168.101.12. Dovrebbe funzionare.

File di configurazione principale: /etc/apache2/httpd.conf

include i files di configurazione dalla directory: /etc/apache2/conf.d/*.conf

In particolare DocumentRoot : /var/www/localhost/htdocs

Directory ad Accesso Limitato

Nella DocumentRoot creare una directory restricted e una pagina HTML di prova:

cd /var/www/localhost/htdocs
mkdir restricted
cd restricted
vi index.html

<html>
 <head>
  <title>Club Privato</title>
 </head>
 <body bgcolor="white">
  <h1>Ciao</h1>
 </body>
</html>

Autenticazione Basic

Scrivere il file di limitazione accessi nella directory riservata:

vi .htaccess

AuthType        Basic
AuthName        "Restricted Access"
AuthUserFile    /etc/apache2/users

<Limit GET>
require valid-user
</Limit>

Modificare i permessi del file di configurazione globale /etc/apache2/httpd.conf

Nella sezione di protezione della directory corrispondente al DocumentRoot, da:

AllowOverride None

a

AllowOverride AuthConfig Limit

Generare il file dei permessi:

cd /etc/apache2
htpasswd -mc users pippo

Password:pluto
Repeat password:pluto

Restartare il server:

httpd -k restart

Analisi del Traffico

Chiudere il browser poi riaprirlo, poichè usa delle cache.

Aprire la cattura di traffico con dump ASCI con:

tcpdump -A

Aprire il browser e connettersi a http://192.168.101.12/restricted, dando l'utente pippo e la password pluto.

Controllare il traffico catturato da tcpdump. Troveremo:

GET /restricted/ HTTP/1.1
Host: 192.168.101.12
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:121.0) Gecko/20100101 Firefox/121.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
If-Modified-Since: Sat, 02 Mar 2024 20:13:15 GMT
If-None-Match: "70-612b31f6ae088"
Authorization: Basic cGlwcG86cGx1dG8=

La coppia nome:password viene inviata nella testata della richiesta http come stringa non crittografata, ma solo trasformata con l'algoritmo Base64.

Uno sniffer può intercettare la richiesta http e uno hacker la può decodificare, p.es.:

echo "cGlwcG86cGx1dG8K=" | base64 -d

pippo:pluto

Autenticazione Digest

E' un metodo challenge-response.

Non occorre inviare la password, basta dimostrare di saperla.

Scrivere il file di limitazione accessi nella directory riservata:

cd /var/www/localhost/htdocs/restricted
vi .htaccess

AuthType                Digest
AuthName                "club"
AuthDigestDomain        /restricted/ http://182.168-101-12/restricted/

AuthDigestProvider file
AuthUserFile /etc/apache2/secure   
 
<Limit GET>
require valid-user
</Limit>

Generare il file dei permessi:

cd /etc/apache2
htdigest -c secure club tizio

Adding password for user tizio in realm club.
New password:caio
Repeat password:caio

Nel file /etc/apache2/httpd.conf:

Togliere il commento alla linea

LoadModule auth_digest_module modules/mod_auth_digest.so

Restart del server corrente:

httpd -k restart

La cattura traffico è completamente differente:

GET /restricted/ HTTP/1.1
Host: 192.168.101.12
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:121.0) Gecko/20100101 Firefox/121.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Authorization: Digest username="tizio", realm="club", nonce="FBRN4bMSBgA=d74359083de5b800e832d25773dcbc555768d016", uri="/restricted/", algorithm=MD5, response="3a4fce5ee9163dd376b803e9cb4f8bbe", qop=auth, nc=00000001, cnonce="0e32602512c548ec"

La password non compare, nemmeno trascodificata.

Se vi sono errori, verificare il file di log /var/www/logs/error.log.

Risoluzione Nomi-Indirizzi e DNS

Origini del DNS

Originariamente la risoluzione hostname -> indirizzo IP era un unico file hosts gestito dal Network Information Center (NIC):

• ogni computer connesso ad Internet aveva il suo indirizzo IP esclusivo e hostname esclusivo
• si scaricava il file hosts da un repository centrale
• ancora oggi i dati contenuti in /etc/hosts sono prioritari rispetto ad altri ambienti di risoluzione N2A

Il Domain Name System introduce spazi nomi chiamati domini.

Gli hostname sono univoci in ciascun dominio.

Vi è un’autorità di dominio che mantiene i record.

Software Implementativo

Tre implementazioni del DNS:

• ChaosNet
  • MIT, esiste ancora ma è sempre stato un esercizio universitario, sigla CS
• Hesiod
  • Digital Equipment Corporation, ritirato, sigla HS
• Berkeley Internet Name Domain (BIND)
  • Università di Berkeley, su UNIX, sigla IN
  • Adottato da Microsoft, da Windows NT in poi
  • Le versioni vecchie sono insicure

Schema del DNS

Domain Name System - Implementazione: Berkeley Internet Name Domain (BIND)

Demone: named

Ruoli DNS:

• Resolver - solo client - /etc/resolv.conf
• Master server (master) - ha i files di configurazione di zona
• Slave server (slave) - copia i files di configurazione
• Hint server (hint) - mantiene cache dei responsi; normalmente combinato con Master o Slave server

Comportamento del DNS

Mappe e Resource Records

DNS mantiene due tipi di mappe:

• forward
  • da campo di input a campo di output, a seconda del tipo di risorsa richiesto
  • originariamente era solo da hostname a indirizzo IP
• reverse
  • da indirizzo IP a hostname
  • aveva senso solo quando esistevano le classi di indirizzamento

Una risorsa viene detta Resource Record.

Direttive (defaults):

$ORIGIN zona_di_origine
$TTL tempo_di_vita

Struttura records:

campo_in clas	TTL 	tipo [opz]		campo_out
zona			SOA			dettagli_zona
zona			NS			server_DNS
zona			MX priorità		server_mail
nome			A			indirizzo
nome_alias		CTYPE			nome_vero
indirizzo_rev		PTR			nome_FQDN

Esempio:

$TTL 1d
@		IN SOA zen.starshell.sh. root.zen.starshell.sh. (
 					2009121200	; serial
 					3h		; refresh
 					1h		; retry
 					1w		; expire
 					1d )		; minimum

 		IN NS		zen.starshell.sh.
 		IN MX 10	mail.starshell.sh.

zen		IN A		192.168.1.1
mail		IN CNAME	zen
air		IN A		192.168.1.4

Sicurezza di Rete

Situazione:

• Negli ultimi anni il panorama della Cybersecurity è cambiato drasticamente
• Non più solo virus, spam, diniego di accesso
• Ora si parla di frode, furto d’identità, dossieraggio, spionaggio, ricatto, cancellazione totale dei dati

Motivi:

• La società è dipendente da procedure ed operazioni on line e non è possibile un ritorno al passato
• La consapevolezza della sicurezza informatica è scarsa
• Il design di sicurezza è un costo aggiuntivo

Cos’è veramente la Sicurezza?

Deve essere una preoccupazione di tutti:

• E’ basata sulla cultura dell’organizzazione
• Protegge il materiale e gli interessi organizzativi
• E’ presente in ogni processo aziendale

Necessità:

• Renderla possibile
• Renderla semplice
• Evidenziare il progresso e i risultati

Modelli di Sicurezza

Si sono evoluti una serie di modelli per rappresentare le situazioni di cybersecurity, gli attaccanti coinvolti, la tipologia di operazioni, i danni causati.

Il più noto è il modello RID - Abbreviazione di Riservatezza, Integrità, Disponibilità.

Questo modello si concentra sugli attacchi ai dati e alla loro compromissione:

• Definisce tre tipi di motivi per gli attacchi
• Separa attacchi compiuti da gruppi e da individui

Modello RID: Attaccanti:

Un nuovo modello più consono alla situazione presente sii concentra sulle categorie degli attori non sui dati.

Vulnerabilità dei Protocolli e Attacchi

Vulnerabilità ed Esposizioni

Concetti di base della sicurezza informatica

Vulnerabilità:

• Errore del software che può essere direttamente usato da uno hacker per avere accesso a sistemi o reti
• Sia nei programmi che nei protocolli di rete
  • Non tutte sono state scoperte
  • Non tutte è possibile correggerle

Esposizione:

• Errore di configurazione o di utilizzo del software che permette l'accesso a informazioni o l'utilizzo di capacità tali da facilitare ad uno hacker l'accesso a sistemi o reti.
• Configurazioni di default o di esempio
• Mancata comprensione dei rischi

Vulnerabilità: OWASP Top 10

OWASP (www.owasp.org) - Open Web Application Security Project

Lista di vulnerabilità più comuni degli applicativi basati su Web:

• Evidenzia la moda corrente degli attacchi
• Aggiornato ogni qualche anno
• Non è completo

Rischio e Minacce

Tutti i protocolli TCP/IP contengono Vulnerabilità e il loro uso può coinvolgere in Esposizioni.

Le vulnerabilità vengono spesso tappate con opportuni patch al software. E' per questo che occorre compiere dei continui upgrade alla versione più recente del software.

Dalle esposizioni ci si può difendere solo parzialmente, con adeguata progettazione degli applicativi, con consapevolezza degli utenti, con contromisure degli amministratori.

Il tutto ricade in una adeguata Policy di Sicurezza Aziendale che si occupi di Gestione del Rischio.

Obiettivi:

• Identificare i processi aziendali e i loro requisiti IT associati. Stabilire priorità in base alla sensitività e criticalità temporali
• Identificare le minacce ai processi e alle infrastrutture
• Definire strategie per eliminare i rischi e minimizzare gli impatti dei rischi non eliminabili.

Classificazione delle Minacce

Aspetti della Difesa

• Acquisire consapevolezza dei problemi di sicurezza
  • Policy di Sicurezza aziendale
  • Personale addetto alla sicurezza
  • Addestramento contro pratiche pericolose
  • Requisiti minimi: Antivirus e Firewall
• Blindatura dei Server esterni
• Isolamento delle macchine deboli
• Piani di Recupero da Disastri

Blindatura dei Server

Con i seguenti aggiornamenti si compie più del 90% della protezione:

• Eliminare tutti i servizi inutili
• Aggiornare le patch di sicurezza dei servizi in uso
• Non usare mai autenticazioni in chiaro
• Non fidarsi mai dei protocolli di rete TCP/IP
  • i controlli avvengono sugli applicativi
• Aumentare la Registrazione delle attività (log)
• Usare sempre solo canali di comunicazione crittografati

Buffer Overflow

E’ una vulnerabilità presente in un numero elevato di programmi scritti male.

Lo sfruttamento consiste nell’input al programma di una stringa molto lunga e complicata.

Questa è una operazione compiuta in automatico da un programma specifico di Exploit, non manualmente.

Il risultato è spesso il lancio di una shell con i privilegi del programma in esecuzione - anche amministrativi.

Vi sono molte varianti di Buffer Overflow, la più nota da tempo è l’overflow di uno Stack Frame.

Per approfondire: “Smashing The Stack For Fun And Profit”, Phrack Magazine, n. 49, file 14 (http://insecure.org/stf/smashstack.html) - articolo molto tecnico.

La maggior parte dei programmi sono scritti in Linguaggio C o linguaggi derivati, e hanno le seguenti vulnerabilità:

• Vulnerabilità di struttura in memoria di un programma
  • Ogni funzione ha il suo stack frame con variabili locali
  • Gli stack frames sono allocati a memoria decrescente
  • Le variabili sono allocate a memoria crescente
  • All’inizio dello stack frame (memoria alta) c’è l’indirizzo di ritorno della funzione
• Vulnerabilità introdotta dal compilatore
  • Il linguaggio C non controlla il superamento delle dimensioni dell’array dichiarato (overflow)
  • Viene semplicemente sovrascritto quello che vi si trova
• Vulnerabilità di base dei computer
  • L’architettura di Von Neumann di tutti i computer moderni non vede alcuna differenza tra un byte di dati e uno di istruzioni

Occorre che la funzione:

• allochi un buffer (array) di caratteri
• contenga una o più funzioni che non controllano l’overflow
  • Sono tante: strcpy(), strcat(), sprintf(), scanf(), …

Il programma che invoca la funzione:

• fornisce una stringa più grande del buffer della funzione (causa un overflow)
  • di solito letta da input di terminale o di rete
• l’input contiene caratteri che in realtà sono codice malefico
  • spesso l’invocazione di una shell, da qui il nome ShellCode
• fa in modo di sovrascrivere l’indirizzo di ritorno della funzione con l’idirizzo del programma malefico

Molti programmi e protocolli di rete presentano queste vulnerabilità.

Non è facilissimo scrivere ShellCode (in assembler), ma è un’arte nota e sperimentata.

Contromisure:

• Scrivere bene i programmi
  • Solo i programmi Open Source, con codice visibile, sono garanzia di qualità e di assenza di altro malware
• Non eseguire i programmi con privilegi amministrativi
  • Se i programmi ne hanno bisogno in alcune parti: impostarli quando servono poi subito toglierli
• Eseguire i programmi in qualche tipo di contenitore
  • Chroot, Jail, Docker, Macchine virtuali
• Per il Brownfield (codice legacy non modificabile - opposto di Greenfield - codice modificabile): *Eseguirli entro del codice involucro (wrapper) che impedisca gli overflow - esempio: Valgrind
• Adottare tecniche di randomizzazione della posizione dei dati negli stack frames (Linux Moderno)
  • Non protegge da tutti i tipi di overflow

Schemi di Autenticazione

Identità Digitale Umana

CIE: Carta d’Identità Elettronica

SPID: Sistema Pubblico di Identità Digitale

Documento fisico (CIE) o elettronico (SPID) con gli attributi primari seguenti:

• nome e cognome (enti fisici)
• ragione sociale esede legale (enti giuridici)
• luogo e data di nascita
• sesso
• codice fiscale
• partita IVA (enti giuridici)
• estremi del documento usato per l'identificazione

ed almeno uno dei seguenti attributi secondari:

• numero di telefono fisso o mobile
• indirizzo di posta elettronica
• indirizzo di residenza fisico e/o elettronico

Terminologia

• Identità Informatica (Pseudoidentità)
  • Chiave univoca
  • Lista di attributi primari e secondari
• Autenticazione
  • Persona che ottiene un’identità informatica
  • Verifica con successo di un'identità informatica
• Identificazione
  • Da un’identità informatica risalire ad una persona (non sempre necessaria)
• Profilo (Ruolo)
  • Una lista di attività che si possono compiere e su quali componenti di un servizio (Lettura, inserimento, update, cancellazione, query, … )
• Autorizzazione
  • Associazione di un’identità informatica ad un profilo
• Auditing (Accountability)
  • Risalire da azioni su un servizio alla persona che le ha compiute

Fattori di Autenticazione

Servono nella fase di Autenticazione per comprovare l’identità dichiarata. Sono parte degli attributi primari.

Tre principali fattori:

• Conoscenza (what you know)
  • Passphrase, PIN, domanda privata, ...
• Possesso (what you own)
  • Smartcard, chiavi, OTP, ...
• Caratteristiche (what you are)
  • Controlli Biometrici
  • Fisiologici: impronte digitali, retina, …
  • Comportamentali: digitazione tastiera, tempi reazione, …

Usare un singolo fattore è autenticazione debole.

Autenticazione Forte o Multifattore: almeno due fattori.

Vengono di seguito esaminati alcuni dei principali metodi di autenticazione.

Password

UserID e Password come metodo di autenticazione.

La password è mantenuta sul server acceduto in forma cifrata, tipicamente come hash.

Alcuni algoritmi hash sono insicuri: MD5, SHA1 Altri, più moderni, sono migliori: SHA-256

Attacchi alle Password

Non è possibile dallo hash risalire alla password, ma è possibile tentare di indovinarla.

E’ necessario rubare (esfiltrare) il database delle password hash, per poter verificare quando si è indovinato.

Tipi di attacco:

• Forza Bruta (Brute Force Attack)
  • Tutte le combinazioni possibili di lunghezza massima
• Basato su Dizionario (Dictionary Attack)
  • Tutte le stringhe più probabili: date, parenti, attori, giocatori, personaggi, …
  • Con varianti euristiche: maiuscole, numeri apposti, …

Gli algoritmi di hash sono lenti e si impiega troppo tempo (anni). Sono però disponibili gigantesche tabelle di hash precalcolati, le Rainbow Tables, con cui si impiega pochissimo tempo (secondi).

Sale alle Password

Generare una Password col Sale

Verificare una Password col Sale

Crittografia e Certificati

Crittografia Classica

La crittografia ha una storia millenaria.

Sicurezza della Crittografazione

Incondizionatamente Sicura

• Il testo cifrato non contiene abbastanza informazioni per determinare univocamente il testo in chiaro corrispondente, per qualsiasi quantità di testo in chiaro
  • Solo One-Time-Pads
• Normalmente i testi lunghi crittografati con la stessa chiave aumentano la probabilità di successo di crittanalisi

Computazionalmente Sicura

• Il costo della decrittografazione è superiore al valore dell’informazione crittografata
• Il tempo richiesto per la decrittografazione supera la vita utile dell’informazione

Principio di Kerckhoffs

Legge di base della crittografia

“il faut qu’il puisse sans inconvénient tomber entre les mains de l’ennemi” - Auguste Kerckhoffs (1835-1903), Fiammingo (La cryptographie militaire, 1883)

“the enemy knows the system being used” - Shannon, 1949

Assumere che il nemico conosca gli algoritmi usati,

Contrario di: Security through Obscurity

Attacchi di Crittanalisi

Cifrario Perfetto

Cifrario perfetto se M e C sono indipendenti:

Prob (M=M’) = Prob (M=M’ | C=C’)

Lunghezza chiave > Lunghezza testo in chiaro

Modern Cryptography

Digitale e basata su due aspetti:

Algoritmi:

• Procedure matemetiche per la crittazione e decrittazione di dati
• Implementati come programmi, routines, funzioni

Tutti i maggiori algoritmi sono ben noti.

E' considerato sicuro un algoritmo noto se ha una implementazione Open Source. E' considerato insicuro un algoritmo proprietario e privato.

Chiavi:

• Sequenze di bit usati nella crittazione e decrittazione
• Configurate manualmente, note solo ai partecipanti

La sicurezza sta nelle chiavi.

Diffusione e Confusione

Diffusione:

• Dissipa la struttura statistica del testo in chiaro
• Il testo cifrato non ha strutture statistiche a corto raggio
• Cifra a blocchi binaria: permutazione + funzione (reversibile)
• Al cambiare di un bit del messaggio in chiaro cambiano in media il 50% dei bit del messaggio crittato

Confusione:

• Complica al massimo la relazione tra la statistica del testo cifrato e il valore della chiave di cifratura
• Al cambiare di un bit della chiave cambiano in media il 50% dei bit del messaggio crittato

Cifra di Feistel

Esempio di Rete a Sostituzione-Permutazione - (Substitution-Permutation Network SPN - Shannon).

Fondamento dei principali algoritmi moderni di crittografazione.

• Un blocco di testo in chiaro è diviso in due metà: Destra e Sinistra
• Vi sono più Sottochiavi, una per ciclo, derivate dalla Chiave primaria e tutte differenti
• N cicli, in ciascuno dei quali si ha:
  • una Sostituzione sulla metà Sinistra:
  • una Funzione di Ciclo sulla metà Destra, parametrizzata dalla Sottochiave di ciclo
• un OR esclusivo del risultante con la metà Sinistra
• una Permutazione: interscambio delle metà Destra e Sinistra

Tutti i maggiori algoritmi di crittografazione moderni sono derivati dai concetti di Cifra di Feistel

Gestione Chiavi

Chiavi Singole

Definizione: Chiave = Stringa di caratteri = Sequenza di Bit

• La stessa chiave K crittografa e decrittografa il messaggio
• Il messaggio non cambia di lunghezza da Chiaro a Crittografato
• L'algoritmo di crittografazione è relativamente veloce

La chiave deve transitare da mittente a destinazione. Il canale per le chiavi è diverso dal canale per i messaggi:

• più sicuro
• più costoso (es. Umano)

Non ne vale la pena per singoli messaggi.

Proprietà delle Chiavi

La crittografazione è un’algebra lineare.

Sia M:messaggio in chiaro, C:messaggio crittografato, E(K)[]:funzione di crittografazione con chiave K, D(K)[]:funzione di decrittografazione con chiave K

Si ha:

C=E(K)[M]    M=D(K)[C]    M=D(K)[E(K)[M]]

In un’algebra lineare la rappresentazione può usare funzioni lineari, matrici od operatori lineari.

Usando operatori lineari e confondendo crittografazione e decrittografazione, rappresentate con la sola chiave K (le sottochiavi sono invertite):

C=KM   M=KC   M=KKM

cioè KK=Identità

Interscambio Messaggi

Chiavi Doppie

Da una stringa casuale S un algoritmo genera due chiavi particolari dette:

• Chiave pubblica U
• Chiave priv*ata P

Algoritmi: RSA, Diffie-Hellmann, ...

Il messaggio è crittografato con una delle chiavi e può venir decrittografato solo con l’altra.

La chiave Pubblica viene inviata ad un Deposito Chiavi da cui tutti possono prelevarla oppure configurata nel software di comunicazione.

La chiave Privata viene mantenuta segreta e non circola mai in rete.

Confidenzialità del Messaggio

Spesso è desiderata la segretezza (riservatezza, confidenzialità) del messaggio.

Il messaggio viene crittografato dal mittente con la chiave pubblica del destinatario.

Solo chi è in possesso della chiave privata corrispondente, cioè il destinatario, può decrittografare il messaggio.

Assicurazione di Provenienza

Non sempre si desidera che il messaggio sia confidenziale, può essere necessario invece assicurarsi dell’identità del mittente.

In tal caso il mittente crittografa il messaggio in partenza con la propria chiave privata.

Tutti lo possono decrittografare avendo così l’assicurazione formale che solo il mittente l’abbia potuto inviare.

Confidenzialità ed Assicurazione di Provenienza possono ottenersi entrambi indipendentemente e simultaneamente.

Necessità di un Programma di gestione, p.es. PGP (Pretty Good Privacy).

In pratica l’uso delle chiavi doppie è troppo lento (10000 volte più delle chiavi singole);

• OK per commutazione di messaggio
• NO per commutazione di pacchetto

Ma: la lunghezza delle chiavi singole è ca. 128 bit

Quindi:

• Usare le chiavi doppie per interscambiare una chiave singola in modo sicuro
• Poi usare la chiave singola per crittografare il messaggio

Concetto di Chiave di Sessione

Chiave di Sessione

The sender initially encrypts a single key (session key) and sends it to the receiver The rest of the communication session is encrypted with that single key

Message Authentication Code

Message Authentication Code (MAC): checksum crittografico allegato al messaggio.

Lo schema di checksum non deve necessariamente essere reversibile.

Funzione di Hash

• Input: stream di bit di qualsiasi lunghezza
• Output: stream di bit di lunghezza fissa
  • anche detto: Segnatura
• Collisione: due stream di input diversi che danno la stessa segnatura - computazionalmente impossibile

Proprietà:

• Funzione non invertibile
  • Tipicamente usa iterazione di passi con compressione dei risultati intermedi
• Attacchi di forza bruta: dipendono dalla lunghezza della segnatura
• Alternativamente metodi crittanalitici complessi
  • Reperire collisioni nei passi intermedi

Firma Elettronica

Mittente:

• Calcolare una funzione di hash del messaggio
• Crittarla con chiave privata e appenderla al messaggio

Ricevente:

• Estrarre la funzione di hash e decrittarla con chiave pubblica del mittente
• Applicare la funzione di hash al messaggio
• Se coincidono la firma è verificata

Non repudiabilità dei messaggi firmati.

Definizioni Italiane

Definizioni giuridiche un po' imprecise dal punto di vista tecnico:

• Firma elettronica (FE)
  • Metodo per identificare l'autore di un'operazione informatica o di un documento informatico
• Firma elettronica avanzata (FEA)
  • FE che consente il controllo esclusivo del mezzo di firma da parte del firmatario, e permette di verificare l'integrità del documento firmato
• Firma elettronica qualificata (FEQ)
  • FEA basata su un certificato qualificato e realizzata mediante un dispositivo sicuro per la creazione della firma
• Firma digitale (FD)
  • FEA basata su un certificato qualificato e realizzata con la tecnica della crittografia asimmetrica

Non esistono al momento tecnologie di firme qualificate che non siano digitali.

Il dispositivo di firma della FEQ è opzionale, poichè FEQ ed FD producono i medesimi effetti giuridici.

Dispositivo di Firma

Apparato elettronico in grado di generare firme digitali e di fornire autenticazione on line tramite certificato.

Formato tipico: Card simile a carta di credito.

• Anche su chiavi USB
  • Ospita un chip avanzato crittografico
  • Necessario l'apposito lettore e software
• Conserva a bordo la chiave privata dell'utente
• Obbligatorio per Firma Qualificata ma non per Firma Digitale
• Non è clonabile

Un'altra soluzione moderna è di ospitare la chiave privata a bordo di uno Smartphone.

Il tentativo di accesso ai dati mediante apparati elettronici di violazione provoca di solito la perdita dei dati contenuti.

• Accesso tramite PIN
• Numero massimo di tentativi - blocco card o programma
• Sbloccare con PUK (personal unlock code)

NOTA

Il fallimento di accesso, avaria o perdita del dispositivo di firma rende inverificabili tutti i documenti firmati con tale dispositivo

Certificati

Identità e Fiducia

In un Deposito Chiavi una chiave necessita di un identificativo univoco del possessore:

• Indirizzo di posta elettronica

Problemi:

• Come si può essere certi che la chiave appartiene alla persona indicata?
• Come si può essere certi dell'identità di un corrispondente nel mondo informatico?
• Come ci si può fidare della verità delle asserzioni di un documento informatico?

Soluzione:

• Trasferimento della fiducia dal soggetto finale ad altri:
  • Più enti arzialmente fidati: raccomandazioni
  • Singolo ente completamente fidato: certificazioni

Verifica: Scenario Possibile

In Pratica

Il deposito chiavi non esiste:

• Qualche eccezione: MIT Key Server
• Sarebbero troppi, problemi di sicurezza e di privacy
• Soprattutto problemi politici (affrontabili tecnicamente)
  • es: Planetary Citizen Registry (1971)

L'utente vuole potersi fidare in assenza dell'ente di verifica o di connessione.

• Necessaria la chiave pubblica del soggetto, non modificata

Struttura di un certificato soggetto:

E' necessaria anche la chiave privata del certificatore. per decrittare il certificato:

La chiave privata è di solito precaricata sul SW dell'utente.

Certificati Speciali

Certificate Chain:

Self-signed Certificate (Root CA):

Uso del Certificato

Esempio della situazione con SSL/TLS.

Standard X509

Standard della ITU-T sui Certificati.

• Basato su crittografia a chiave doppia e firma elettronica
• Definisce i tracciati record dei Certificati
  • 3 versioni principali
• Prevede Liste di Revoca dei Certificati

Imposta unastruttura gerarchica degli enti di certificazione

• Certifying Authority (CA)
• Public Key Infrastructure (PKI)

Public Key Infrastructure

Per PKI s’intende l’infrastruttura necessaria per consentire un uso appropriato ed efficiente di una serie di funzionalità legate alla crittografia a chiave pubblica quali la firma digitale, l’autenticazione, la cifratura/decifratura e la marcatura temporale dei documenti.

PKI è una infrastruttura per la gestione di chiavi pubbliche e non una infrastruttura pubblica per la gestione chiavi.

OpenSSL

E' un toolkit Open Source robusto, sicuro e completo per la gestione di protocolli Transport Layer Security (TLS) e Secure Sockets Layer (SSL).

E' anche una libreria generica con molte utility crittografiche.

openssl

OpenSSL> help
Standard commands
asn1parse         ca                ciphers           cms
crl               crl2pkcs7         dgst              dhparam
dsa               dsaparam          ec                ecparam
enc               engine            errstr            gendsa
genpkey           genrsa            help              list
nseq              ocsp              passwd            pkcs12
pkcs7             pkcs8             pkey              pkeyparam
pkeyutl           prime             rand              rehash
........

openssl comando opzioni argomenti

Certificate Request

Creazione di una nuova Chiave Privata e Certificate Signing Request:

openssl req -out geekflare.csr -newkey rsa:2048 -nodes -keyout geekflare.key

Generating a RSA private key
............
writing new private key to 'geekflare.key'
-----
You are about ....
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:NSW
Locality Name (eg, city) []:Sydney
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:Development
Common Name (e.g. server FQDN or YOUR name) []:geekflare.com
Email Address []:boss@geekflare.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:password
An optional company name []:GeekFlare

Self-Signed Certificate

Creazione di un Self-Signed Certificate per una Root CA:

openssl req -x509 -sha256 -nodes -newkey rsa:2048 -keyout gfselfsigned.key -out gfcert.pem

Generating a RSA private key
..........
writing new private key to 'gfselfsigned.key'
-----
You are about to be asked ...
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Washington
Locality Name (eg, city) []:Seattle
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Microsoft
Organizational Unit Name (eg, section) []:World Control
Common Name (e.g. server FQDN or YOUR name) []:world.ms.com
Email Address []:galacticboss@ms.com

Configurazione di CA

Creare un file minimo di configurazione per una CA:

vim ca.conf

[ ca ]
default_ca = ca_default
[ ca_default ]
dir = ./ca
certs = $dir
new_certs_dir = $dir/ca.db.certs
database = $dir/ca.db.index
serial = $dir/ca.db.serial
RANDFILE = $dir/ca.db.rand
certificate = $dir/ca.crt
private_key = $dir/ca.key
default_days = 365
default_crl_days = 30
default_md = md5
preserve = no
policy = generic_policy
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = optional
emailAddress = optional

Infrastruttura CA

Creare la directory di database del CA ed alcune altre directory e file necessari, che manterranno informazioni sui certificati emessi:

mkdir ca
cd ca
mkdir ca.db.certs
touch ca.db.index
echo "1234" > ca.db.serial
cd ..

Copiare il certificato autofirmato (root CA certificate) e chiave privata alla directort CA.

cp gfcert.pem ca/ca.crt
cp gfselfsigned.key ca/ca.key

Generare un Certificato

Firmare una Certificate Request e generare un certificato:

openssl ca -config ca.conf -out certificate.pem.crt -infiles geekflare.csr

Using configuration from ca.conf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'AU'
stateOrProvinceName   :ASN.1 12:'NSW'
localityName          :ASN.1 12:'Sydney'
organizationName      :ASN.1 12:'Internet Widgits Pty Ltd'
organizationalUnitName:ASN.1 12:'Development'
commonName            :ASN.1 12:'geekflare.com'
emailAddress          :IA5STRING:'boss@heekflare.com'
Certificate is to be certified until Sep  8 09:19:15 2022 GMT (365 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Altre Operazioni

Verificare il file CSR:

openssl req -noout -text -in geekflare.csr

Da in output il contenuto ASCII della richiesta.

Creare una chiave privata RSA:

openssl genrsa -out private.key 2048

Verificare una chiave privata:

openssl rsa -in private.key --check

Verificare la Certificate Signer Authority:

openssl x509 -in certificate.pem.crt -noout -issuer -issuer_hash

issuer=C = US, ST = Washington, L = Seattle, O = Microsoft, 
OU = World Control, CN = world.ms.com, 
emailAddress = galacticboss@ms.com
2f06f056

Controllare il valore hash di un certificato:

openssl x509 -noout -hash -in certificate.pem.crt

c414604e

HTTPS Server in Docker

Preparare la directory di progetto:

mkdir -p ~/docker/08nginx-cert
cd ~/docker/08nginx-cert

Preparare un Self Signed Certificate:

openssl req -x509 -nodes -days 365 \
  -subj "/C=CA/ST=QC/O=Example Inc./CN=example" \
  -addext "subjectAltName=DNS:example.com" \
  -newkey rsa:2048 -keyout server.key \
  -out server.crt

Run del server col certificato:

docker run -d -v $PWD:/etc/ssl/private/ -v $PWD:/etc/ssl/certs/ \
  -e CRT=server.crt -e KEY=server.key \
  -p 80:80 -p 443:443 --name one mpineault/nginx-alpine-ssl

Collegarsi con un browser a https://localhost

Connessioni Sicure con SSH

Login remoto sicuro e altri servizi su canale insicuro: ssh, sftp, scp - secure shell, secure file transfer, secure copy.

Rimpiazza comandi Unix rlogin, rcp, rsh, ecc.

Fornisce:

• Crittografazione del canale
• Autenticazione forte - basato sull'uso di chiavi doppie (Pubblica / Privata)
• Tunnel per altri protocolli su ssh (X Window)

Contrasta:

• IP spoofing
• DNS spoofing
• Alterazioni di routing

Il server si autentica con chiave pubblica.

E' possibile preinstallare le chiavi pubbliche degli host conosciuti.

Files:

• /etc/ssh/known_hosts - default per tutti gli utenti
• $HOME/.ssh/known_hosts - per ciascun utente

Handshake ssh

Il server ha una coppia di chiavi doppie per ogni algoritmo supportato.

Segue l'autenticazione dell'utente (password), che transita già crittografata.

Autenticazione a Chiave

Alternativa sicura all'autebticazione sullo host remoto con password.

Generazione chiavi asimmetriche sul client:

ssh-keygen

• Accettare la locazione di default ~/.ssh/id_rsa
• Dare la passphrase 'segreto' ( 2 volte)

Registrare la chiave allo ssh agent.

Se non è già partito, lanciarlo:

eval $(ssh-agent -s)
ssh-add

Viene chiesta la passhphrase.

Aggiungere l'autorizzazione al server:

ssh-copy-id utente@IP

Viene chiesta la password di utente.

Uscire e provare la connessione: ssh utente@IP.

Non viene più chiesta la password di utente.

Collegamento Parametrico

Sul client editare il file ~/.ssh/config:

vim ~/.ssh/config

Host userv
  User root
  Hostname 10.0.1.12
  Port 22
  IdentityFile ~/.ssh/id_rsa

Sostituire il proprio nome di login sul server e l'indirizzo del server.

Si possono aggiungere più paragrafi, per più host remoti.

Test:

ssh userv

Ssh Port Forwarding

Tunnel ssh e Pericoli

Qualunque utente può stabilire un tunnel ssh.

Necessario un server ssh intranet e un utente noto su tale server. N.B.: Molti Linux installano e attivano ssh per default.

• I server ssh non devono avere utenti di comodo (guest)
• I server interni devono essere protetti da firewall personali
• Accettare connessioni solo dal server ssh ufficiale

Esempio di Ssh

Nella directory del primo esercizio, lanciare il progetto:

cd ~/ex/01net1-ccli-cssh
docker compose up -d

Autenticazione a Chiave

Aprire il terminale one.

Coppia di Chiavi Crittografiche

Generare le chiavi crittografiche:

ssh-keygen

Viene chiesta:

1. la locazione ove porre le chiavi - accettare il default
2. La passphrase di sblocco della chiave privata

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:ZvsVOI2UdgkkBvW05HTOkAqx+M8IHXrjY1MGDJeU08Q root@one
The key's randomart image is:
+---[RSA 2048]----+
|    ..=X=.B..    |
|     ==oEB.O .   |
|    . =o .B =    |
|     + o.o =     |
|    o = S + o    |
|     + X . . .   |
|      * +   .    |
|     . o . .     |
|          .      |
+----[SHA256]-----+

Viene generata una coppia di chiavi, pubblica e privata. Quella pubblica rappresenta l'identità e va distribuita ad altri, quella privata è associata alla chiave pubblica e non va mai distribuita.

Le locazioni sono nella directory ~/.ssh:

• id_rsa - chiave privata
• id_rsa.pub - chiave pubblica

Sono in formato ASCII Armoured, cioè trascodificate in Base64.

L'algoritmo di generazione di default è RSA a 2048 bit.

La chiave è molto lunga. Il fingerprint è uno hash della chiave che la rappresenta e identifica.

Il randomart è un precursore funzionale di un QR Code: è un'altra rappresentazione della nostra chiave pubblica, bidimensionale.

Note

La chiave pubblica generata identifica l'account che l'ha generata, in questo caso root, sulla macchina che l'ha generata, in questo caso one.

E' un'Identità. Perderla, o generarne un'altra, vuol dire non essere più in grado di essere riconosciuti su tutti i server remoti che avevamo configurato con le chiavi precedenti.

Nel mondo reale abbiamo alcune Identità Digitali, per esempio lo SPID, o la CIE o un conto bancario on line. Le chiavi private, o la passphrase di sblocco delle chiavi private, sono spesso registrate su uno smartphone, e associate non solo ad una persona fisica, ma anche all'identificativo IMEI dello smartphone.

Cambiare smartphone può voler dire dover rifare l'identità digitale che quello precedente configurava.

Noi non siamo più noi, siamo il nostro smartphone.

Ssh Agent

Senza questo componente, ogni volta che ci connettiamo alla macchina remota che presto configureremo, ci verrà chiesto non più la password dell'utente remoto, ma la passphrase di sblocco della nostra chiave privata.

Lo Ssh Agent si ricorda questa passphrase per noi e la fornisce trasparentemente.

Abilitare il lo Ssh Agent. Fornirgli la chiave. Viene chiesta la passphrase di sblocco della chiave privata. Non verrà più richiesta durante questa sessione.

eval $(ssh-agent -s)
ssh-add

Se terminiamo la sessione a one naturalmente termina anche il nostro Ssh Agent, e alla prossima sessione dovremo riattifarlo e risottomettergli la chiave.

Trasferimento della Chiave Pubblica

Trasferire la propria chiave pubblica al server:

ssh-copy-id pippo@192.168.101.12

Viene chiesta la password dell'utente pippo sul server.

Terminato. Se ha funzionato l'accesso al server è ora con autenticazione a chiave.

Sul server di destinazione viene trasferita la chiave pubblica dell' utente root@one, e storata nel file ~/.ssh/authorized_keys della directory di login di pippo.

Prova di Collegamento

ssh pippo@192.168.101.12

Da subito accesso e non chiede la password di pippo.

Naturalmente se accediamo ad un altro utente o ad un altro server il processo è da ripetere.

Collegamento Parametrico

Sul terminale one editare il file di configurazione:

vi ~/.ssh/config

Host two
  User pippo
  Hostname 192.168.101.12
  Port 22
  IdentityFile ~/.ssh/id_rsa

Test di collegamento:

ssh two

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.

Filtraggio Pacchetti e Firewalls

Difese Perimetrali e in Profondità

Difesa Perimetrale:

• Firewall Tradizionale
• Sopprimere tutti gli accessi alternativi (smartphone, ecc.)
• Monitorare e persegure le violazioni

Difesa in Profondità:

• Difendere ogni macchina
• Logging e filtri addizionali
• Gli attacchi possono provenire dall’interno
• Uso pervasivo di tecniche di crittografazione
• Segmentazione rete interna con switch

Firewall Perimetrale

Insieme di funzionalità coordinate che separano l’Intranet dall’Internet.

Sistema di difesa tra Intranet e Internet.

Composto di più ruoli:

Implementato da piu’ piattaforme (una al limite).

Schema logico di un Firewall

Tabella di Filtraggio Pacchetti

Gateway di Circuito

Router Interno

Separa indirizzi IP validi da interni.

Può compiere ulteriore filtraggio pacchetti

Può implementare Network Address Translation (NAT).

Proxy Web in Uscita

Relay di Posta

DNS

Firewall di Linux

Tuning del firewall per la difesa

Sistemare i parametri di tuning nel file di configurazione /etc/sysctl.conf:

net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.tcp_syncookies = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.ip_forward = 1

Tabelle iptables

iptables -t filter ...

• Default
• Filtraggio in ingresso
• Nessuna variazione di campi in uscita

iptables -t nat ...

• Filtraggio in ingresso
• Variazione in uscita dei campi IP(mittente), IP(destinatario),
• Porta(mittente), Porta(destinatario)

iptables -t mangle ...

• Filtraggio in ingresso
• Variazione in uscita di qualsiasi campo

iptables -t filter

Default.

Chains predefinite (non si possono eliminare):

• INPUT - pacchetti destinati a questo host
  • Firewall personale - Ingress filtering
• OUTPUT - pacchetti in partenza da questo host
  • Egress filtering
• FORWARD - pacchetti in transito da questo router
  • Firewall perimetrale

Operazioni su una Chain

iptables [-t filter] ...

• -A chain regola -j destinazione - append
• -I chain regola -j destinazione - insert
• -D chain numero - delete
• -R chain numero regola -j destinazione - replace
• -L [-v] [chain] - list
• -F [chain] - flush
• -N nuovachain - crea nuova chain
• -X nuovachain - rimuovi chain
• -E vecchiachain nuovachain - rinomina chain
• -P chain destinazione - policy di default

Destinazioni finali - nessun ulteriore processamento:

• ACCEPT - il pacchetto passa
• REJECT - non passa, è inviato un messaggio al mittente di tipo ICMP administratively-prohibited
• DROP - non passa e non è inviato alcun messaggio

Destinazioni non finali:

• LOG - registrato a syslog
• Nuovachain - alla chain nuova come subroutine
• RETURN - ritorna alla chain chiamante

Solo ACCEPT e DROP si possono usare come policy di default (opzione -P)

Esempi di Regole

• -s 180.24.36.0/24 - rete sorgente
• -d 10.0.0.0/8 - rete destinazione
• -s ! 172.1.2.0/24
• -d ! 192.168.1.32/27 - NOT reti specificate
• -i eth0 - interfaccia di ingresso
• -o eth1 - interfaccia di uscita
• -p tcp | udp - protocollo
  • --sport 1024:65500 - porta sorgente (range)
  • --dport 23 - porta destinazione
• -p icmp
  • --icmp-type 0 - tipo di messaggio ICMP

Regole non specificate valgono ANY | EVERYWHERE

Policy di Default

iptables -t filter -P chain ACCEPT

• Blacklist: tutto è accettato tranne il traffico descritto dalle regole del chain
• Ogni regola del chain ha destinazione DROP o REJECT
• Strategia deprecata

iptables -t filter -P chain DROP

• Whitelist: tutto è negato tranne il traffico descritto dalle regole del chain
• Ogni regola del chain ha destinazione ACCEPT
• Strategia favorita

Firewall Stateless

SSH con firewall personale stateless

iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT

iptables -t filter -A OUTPUT -p tcp --sport 22 -j ACCEPT

SSH con firewall perimetrale stateless

iptables -t filter -A FORWARD -d 192.168.1.7 -p tcp --dport 22 -j ACCEPT

iptables -t filter -A FORWARD -s 192.168.1.7 -p tcp --sport 22 -j ACCEPT

Firewall Stateful

Solo per le connessioni con TCP.

Tutte le connessioni già stabilite o in relazione ad esse, sono concesse.

Personale:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Perimetrale:

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Le connessioni nuove concesse con più discriminazione:

iptables -A INPUT -s 10.10.10.0/24 -i eth1 -p tcp --dport 22 -m state --state NEW -j ACCEPT

Firewall e ICMP

Se eth0 è l'interfaccia esterna ed eth1 l'interfaccia interna del filtro personale:

iptables -A OUTPUT -p icmp --icmp-type 8 -o eth0 -j ACCEPT

“ping” in uscita

iptables -A INPUT -p icmp --icmp-type 0 -i eth0 -j ACCEPT

“pong” in ingresso

iptables -A INPUT -p icmp --icmp-type 3 -i eth0 -j ACCEPT

destination unreachable in ingresso

iptables -A INPUT -p icmp --icmp-type 11 -i eth0 -j ACCEPT

TTL exceeded in ingresso

Simili regole per il firewall perimetrale

Tabelle di Iptables

filter:

• ACCEPT o DROP sulla base dei campi del pacchetto in ingresso
• Nessun cambiamento ai campi del pacchetto

nat (Network Address Translation):

• Cambiamento a uno o più dei campi: IP_mittente, IP_destinazione, Porta_mittente, Porta_destinazione
• Eseguito prima del routing (PREROUTING) o dopo il routing (POSTROUTING)

mangle:

• Cambiamento a uno o più campi qualsiasi
• Potenzialmente potente e flessibile, poco usato
• Eseguito prima del routing (PREROUTING) o dopo il routing (POSTROUTING)

Masquerade

Il Firewall si ‘maschera’ come mittente del pacchetto.

Deve sapere a chi va il pacchetto di ritorno.

Esempio:

iptables -A POSTROUTING -t nat -o eth0 -s 192.168.1.0/24 -d 0/0 -j MASQUERADE

Iptables Flowchart