Autenticazione ssh senza password

Fonte: http://www.linuxproblem.org/art_9.html

Se vogliamo connetterci ad un server ssh e autenticarci senza bisogno di inserire la password, possiamo utilizzare l’autenticazione tramite chiavi. Questo sistema è particolarmente utile quando vogliamo che la connessione ssh sia gestita da uno script bash, magari con attivazione schedulata tramite cronjob.

Abbiamo due host:
– client locale “PC-cons1″ con utente root (può essere qualsiasi utente)
– server openssh con nome pc-test-8 con utente luca

Logghiamoci nel client locale come utente root e generiamo la coppia di chiavi di autenticazione. Quando ci verrà chiesta la passphrase non inseriamo nulla, altrimenti vanifichiamo la possibilità di autenticarci senza password:

root@PC-cons1:~# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
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:
45:05:70:62:63:16:77:20:51:74:1b:9d:67:bd:a4:51 root@PC-cons1
The key's randomart image is:
+--[ RSA 2048]----+
...
...
...
...
...
+-----------------+

Ora connettiamoci via ssh all’host pc-test-8 come utente luca e creiamo in esso la directory .ssh nella home di luca:

root@PC-cons1:~# ssh luca@pc-test-8 mkdir -p .ssh
The authenticity of host 'pc-test-8 (192.168.201.198)' can't be established.
ECDSA key fingerprint is df:13:36:93:8f:27:61:69:f3:97:15:8c:43:35:9a:1f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pc-test-8' (ECDSA) to the list of known hosts.
luca@pc-test-8's password:

Ora appendiamo la nuova chiave pubblica dell’utente root nel file .ssh/authorized_keys nella home dell’utente luca nell’host pc-test-8 e inseriamo la password di luca per l’ultima volta:

root@PC-cons1:~# cat .ssh/id_rsa.pub | ssh luca@pc-test-8 'cat >> .ssh/authorized_keys'
luca@pc-test-8's password:

Da ora possiamo loggarci in pc-test-8 come utente luca dall’host PC-cons-1 senza password:

root@PC-cons1:~# ssh luca@pc-test-8
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-24-generic x86_64)

* Documentation: https://help.ubuntu.com/

Last login: Tue Jan 27 07:09:41 2015
luca@pc-test-8:~$

 

Montare condivisioni Windows da Linux

Montare condivisioni Windows da Linux

CIFS (formalmente conosciuto come SMB) è il protocollo di default delle condivisioni Windows.
Da una macchina Linux è facile connettersi ad una condivisione Windows, sia utilizzando la GUI che la CLI.

Occorre innanzitutto installare i seguenti pacchetti:
(in RHEL/CentOS/Fedora)

# yum install samba-client samba-common cifs-utils

CONNETTERSI TRAMITE GUI:

E’ la soluzione sicuramente più comoda perchè permette di gestire i file remoti tramite interfaccia grafica come se fossero locali. Ovviamente non è affatto adatta agli script.
A seconda del sistema Linux e del server grafico, la procedura può variare.
Dal browser Nautilus, ad esempio, basta inserire nella barra di navigazione l’indirizzo del server Windows nella forma:
smb://<server>/<share>
Una volta dato l’invio, verranno chieste le credenziali per l’accesso alla condivisione.
Nelle ultime versioni di Ubuntu in Nautilus troviamo la comoda opzione “Connetti al server” che apre una finestra di dialogo dove inserire smb://<server>/<share>.

CONNETTERSI TRAMITE CLI
Utilizzando il comando smbclient è possibile accedere alla condivisione Windows tramite linea di comando, in una modalità assai simile a quella ftp. E’ questa la soluzione migliore per l’utilizzo tramite script.
Per visualizzare le condivisioni remote disponibili:

# smbclient -L <server> -U <user>

Dopo aver fornito la corretta password, il comando visualizzerà le condivisioni in forma di tabella a 3 campi: sharename, type, comment.
Per connettersi ad una particolare condivisione:

# smbclient //<server>/<share> -U <user>

Dopo aver fornito la password corretta apparirà il prompt “smb:\>” che riconoscerà svariati comandi “FTP-like” come: ls, cd, lcd, get, put, mget, mput etc

UTILIZZO DEL COMANDO MOUNT
In alternativa alle due precedenti soluzioni possiamo usare il comando “mount”, particolarmente adatto se abbiamo bisogno di un accesso persistente alla condivisione. In tal modo la condivisione apparirà come una cartella locale e sarà possibile utilizzare comandi come “cp” o “rm” per gestire i file remoti.
Potrebbe essere necessario installare alcuni pacchetti come cifs-utils e smbfs, dipende dalla distribuzione e dalla versione.
La sintassi per montare la condivisione è la seguente:

# mount -t cifs -o user=<user> //<server>/<share> /win_share

“win_share” è il punto di mount della condivisione remota nel sistema locale. Di fatto è una cartella locale dentro alla quale appariranno gli oggetti della condivisione. Se non esiste va creata con “mkdir /win_share”.

Per smontare:

# umount /win_share

Se vogliamo che la condivisione venga montata all’avvio, potremo editare il file /etc/fstab ed aggiungere la riga seguente:

//servername/sharename /win_share cifs username=msusername,password=mspassword,iocharset=utf8,sec=ntlm 0 0

RETI – Fondamenti (Cisco based)

RETI – Fondamenti (Cisco based)

Switch e switching
Vlan
Router e routing
WAN
ACL
NAT
Enterprise Network Documentation
Lezioni di Italiano a Monaco di Baviera

Ports/applications

0-1023: well-known ports;
1024-49151: registered ports;
49152-65535: private ports.

20 tcp ftp-data
21 tcp ftp-control
23 tcp telnet
25 tcp smtp
53 tcp/udp dns
67 udp dhcp v4 client
68 udp dhcp v4 server
69 udp tftp
80 tcp http
110 tcp pop3
137 tcp/udp nbns
143 tcp imap4
161 udp snmp
443 tcp https
546 udp dhcp client
547 udp dhcp server

Pila iso/osi

7 application
6 presentation
5 session
4 transport
3 network
2 data link
1 physical

Pila tcp/ip

4 application
3 transport
2 internetwork
1 physical

Wireless – protocol

IEEE 802.11a – 5Ghz – max data rate 54 Mbps – non compatibile con i 2.4 Ghz
IEEE 802.11b – 2.4 Ghz – max data rate 11 Mbps – 46m indoor; 96 outdoor
IEEE 802.11c – 2.4 Ghz – max data rate b54 Mbps – compatibile con 802.11b
IEEE 802.11n – 2.4/5 Ghz – totalmente retrocompatibile – ancora in fase di sviluppo/ultimazione

Wireless – security

 

Lezioni di Italiano a Monaco di Baviera?

http://francescaromano.eu

 

Autenticazione:
open authentication = nessuna autenticazione richiesta
PSK (preshared keys) = ap e client con uguale chiave di criptazione dati
EAP (extensible authentication protocol) = autenticazione che si appoggia ad un server RADIUS
Criptazione dati
WEP (wired equivalency protocol) = chiave a 64, 128, raramente a 256 bits condivisa tra AP e tutte le STAs
WPA (wi-fi protected access) = chiave da 64 a 256 bits dinamica, ovvero generata a nuovo ogni volta che un client stabilisce connessione

Connessioni

dial-up = 56 Kbps
DSL = 512 Kbps e oltre
Cable modem = 5 Mbps – 10 Mbps
Satellite = 128-512 Kbps

Dedicated bandwidth options

medium size business:
T1 = 1.544 Mbps
E1 = 2.048 Mbps

large business:
T3 = 45 Mbps
E3 = 34.368 Mbps

large business with branch in the same city:
Metro Ethernet = 10 Gbps

Planning a network upgrade

Network requirements documentation (inventario dell’esistente):
device name; date of purchase; warranty information; location; brand and model; OS’s; logical addressing information; connection information; security informations.
1. requirements gathering
2. selection and design
3. implementation
4. operation
5. review and evaluation

IDF = intermediate distribution facility MDF = main distribution facility

Classificazione indirizzi IP (RFC1918: address allocation for private internets)

classe A 1-127 /8            privati: 10.0.0.0 – 10.255.255.255 /8
classe B 128-191 /16     privati: 172.16.0.0 – 172.31.0.0
classe C 192-223 /24     privati: 192.168.0.0 – 192.168.255.255
classe D 224-239 multicast
classe E 240-255 experimental use

127.0.0.0 loopback address (privato)
169.254.0.1 – 169.254.255.254 /16 riservato APIPA (automatic private ip addressing)

IPv4 address: 32 bits
IPv6 address: 128 bits (hex)

Negoziazione DHCP

dhcp discover – offer – request – acknoledgement

SWITCH CISCO e SWITCHING in generale

 

 

CAM: content addressable memory → high-speed memory che contiene la MAC address table
Aging time: tempo trascorso il quale lo switch cancella le entry non utilizzate dalla mac address table
Durante una sessione lo switch crea una virtual circuit tra le porte che stanno comunicando.
ASIC: caratteristica harware (e quindi anche software) dei multilayer switch.

Metodi di switching:

Store-and-forward (oggi più comune) → lo switch legge, controlla e stora ogni frame. Controlla il checksum (CRC), e se tutto è ok inoltra il frame.
Cut-through switching → tutto viene switchato in automatico, senza alcun controllo.
Può essere fastforward (il metodo più veloce, che non controlla nulla) oppure fragment-free (quando legge i primi 64 bytes del frame, che sono la misura minima di un frame ethernet – i più piccoli sono generalmente frutto di collisioni, e vengono scartati).
I moderni switch usano la forma mista detta adaptive cut-through switching: iniziano a forwardare i frame con il fast-forward ma controllando eventuali errori. Se gli errori superano un certo numero prestabilito, passano in Store-and-forward switching.

STP (Spanning Tree Protocol):

Si avvia di default sugli switch; è un open standard protocol. Disabilita alcune porte di link ridondati per evitare loops. Si riconfigura dinamicamente al variare della rete di switches.
Il root bridge è il “focal point”, quello switch che manda a tutti gli altri i BPDU (bridge protocol data units) ogni 2 secondi in multicast, che contengono informazioni sulla topologia della rete.
Nella negoziazione ogni porta passa vari stati:
1. blocking →20 sec circa → riceve solo i BPDU ma scarta tutti i frame contenenti altri dati → led steady amber
2. listening → 15 sec circa → calcola quali rotte possono essere usate senza creare loops → non forwarda nulla → led: flash amber
3. learning → 15 sec circa → riceve e processa tutto, impara i mac ma non forwarda nulla → led: flash amber
4. forwarding → processa BPDU e data frames, impara mac-addresses e inoltra i data frames attraverso la rete. → led steady green
Lo stato disabled corrisponde ad un “administratively down”.
Tempo di convergenza: circa 50 sec. → Non è grave solo se la rete è stabile e non sono previsti cambiamenti frequenti.
Implementazioni proprietarie Cisco minimizzano i tempi di convergenza:
PortFast → le access port vanno subito in forwarding state, senza aspettare la convergenza
UplinkFast → accelera la scelta della nuova root-port
BackboneFast → permette velocissima convergenza quando cambia qualcosa nella topologia dello spanning-tree; viene utilizzato nel distribution e nel core layer.

RSTP (Rapid Spanning Tree Protocol)

Open protocol. Permette la riconfigurazione in meno di 1 secondo. Le porte sono o in discarding state (che riassume i primi tre stati dello STP), o in forward state. Introduce il concetto di active topology.

Vari show:

C#show spanning-tree → display root ID, bridge ID, and port states
C#show spanning-tree summary → sommario delle porte
C#show spanning-tree root → status and information about the root bridge
C#show spanning-tree detail → information on the spanning-tree ports
C#show spanning-tree blockedports → view any port that are currently blocked by STP

S# show port security → mostra tutte le porte dove è attivo il port-security
S# show mac-address-table → mostra tutti i mac che lo switch ha imparato e le vlan associate alle porte.

 

Bridge-ID (BID) → identificativo dello switch, composto dal valore di bridge-priority (default 32.768) + mac-address più basso delle sue porte. Viene eletto root lo switch con il BID più basso.
Per variare la bridge-priority (e quindi forzare o meno l’elezione a root-bridge):
S(config)# spanning-tree vlan VLAN-ID priority <0-61440> → N.B. Di default è 32.768.

VLAN

 

Le ACCESS PORTS non creano loops perchè non sono connesse ad altri switches, sono connesse ad hosts terminali all’interno di una singola vlan.
Le TRUNKING PORTS possono connettersi ad altri switches e trasportano dati di varie vlans, quindi potenzialmente possono creare loops.

Vlan statiche

L’amministratore configura manualmente su ogni switch le vlan e le relative porte.
Vlan dinamiche
Appartenere ad una vlan dinamica significa avere un VLAN management policy server (VMPS), che contiene un database che mappa i mac address con le relative vlan di appartenenza. Quando un dispositivo si collega allo switch, il VMPS legge il mac e lo associa ad una certa vlan.

Creare una vlan:

S(config)#vlan <vlan_number> → assegno un numero alla vlan
S(config-vlan)#name <vlan_name> → assegno un nome alla vlan (è una best practice)
S(config)#exit
Assegnare una porta alla vlan:
S(config)#interface fa#/#
S(config-if)#switchport access vlan <vlan_number>
S(config)#exit
Assegnare un range di porte alla vlan:
S(config)#interface range fa#/start_of_range – end_of_range
S(config-if)#switchport mode access
S(config-if)#switchport access vlan <vlan_number>
S(config)#exit
Vari show:
S#show vlan → resoconto dettagliato delle vlan (possibile anche show vlan ID o show vlan NAME)
S#show vlan brief → resoconto più essenziale

IEEE 802.1Q (sintetizzato: dot1q)→ è lo standard per il frame tagging, grazie al quale il frame viene taggato con un campo di 4 byte che identifica la vlan di appartenenza e quindi permette il trunking (il passaggio dei frame da una vlan ad un’altra, quasi come fosse un routing).
Col protocollo 8201q il traffico non taggato diviene appartenente alla vlan nativa (VLAN1 di default).
Porte: access (interne ad una vlan, connesse a devices finali) o trunk (traffico inter-vlan, connesse ad altri switch, standard dot1q – dai Catalyst 6500 series viene supportato anche lo standard Cisco ISL).

Configurare porta trunk:

S(config)#interface fa#/#
S(config-if)#switchport mode trunk
S(config)#switchport trunk encapsulation <dot1q | isl | negotiate> (negotiate negozia l’encaps. di default)
Gli ultimi switch permettono anche il modo dynamic <desirable | auto> → in molti Cisco dot1q è già di default, quindi non occorre configurare quest’ultima parte del protocollo dot1q

Cambiare la vlan nativa (dalla 1 che è quella di default):

In ognuna delle porte trunk :
S(config-if)#Switchport trunk native vlan <vlan_ID>
Quando si cambia la vlan nativa è anche necessario configurare la subinterfaccia del router relativa alla vlan nativa, con:
R(config-subif)# encapsulation dot1q <native_vlan_id> native
Configurazione sotto-interfacce router:
Nella parte di confine, generalmente siamo connessi ad una interfaccia fastethernet del router, che riceve il link trunk dallo switch, e che funge da gateway per le vlan. Su quel link viaggeranno frame provenienti da vlan diverse, quindi con ip diversi. Per questo motivo configurerò varie sottointerfacce logiche di una stessa interfaccia fisica, a cui assegnerò ip address ed encapsulation dot1q. Ecco un esempio:
S(config)#interface fa0/2
S(config-if)#switchport mode trunk
S(config)#switchport trunk encapsulation dot1q
Poi sul router:
R(config)#interface fa 0/1
R(config-if)#no ip address
R(config-if)#no shutdown

R(config)#interface fa 0/10 → numero sottointerfaccia (0/10)
R(config-subif)#encapsulation dot1q 10 → tipo incapsulazione e numero vlan (10)
R(config-subif)#ip address 192.168.10.1 255.255.255.0 – indirizzo rete assegnata alla vlan 10.

Configurare la vlan per il management:

S(config)# interface vlan1 → è la management di default
S(config-if)#ip address <ip address> <subnet mask>
S(config-if)#no shutdown
S(config-if)#exit
S(config)#ip default-gateway <gateway ip address> → setta il default gateway
S(config)#end

Sicurezza: disabilitare funzione http server e shuttare tutte le porte non utilizzate:
S(config)#no ip http server

S(config)#interface range fastethernet 0/2 – 5 , fastethernet 0/11 – 24
S(config-if-range)#shutdown
S(config-if-range)#end

MAC ADDRESS STATICO

S(config)#mac-address-table static <mac address> vlan 1 interface fastethernet <n. porta, es 0/4> → configura il mac collegato all’interfaccia dello switch

STATIC SWITCH PORT SECURITY

S(config)# interface <type> <number>
S(config-if)# switchport mode access
S(config-if)# switchport port-security mac-address <mac address abilitato ad usare interfaccia>
S(config-if)# end

DYNAMIC SWITCH PORT SECURITY

S(config)# interface <type> <number>
S(config-if)# switchport mode access
S(config-if)# switchport port-security maximum <max num di mac che memorizzerà>
S(config-if)# switchport port-security → legge e stora il primo mac che si collega.
S(config-if)# end

STICKY SWITCH PORT SECURITY

S(config)# interface <type> <number>
S(config-if)# switchport mode access
S(config-if)# switchport port-security
S(config-if)# switchport port-security maximum <max num di mac che memorizzerà>
S(config-if)# switchport port-security mac-address sticky
S(config-if)# end → legge e stora i primi mac che si collegheranno e li stora nella startup-config

NB: per verificare la configurazione:
S# show port-security interface <type> <number> → impostazioni interf. specifica
S# show port-security → impostazioni generali della port-security
S# show port-security address → mostra tutti i mac memorizzati e quindi considerati sicuri

VTP (Vlan Trunking Protocol)

Permette la distribuzione e il management del database delle vlan da uno switch (o 2) che funge da server. Agisce all’interno di un dominio che ha nome univoco. Esiste la versione 1 (default) e la 2. La 1 non è compatibile con la 2.
Switches mode: VTP Server Mode (salva le vlan configuration information nella NVRAM e le invia attraverso le trunk port); VTP Client Mode (prende informazioni dal server e aggiorna le sue tabelle, se il numero di revisione dell’advertisement è superiore al proprio; inoltra poi i messaggi attaverso le trunk); VTP Transparent Mode (ignora tutte le informazioni ricevute pur inoltrandole sulle trunk; non manda aggiornamenti o richieste in seguito a variazioni nella propria vlan; è una sorta di “ripetitore”). Di default gli switches sono in server mode.
VTP Revision Number: per non incorrere in grossi problemi occorre azzerare il numero di revisione di uno switch prima di inserirlo in un dominio VTP → inserendolo in transparent mode e poi in client o server, oppure cambiando il nome di dominio vtp e poi rimettendo quello appropriato.
Tipi di messaggio VTP:
Summary advertisements: ogni 5 minuti o ogni volta che varia qualcosa nel dominio vtp; contengono nome di dominio vtp e il numero di revisione, che viene incrementato ad ogni variazione nel dominio vtp; gli switch che ricevono il summmary e si accorgono che il numero di revisione è più alto del proprio, lanciano un advertisement request.
Advertisemente requests: richiesta di informazioni sulla vlan.
Subset Advertisements: fornisce informazioni sulle vlan, permettendo agli switches di aggiornarsi.

VTP – Configurare lo switch server:

S1(config)# vtp domain <domain_name>
S1(config)# vtp mode server
S1(config)#vtp password <password> → facoltativo, è una best practice
S1(config)# end

VTP – Configurare lo switch client:

Dopo aver configurato le varie vlan, le porte access e quelle trunk:
S2(config)#vtp domain <domain_name>
S2(config)#vtp password <password> → facoltativo, è una best practice
S2(config)#vtp mode client

Aggiungere un nuovo switch al dominio VTP:

E’ buona prassi inserirlo dapprima il transparent mode, oppure con un altro nome di dominio, per azzerare i contatori del numero di revisione. Poi inserire i dati giusti.
S(config)# vtp domain <domain_name>
S(config)#vtp mode <server | client | transparent>
S(config)#vtp password <password>
S(config)#end
S#wr
S#show vtp status → per vedere il numero di revision number
S#show vlan → per vedere se ha preso le informazioni sulle vlan dal server (o se sono ben impostate)
S#show vtp password → per vedere la password
S#show vtp counters → per vedere i contatori dei messaggi vtp
S#reload → per rebootare lo switch

ROUTER CISCO e ROUTING in generale

 

Bootup process:

– POST: testa l’hardware e avvia il BOOTSTRAP
– Viene localizzato (nella flash memory come di default, ma anche in un tftp server o altrove, come indicato nella startup-config) , avviato e caricato l’IOS software nella ram.
– Viene localizzato ed eseguito lo startup configuration file (nella NVRAM) oppure, se questo non è trovato, entra in setup mode.
Tutte le variazioni sono inserite nella running-config (volatile: nella RAM)

R> show version → tutte le informazioni relative al software e all’hardware del dispositivo. C’è anche il configuration register che indica come deve bootare il dispositivo (es 0x2102: boot da flash in NVRAM)

Se non si avvia il router entra in rom-monitor dove è possibile dare i comandi:
dir flash → localizza l’IOS image, in modo da poter poi dare (ad esempio):
rommon1 > boot flash:c2600-is-mz.121-5

R#reload → riavvio del software de router

Troubleshooting se router non si avvia:

R> show version → controllo il configuration register
R> show startup-config → controllo se ci sono indicazioni di cercare l’IOS da qualche altra parte (cerco in boot system…)

Tipi di encapsulation:

HDLC (Hight-level data link control)
FRAME RELAY → percorso logico: quello fisico è shared fra + utenti
PPP (point to point protocol) → +costosa connessione diretta sempre attiva

Configurazione:

– in user exec mode (R>) posso dare vari show, ping, traceroute
– in privileged exec mode (R#) posso configurare tutti i parametri.
R> enable → entro in privileged exec mode (o semplicemente en)
R# configuration terminal (o conf t) → entro in modalità configurazione globale

Nominare il dispositivo
R(config)# hostname <hostname>

N.B. Al termine della configurazione salvare dalla RAM al disco:
R#copy running-config startup-config (oppure semplicemente wr)

Interfacce:
R(config)# interface <type> <number> → entro nella configurazione dell’interfaccia
R(config-if)#ip address <ip address> <subnet mask> → configuro indirizzo logico
R(config-if)#no shutdown → alzo l’interfaccia
R(config-if)#description <description> → permette di inserire descrizione (label) dell’interfaccia
Nel caso siano interfacce seriali vanno configurati anche l’encapsulation (hdlc, frame relay o ppp) e il clock (nella DCE (femmina); generalmente 56000 o 64000):
R(config-if)#encapsulation <encapsulation type>
R(config-if)#clock rate <clock rate>

R# show ip interface brief → vedi configurazioni logiche interfacce
R#show history → vedo ultimi 10 comandi della CLI
R#terminal history size → imposto quanti comandi deve tenere nella history
Vari show:
running-config –
interfaces (a livello 1 e 2) –
ip interfaces brief (a livello 3) –
arp –
ip route –
protocols (protocolli interfacce) –
ip protocols (protocolli di routing) –
version –
cdp neighbors (mostra i vicini) –
cdp neighbors detail (mostra tutti i dati dei vicini) –
session (mostra sessione telnet) –
ssh (mostra connessioni ssh)

R(config)#banner motd #x..y..z..# → setta messaggio da visualizzare al login del router
R(config)#banner login #x..y..z..# → simile a quello sopra

R(config)#logging synchronous →toglie messaggi non voluti dalla CLI
R(config)#no ip domain-lookup → impedisce al router di cercare di risolvere i nomi a lui sconosciuti collegandosi ad un dns server (fa perdere un sacco di tempo)

Password e security:

Passwords:
R(config)#enable password <password> → configura password di enable in chiaro
R(config)#enable secret <password> → configura password di enable criptata

R(config)#line console 0
R(config-line)#password <password>
R(config-line)#login → imposta password per la console

R(config)#line vty 0 4
R(config-line)#password <password>
R(config-line)#login

R(config)# service password-encryption → cripta tutte le password

Rotte:

Configurazione rotta default
R(config)# ip route 0.0.0.0 0.0.0.0 <GATEWAY(ip oppure interfaccia)>
Configurazione rotta statica
R(config)# ip route <IP> <MASK> <GATEWAY (ip next hop oppure interfaccia)>
Configurazione di una floating static routes (rotta statica di backup)
R(config)# ip route <IP> <MASK> <GATEWAY (ip oppure interfaccia)> 200 → 200=AD

DHCP

R(config)# ip dhcp pool <pool name or number (label)>
R(dhcp-config)# network <network address> <subnetmask>
R(config)#ip dhcp excluded-address <from ip addr> <to ip addr>
R(dhcp-config)# domain name <name>
R(dhcp-config)# dns-server <primary dns ip addr> <secondary dns server ip addr>
R(dhcp-config)# default-router <default gateway ip address> → default gateway dei clients
R(dhcp-config)# lease <days><hours><min> | <infinite>
R(dhcp-config)# end (or exit)

R# show ip dhcp binding → vedi indirizzi assegnati (utile per toubleshooting)
R# show ip dhcp conflict → visualizza eventuali conflitti nell’assegnazione indirizzi dhcp
Quando il dhcp server si trova in una subnet diversa da quella degli host, bisogna utilizzare in comando “ip helper-address <ip address>” sull’interfaccia gateway della lan degli host. In tal modo le richieste dhcp vengono forwardate al server dhcp e gli ip assegnati dal server stesso vengono anch’essi regolarmente forwardate verso gli host.
R(config-if)# ip helper-address <ip address>

BACK UP CONFIGURAZIONE SU TFTP SERVER I

R# copy startup-config tftp → vengono poi chiesti i parametri del server tftp

RESTORE LA CONFIGURAZIONE DA TFTP SERVER

R# copy tftp running-config

 

DEBUG

Per abilitare la modalità di debug (registra e visualizza il passaggio di pacchetti icmp, come i ping):
debug ip icmp
oppure genericamente
debug ip <protocollo (rip, icmp…)>

PROTOCOLLI DI ROUTING: RIP

AD:120
(Routing Information Protocol) – cat. “distance vector”, max 15 hops, small business-multiple routers
Updates su 224.0.0.9 (UDP port 520) con intera tabella di routing, ogni 5 secondi + triggered update. Summarizza di default.
Implementare RIP:
R( config)# router rip
R( config-router)# version 2
R( config-router)# network <prima rete da pubblicare>
R( config-router)# network <seconda rete da pubblicare> → etc. etc.
R( config-router)# end
Scelta di tipo di update (da configurazione interfaccia):
R( config-if)# ip rip send version <1 | 2 | 1 2>
R( config-if)# ip rip receive version <1 | 2 | 1 2>
R#debug ip rip → mostra in tempo reale tutti gli update inviati e ricevuti
Inserire rotta di default negli update:
R(config-router)# default-information originate
Inserire rotte statiche negli update:
R(config-router)# redistribute static
Impedire ad una interfaccia di inviare-ricevere update di routing:
R(config-router)# passive-interface <type> <number>
Vedere rotte conosciute dal protocollo rip:
R(config)# show ip rip database
Vede gli update in tempo reale:
R(config)# debug ip rip

PROTOCOLLI DI ROUTING: EIGRP

AD:90
Proprietario Cisco. cat. “distance vector”. Supporta VLSM and classless routing; MAX 224 HOPS;
La metrica è composta ed utilizza bandwidth, delay, reliability and load.
Usa il logaritmo DUAL per prevenire loop; veloce convergenza grazie agli bounded updates; mantiene tavole multiple; forma le aidacenze con i vicini; mantiene le rotte successor e feasible successor; fa il load balancing; usa vari tipi di pacchetti per una veloce convergenza; usa l’RTP (Reliable transport protocol) per il supporto a qualsiasi protocollo di Leyer 4. Summarizza di default.
– Ogni router manda periodicamente degli Hello Packets (multicast ogni 5 o 60 secondi) ai vicini per stabilire con loro l’adiacenza. Manda poi sempre ai vicini i Bounded Updates (multicast 224.0.0.10, vedi più sotto): degli aggiornamenti solo relativi ai cambiamenti nelle reti di sua pertinenza. I vicini aggiornano la loro table e inoltrano a loro volta i cambiamenti ai loro vicini.
Ogni route ha tre table:
1. neighbor table: con le informazioni dei router direttamente connessi e relative interfacce e indirizzi ip → show ip eigrp neighbors details
2. topology table: con informazioni su tutte le rotte imparate da ogni vicino. DUAL calcola le rotte con minore costo, dette successor. Tra le successor (con costo uguale o anche diverso) fa il load balancing. Calcola anche le feasible successor, rotte di backup che vengono inserite nella route table, se la rotta primaria fallisce. N.B. Passive = rotta in funzione; Active = durante il ricalcolo di DUAL. Tra parentesi tonde troviamo (feasible distance/Advertised, o reported distance).
→ show ip eigrp topology
3. routing table: mostra solo le rotte “migliori”, le successor routes. Tra le quadre troviamo AD/feasible distance)

EIGRP updates nel dettaglio:
a. Acknowledgement: unicast, corrisponde ad un “ok, ricevuto!”
b. Update: info su cambiamento rete; se si forma nuova adiacenza sono in unicast, altrimenti multicast
c. query: inviato ai vicini de una rotta cade. Aiuta DUAL a calcolare la nuova successsor; uni o multicast
d. Reply: unicast, risposta ad una query.
Implementare EIGRP:
E’ necessario dare a EIGRP il numero di AS:
R( config)# router eigrp <AS_number> → <AS_number> da 1 a 65535
R( config-router)# network <prima rete da pubblicare>
R( config-router)# network <seconda rete da pubblicare> → etc. etc.
R( config-router)# exit
disabilita auto summarizzazione:
R(config-router)# no auto-summary
Summarizzazione manuale:
R(config)#interface <type> <number>
R(config-if)#ip summary-address eigrp <AS_number> <rotta sammarizzata> <subnetmask>
Criptazione degli updates, con md5:
Da impostare su tutti i router che partecipano ad eigrp
R(config)#key chain <keychain> → imposta il portachiavi
R(config-keychain)#key 1 → entro in configurazione chiave (o password)
R(config-keychain-key)# key-string <key_string> → imposto la key-string (o password)
R(config-keychain-key)#end
R(config)# interface <type> <number>
R(config-if)# ip authentication mode eigrp <AS_number> md5 → configuro metodo criptazione sul link
R(config-if)# ip authentication key-chain eigrp <AS_number> <keychain> → applico la password al link

PROTOCOLLI DI ROUTING: OSPF

AD:110

Link-state protocol. Divide il network in aree (ogni area: max 50 routers). Tutte le aree costituiscono l’OSPF autonomous system. Manda update solo quando si verificano dei cambiamenti nella rete. Un full-update è previsto solo ogni 30 minuti. Ogni router genera una mappa completa di tutta la rete, vista dal suo punto di vista. NON summarizza automaticamente. La metrica è basata sulla bandwidth. Più alta è la bandwidth e più basso è il costo.

Fastethernet and faster costo: 1
ethernet costo: 10
E1 costo: 48
T1 costo:64
512 kbps costo: 195
256 kbps costo: 390
128 kbps costo: 781
64 kbps costo: 1562
56 kbps costo: 1785

Ogni router manda ai suoi vicini gli LSA (link-state advertisements) con informazioni sullo stato dei suoi links. Quando un router riceve le indormazioni su tutti i link dell’area, utilizza l’SPF algorithm (Dijkstra’s alg.) per generare un topological tree, a map of the network. Ogni router vede se stesso come root di quell’albero. Il topology database stora le informazioni del SPF tree. Le rotte con minore costo vengono inserite nella routing table.
La convergenza avviene quando:
1. tutti i router ricevono informazioni su ogni destinazione della network
2. SPF alg. ha processato tutte queste informazioni
3. tutte le routing tables sono state aggiornate.
Gli update sono inviati solo quando avvengono dei cambiamenti nella rete.
Ogni router stringe con i vicini una adiacenza, che è full quando hanno sincronizzato pienamente i loro database e tutti i settings matchano.
L’adiacenza inizia con un hello packet (multicast 224.0.0.5 – ogni 10 secondi in ethernet, ogni 30 secondi per link non broadcast).
In un ambiente broadcast, per diminuire la quantità di traffico, OSPF nomina un designated router (DR) e un backup designated router (BDR). DR e BDR ricevono da tutti gli update (sul multicast 224.0.0.6) e poi li diffondono a tutti (al multicast 224.0.0.5). Gli altri router sono detti DROther.
Viene eletto DR il router con il router-ID più alto. Il secondo viene eletto BDR.
Il router ID è un indirizzo ip che viene determinato:
1. manualmente con il comando router-id
2. se non viene settato un router id, viene preso l’indirizzo più alto delle loopback
3. se non ci sono loopback alzate, viene preso l’indirizzo più alto delle interfacce fisiche SIA CHE PARTECIPINO ALL’AREA OSPF, SIA CHE NON PARTECIPINO.
Per forzare l’elezione di DR e BDR, si può usare il comando ip ospf priority number (da 0=non verrà mail eletto a 255=elezione sicura).
Reti identificate da OSPF:
1. Broadcast multiacces networks (Ethernet): vengono eletti DR e BDR
2. Point to point networks (serial, T1/E1): non vengono eletti DR e BDR
3. NBMA – Nonbroadcast multiaccess networks (Frame Relay, ATM): due possibilità per OSPF:
a. Simulated broadcast environment: viene simulato un enrironment broadcast, con elezione di DR e BDR. I neighbors devono essere definiti staticamente.
b. Point-to-point environment: niente elezione di DR e BDR. I neighbors devono essere definiti staticamente.
Implementare OSPF:
E’ necessario dare a OSPF un numero di processo (con valore solo locale), e alla rete il numero di area:
R( config)# router ospf <processo_id> → <processo_id> da 1 a 65535
R( config-router)# network <network_address> <wildcard-mask> area <area_id>
R( config-router)# exit
Autenticazione criptata con md5 (esempio)
R(config)# interface serial 0/0/0
R(config-if)# ip address 10.1.1.1 255.255.255.0
R(config-if)# ip ospf message-digest-key 10 md5 areapassword
R(config)# router ospf 18
R(config-router)# network 10.1.1.0 0.0.0.255 area 0
R(config-router)# area 0 authentication message-digest

R(config)# interface serial 0/0/0
R(config-if)# ip address 10.1.1.2 255.255.255.0
R(config-if)# ip ospf message-digest-key 10 md5 areapassword
R(config)# router ospf 25
R(config-router)# network 10.1.1.0 0.0.0.255 area 0
R(config-router)#area 0 authentication message-digest

Configurare l’interface priority:
R(config)#interface <type> <number>
R(config-if)# ip ospf priority <priority_number> → da 0 a 255 (0=mai bridge 255=sicuramente bridge)
Configurare il router id:
R(config)# router ospf 1
R(config-router)# router-id 10.1.1.1
N.B. Dopo aver variato il router id o la priority di un’interfaccia, è necessario dare un clear ip ospf process perchè i cambiamenti abbiano effetto.
Configurare l’OSPF cost:
R(config)#interface <type> <number>
R(config-if)#bandwidth <56 | 64 | 256 |…>
Configurare l’OSPF bandwidth:
R(config)#interface <type> <number>
R(config-if)#ip ospf cost <cost-number>
Inserire rotta di default negli update:
R(config-router)# default-information originate
Summarizzare le rotte OSPF sull’ASBR (esempio):
R(config-router)#area 0 range 192.168.0.0 255.255.252.0
Debug:
R#debug ip ospf events
Alcuni show:
R#show ip ospf neighbor
R#show ip ospf
R#show ip ospf interface

DISTRIBUIRE LE ROTTE OSPF SU RIP

Sul router su cui gira sia RIP che OSPF
R(config)#ruoter rip
R(config-router)#version 2
R(config-router)#redistribute ospf <ospf_process_number> metric <1-16 =metrica con la quale rip leggerà le rotte importate da ospf>

WAN

 


DCE: data commun. equipment – DTE: data terminal equipment → physical layer protocol: X.21/V.35 …
physical layer protocol:
– EIA/TIA-232: up to 64 kbps – 25-pin D connector
– EIA/TIA-449-530: up to 2 Mbps – 36-pin D connector
– EIA/TIA-612-613: up to 52 Mbps – 60-pin D connector
– V.35: up to 48 kbps – 34-pin rectangular connector
– X.21: standard for synchronous digital communications – 15-pin connector

Link speed: DS0: standard a 64 kbps – DS1: T1 a 1544 Mbps – DS3: T3 a 44736 Mbps
E1 = 32 DS0s up to 2048 Mbps
E3 = 16 E1s up to 34064 Mbps

La bandwidth di un link non dedicato viene divisa dall’ISP in più DS0s per i vari customers. La suddivisione avviene in base a slot di tempo:

- TDM (time-division multiplexing) → vede slot di tempo pre-assegnati; spesso è causa di sprechi di banda

- STDM (statistical time-division multiplexing) → slot di tempo assegnati al “bisogno”: una intelligent device tiene traccia delle conversazioni e determina se una conversazione ha bisogno di più o meno banda.

Tipi di connessioni:

Dedicated leased line: point to point serial link between two routers
Circuit switching: simile alla telefonata tradizionale, viene stabilito un circuito dedicato al momento della chiamata che resta su fino al suo termine. Costo in base alla distanza e al tempo di chiamata. Ottimo livello di sicurezza.
Packet switching (es. Frame Relay): I dati sono fragmentati in pacchetti sui quali vengono inseriti gli identificativi che identificano la rotta che devono seguire. Il processo è simile al routing e ai relativi protocolli. I circuiti a volte sono preconfigurati, ma sono condivisi fra più organizzazioni, non sono mai esclusivi.
Cell Switching (es. ATM): le celle sono pacchetti di piccoli di dimensioni sempre uguali (53 byte: 48 data+5 header), quindi vengono switchati velocemente, ma producono overload per i dispositivi che devono analizzare molti più pacchetti.

Nel packet switching:
SVC (Switched virtual circuit): circuito stabilito dinamicamente al momento della richiesta di trasmissione. Connessione tirata su al momento della richiesta e tirata giù al termine. Porta delay nella network.
PVC (Permanent virtual circuit): il path è permanente. E’ migliore dell’SVC, più diffuso, generalmente utilizzato dal Frame Relay.

Layer 2 serial line encapsulation:

— HDLC: synchronous serial, bit-oriented data link, usa acknowledgement e windowing scheme. Ogni frame usa lo stesso formato: flag, address, control, information, FCS, flag. Lo standard non contiene un campo per il tipo di protocollo. Per questo non può trasportare protocolli multipli sullo stesso link. Il proprietario CISCO HDLS ( di default sui router Cisco) aggiunge invece un campo con l’indicazione del tipo di protocollo (campo “type”: protocol code) che quindi abilita multipli network layer protocols a condividere lo stesso link. Per questa differenza non è possibile abilitare HDLS su ambienti multi vendor (Cisco ed altri).

— PPP: funziona su interfacce Asynchronous/Synchronous serial, HSSI, ISDN.
Ha due subprotocolli:
– a. LCP (Link Control protocol) che stabilisce, mantiene, testa, temina il link ppp, oltre a negoziare e configurare le opzioni di controllo del link wan. La negoziazione prevede le fasi: authentication (PAP, CHAP), Callback, Compression, Multilink
– b. NCP (Network Control Protocol) che incapsula i dati permettendo multipli network layer protocols. Ogni protocollo richiede un diverso NCP.
Fasi di una sessione ppp:
Link-establishment phase: prima negoziazione di LCP; alla fine un acknowledgement dà l’ok
Authentication phase: (opzionale) NCP attua l’autenticazione
NCP negotiating phase: quando LCP ha stabilito che la qualità del collegamento è abbastanza buona per trasportare dati di livello 3 e l’autenticazione opzionale ha avuto esito positivo, ppp invia i pacchetti NCP per configurare uno o più protocolli di rete.
Configurazione di ppp:
R(config-if)# encapsulation ppp
R(config-if)# compress <predictor | stac> → stacker= + cpu – memoria ; predictor= + memoria – cpu
R(config-if)# ppp multilink

vari show:

R# show interfaces serial → incapsulazione e stato di LCP
R# show controllers → stato canali delle interfacce, DCE/DTE protocollo relativo, clock rate…

Autenticazione ppp:
PAP Password Authentication protocol: two way handshake, password circola in chiaro
CHAP Challenge Handshake Authentication protocol: la password non viene trasmessa in rete. Viene trasmessa solo una stringa testo random che viene criptata con la password impostata dall’utente e che deve essere uguale per i due router. Autenticazione ripetuta più volte in breve spazio di tempo.
Fasi:
challenge → viene inviata stringa testo random
response → risposta: stringa criptata con password condivisa
Accept/Reject → se il primo router verifica la giustessa della criptazione acceta, altrimenti rifiuta e cade link

Configurare l’autenticazione ppp:
R(config)# username <name> password <password> → hostname del vicino + password comune
R(config-if)# ppp authentication <chap | chap pap | pap chap | pap>
→ fine configurazione chap o pap
Solo nel pap dall’IOS Cisco Release 11.1:
R(config)# ppp pap sent-username <name> password <password>

Vari debug: debug ppp <authentication|packet|negotiating|error|chap>

— FRAME RELAY: la frame relay è una NBMA. Usa packet switching, STDM per ottimizzazione della banda disponibile, PVC che il provider preconfigura. Per funzionare deve avere un modo per associare il VC con un indirizzo di livello 3. Questo avviene con l’INVERSE ARP.
Inverse Arp: associa un DLCI (identificativo di un certo VC, ma con valore solamente locale, presente in ogni frame inviato) con un certo ip address remoto.
LMI (Local Management Interface): gestisce e mantiene lo stato di una connessione tra il DTE e un Frame Relay switch (DCE), quindi del VC. La connessione del VC può essere in:
active state → tutto ok
Inactive state → connessione locale al DCE è ok, ma non quella della connessione remota, sempre al DCE
Deleted state → nessun LMI ricevuti dal farme relay switch, o non c’e servizio tra la DTE e la DCE.
Parametri negoziati con l’ISP:
CIR – Committed information rate: minimum bandwidth rate guaranteed
Tc – Committed time: calculated time inrval
Bc – Committed burst: number of comitted bits within the Tc
EIR – excess information rate: rate massimo (superiore al normale) che il VC può supportare in caso di no congestion. Questi extra bits sono detti Be – excess burst (“scatti extra”). I frame inviati “extra” sono detti DE – descard eligible. Se ci sono congestioni i frame sono droppati.

FECN – forward explicit congestion notification: campo ad 1 bit settato da uno switch. Indica che una DTE è congestionato
BECN – backward explicit notification: simile al FECN, indica che la entwork è congestionata nella direzione opposta.
FECN e BECN permettono al livello applicazione di agire intelligentemente di conseguenza.

Configurazione del Frame Relay (limitatamente ai routers cpe):
Entro nell’interfaccia, do “no ip address” e imposto l’encapsulation frame-relay. Poi creo la subinterfaccia impostandola come point to point oppure multipoint, configuro l’ip address, e imposto il numero di dlci. Es:
R(config)# int se0/0/0
R(config-if)# no ip address
R(config-if)# ensapsulation frame-relay
R(config-if)# end
R(config)# int se0/0/0.101 point-to-point (oppure multipoint)
R(config-subif)# frame-relay interface-dlci 20
R(config-subif)# end

ACL

 


Guidelines:
Configurare solo una ACL per protocollo, per direzione
Standard 1-99 1300-1399 → vicino alla destinazione
Extended 100-199 2000-2699 → vicino alla sorgente
Named → va indicato se sono standard o extended
Determinare correttamente se inbound o outbound, dal punto di vista dell’interno del router
Gli statements sono letti dal primo all’ultimo e alla fine c’è un implicito deny any any
Inserisci gli statements dal più specifico al più generale
Ciò che proviene dall’interno del router non è processato dalle ACL

Realizzare l’ACL:
St. → R(config)# access-list <ACL_number> <deny | permit> <source address> <source_wildcard> <log>
Ext → R(config)#access-list <ACL_number> <deny | permit> <protocol-type> <source address> → cont: <source_wildcard> <host | any> <dest_address> <dest_wildcard> <eq | gt | lt | range> <appl_protocol_type>
Named → R(config)# ip access-list <standard | extended> <named_name> → poi di seguito inserire gli statements senza ripetere ogni volta la dicitura iniziale.

Nelle nuove IOS è possibile cambiare una sola o più righe degli statements, senza dover riscrivere tutta l’ACL. Il comando è:
R(config)# ip access list → dare poi il comando no line number <xy> e riscrivere la riga usando il numeRo della riga cancellata.
Per inserire una riga nuova:
basta dare l’input con il numero di riga intermedio rispetto alla riga precedente e successiva.
es. 20 permit ip 192.,168.1.77 any

Configurare una label (remark):
R(config)# access-list <ACL_number> remark <remark_text>

Applicazione dell’ACL all’interfaccia:
R(config-if)# ip access-group <ACL_number> <in | out>
Applicazione dell’ACL all’interfaccia vty:
R(config-line)#access-class <ACL_number> <in | out>

wildcard mask 0.0.0.0 = host → indicano un host specifico
wildcard mask 255.255.255.255 = any → tutti gli host di quella rete
0.0.0.0 255.255.255.255 = any → tutti gli host di tutte le reti

Established traffic:
Permette solo il traffico che è risposta ad una richiesta proveniente dall’interno della rete:
esempio: R(config)# access-list 101 permit tcp any any established

Per vedere tutte le access list:
R# show access-list

I log creati dalle ACL quando alla fine dello statement viene inserito il comando log, per il syslog sono di tipo informational.
Nelle Cisco IOS sono possibili altre ACL oltre le standard e le extended (e le named). Queste sono le:
Dynamic ACL: dette anche “lock and key”, richiedono all’utente che si collega via telnet di loggarsi (autenticarsi)
Reflexive ACL: simili alle extended “established” ma ispezionano non solo il traffico tcp ma anche quello UDP e ICMP
Time-based ACL: permettono o negano il traffico basandosi sull’ora e sul giornodella settimana.

CDP (Cisco Discovery protocol)

Tool (presente e attivo di default) per avere info su altri dispositivi direttamente connessi
R# show cdp neighbors → da info su dispositivi, interfacce, raggiungibilità
R# show cdp neighbors detail → da tutte le informazioni possibili anche sul software, ind. Logici…)
R# no cdp run → disabilita cdp
R(conf-if)# no cdp enable → disabilita cdp solo per l’interfaccia dove ci si trova
R# cdp run ->avvia cdp
R(conf-if)#cdp run enable –>avvia cdp su quell’interfaccia

NAT

 


inside local address – inside global address / outside local address – outside global address
static nat: 1 indirizzo privato viene traslato in 1 indirizzo pubblico
dynamic nat: un host della rete interna riceve un indirizzo pubblico tra un pool di indirizzi pubblici disponibili al router.
Nat overload or pat (port-based address translation): più hosts della rete interna ricevono lo stesso indirizzo pubblico, che è l’indirizzo dell’interfaccia verso l’esterno della rete → è il più comunemente utilizzato

Nat Statico (1 indirizzo interno nattato in 1 indirizzo pubblico)
R(config)# interface <type> <number> → entro nella configurazione dell’inside interface
R(config-if)# ip address <ip address> <subnet mask>-> configuro ind. logico (se non già fatto)
R(config-if)# ip nat inside
R(config-if)# exit

R(config)# interface <type> <number> → entro nella configurazione dell’outside interface
R(config-if)# ip address <ip address> <subnet mask> → configuro ind. logico (se non già fatto)
R(config-if)# ip nat outside
R(config-if)# exit

R(config)# ip nat inside source static <inside address> <outside address>
N.B. Per verificare le translazioni NAT: R# show ip nat translations

Nat dinamico (1 indirizzo interno ne riceve uno pubblico da un pool di indirizzi pubblici)
R(config)# Access-list 1 permit <indirizzo rete> <wildcard>
R(config)# ip nat pool NAT-1 <primo ind. NAT disponibile> <ultimo ind. NAT disponibile> netmask <netmask>
R(config)# ip nat inside source list 1 pool NAT-1 overload
R(config)# interface <type> <number>
R(config-if)# ip nat inside
R(config)#interface <type> <number>
R(config-if)#ip nat outside

Nat dinamico – PAT (al pool di indirizzi interni viene assegnato l’indirizzo dell’interfaccia esterna)
(config)# Access-list 1 permit <indirizzo rete> <wildcard>
R(config)# ip nat inside source list 1 interface <type> <number> overload
R(config)# interface <type> <number>
R(config-if)# ip nat inside
R(config)#interface <type> <number>
R(config-if)#ip nat outside

R# show ip nat translations
R# clear ip nat translation → cancella le translazioni in atto
Intranet: rete privata utilizzata per fornire accesso a dipendenti da locale e da remoto, via LAN e vi WAN. Contiene dati anche molto riservati ed è disegnata quindi per i dipendenti dell’azienda.
Extranet: rete privata pensata per fornitori e clienti esterni all’azienda. I dati in essa contenuti sono generalmente meno confidenziali. Ci si connette tramite WAN, con login da remoto o tramite VPN. Non è una public network.

Enterprise network documentation

 


Physical topology
Logical topology
Control Plane: describes failure domains and interfaces where different network technology intersect.

Business Continuity Plan (BCP): cosa fare per evitare che, in caso di disastro, il business non si interrompa. Backup remoto, centri di controllo alternativi, ridondanza delle comunicazioni.
Business Security Plan (BSP): applicazione policy di sicurezza, previene accessi non autorizzati.
Autenticazione, Software ammesso, accesso remoto, monitoraggio intrusioni…
Network Maintenance Plan (NMP): Manutenzione per mantenere sicuro e stabile il sistema. Definisce:
timing della manutenzione, schedulazione dei downtime, responsabilità dello staff, dispositivi e software da manutenere, monitoraggio delle performance della rete
Service-Level Agreement (SLA): contratto con l’ISP. Prevede: velocità e banda, network uptime, monitoraggio delle performance della rete, tempi di risposta per risoluzione dei problemi, responsabilità.

Samba 4 as Active Directory Domain Controller

In questo articolo configureremo samba 4 come domain controller. Da precisare che tale configurazione potrà prevedere samba 4 come unico gestore del dominio oppure come domain controller aggiunto ad un dominio Active Directory Windows preesistente.
La documentazione di riferimento è quella ufficiale:Samba_AD_DC_HOWTO per la prima soluzione e Join_a_domain_as_a_DC per la seconda. Aggiungerei anche questa tagliata su Ubuntu 14.04 e personalmente testata con successo.

1. Preparazione

Partiamo da una installazione di Ubuntu 14.04 server senza interfaccia grafica. Durante l’installazione sceglieremo solamente di aggiungere il server ssh (Openssh-server).  Per semplicità io generalmente opto per abilitare l’utente root e poter lavorare senza dover ogni volta ulitizzare il sudo. Quindi:

$ sudo passwd root
 [sudo] password for luca:
 Inserire nuova password UNIX:
 Reinserire la nuova password UNIX:
 passwd: password aggiornata correttamente
 $ su -
 Password:
 #

In tal modo lavoreremo come root. Aggiorniamo il sistema:

# apt-get update && apt-get upgrade

2. Installazione e configurazione di samba

2.1 Installazione prerequisiti di samba come DC

# apt-get install attr build-essential libacl1-dev libattr1-dev libblkid-dev libgnutls-dev libreadline-dev python-dev libpam0g-dev python-dnspython gdb pkg-config libpopt-dev libldap2-dev dnsutils libbsd-dev attr krb5-user docbook-xsl libcups2-dev acl ntp

Durante l’installazione di Kerberos verranno richiesti alcuni parametri. Sostanzialmente quelli relativi alla mia configurazione sono:

Realm=DOMINIOSAMBA.IT / Server=samba4 (o anche samba4.dominiosamba.it)

2.2 Configurazione di rete e ntp

Settare un ip statico in /etc/network/interfaces ed aggiungerci come dns server l’ip del server stesso + l’ip di un server dns esterno (generalmente quello del nostro provider) + l’indicazione del dominio:

# vim /etc/network/interfaces

# The primary network interface
auto eth0
iface eth0 inet static
     address 192.168.201.136
     netmask 255.255.255.0
     gateway 192.168.201.20
     dns-nameservers 192.168.201.136 8.8.8.8
     dns-search dominiosamba.it

Ovviamente i dati relativi agli indirizzi dovranno essere adattati alla vostra rete.

Settare l’hostname (in /etc/hostname) in modo congruente, nel mio caso “samba4″.

Visto che samba fa uso di attributi di filesystem che generalmente ext3/4 non supportano, occorre indicarli in /etc/fstab. Qualcosa del tipo:

#questa è la partizione dove risiede samba:
UUID=xyzxyzxy-xyzx-xyzx-x    /    ext4     errors=remount-ro 0 1
#Occorre aggiungere qualche parametro:
UUID=xyzxyzxy-xyzx-xyzx /    ext4     user_xattr,acl,barrier=1,errors=remount-ro 0 1

Ora settare /etc/hosts con qualcosa del tipo:

# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 samba4.dominiosamba.it samba4
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

2.3 Configurazione ntp

# service ntp stop

In /etc/ntp.conf aggiungere il proprio server ntp (nel mio caso 192.168.17.22), altrimenti lasciare quelli di default (ntp server di ubuntu.pool.ntp.org):

# vim /etc/ntp.conf
  Continue reading 

Freeradius: AD domain users authentication and filter by domain groups

L’obiettivo è quello di permettere l’autenticazione radius di utenti di dominio per l’accesso telnet ad uno o più apparati di rete. Nel mio caso utilizzerò uno switch C2960. L’accesso dovrà essere consentito solamente agli utenti appartenenti ad un determinato gruppo del dominio e dovrà fornire loro il livello 15 di privilegi (il massimo livello).

Freeradius grazie all’utility samba ntlm_auth consentirà l’autenticazione degli utenti del dominio.

Prima di iniziare consiglio la lettura attenta di questo sito per comprendere i metodi di autenticazione di Freeradius. Se l’avessi letto io quando ho iniziato la configurazione la prima volta avrei risparmiato davvero tanto tempo. La documentazione seguita: wiki ufficiale, simweb.ch,  e alcune indicazioni contenute in freeradius.1045715…, in particolare per lo script scritto da Scott McLane Gardner.

Questo articolo presuppone che abbiate già a disposizione un dominio active directory gestito (in esclusiva o inserito in un dominio Windows pre-esistente) da samba 4. Questo articolo vi spiegherà passo passo come fare.

Freeradius andrà installato sullo stesso server, nel mio caso Ubuntu 14.40 LTS Server.

1. Installazione e configurazione freeradius

Iniziamo con l’installazione di alcune dipendenze necessarie a freeradius

# apt-get install snmp libtalloc-dev libssl-dev

Ora scarichiamo i sorgenti di openssl e di freeradius direttamente dai siti ufficiali oppure dal mio server: openssl-1.0.1j.tar e freeradius-server-3.0.4.tar

Ci spostiamo nella directory dove abbiamo scaricato gli archivi e  compiliamo e installiamo openssl:

# tar -xvf openssl-1.0.1j.tar 
# cd openssl-1.0.1j/
# ./config --prefix=/usr/local/openssl shared
# make
# make install

Il primo comando scompatta l’archivio tar, il secondo ci fa entrare nella directory scompattata, il terzo esegue uno script di shell che fa un check per i requisiti di sistema, il quarto costruisce i binari (richiede un po’ di tempo), il quinto esegue le istruzioni di installazione.

Ora è la volta di freeradius:

# tar -xvf freeradius-server-3.0.4.tar 
# cd freeradius-server-3.0.4/
# ./configure
# make
# make install

Ora lavoriamo ai file di configurazione.

Entriamo nel file /usr/local/etc/raddb/clients.conf e alla fine inseriamo la rete dalla quale verranno le richieste di autenticazione, con la password di autenticazione e il nas_type:

# vim /usr/local/etc/raddb/clients.conf
....
client 192.168.201.0/24 {
 secret = testing123
 shortname = ReteCOS
 nas_type = cisco
 }
......

Ora modifichiamo il file /usr/local/etc/raddb/users, dopo aver salvato, per sicurezza, la versione originale:

# cp /usr/local/etc/raddb/users /usr/local/etc/raddb/users_orig

Inseriamo in users alcuni utenti di test (per i quali verrà bypassata l’autenticazione da dominio):

....
# The canonical testing user which is in most of the
# examples.
testuser1 Cleartext-Password := "testuser1!", MS-CHAP-Use-NTLM-Auth := 0
testuser2 Cleartext-Password := "testuser2!", MS-CHAP-Use-NTLM-Auth := 0
testuser3 Cleartext-Password := "testuser3!", MS-CHAP-Use-NTLM-Auth := 0
....

Notare che “MS-CHAP-Use-NTLM-Auth := 0″ indica proprio che l’autenticazione dell’utente indicato non dovrà essere processata da ntlm_auth ma avvenire “localmente” tramite il file di configurazione.

Verificare poi che il file di configurazione inner-tunnel contenga la seguente indicazione:

# cat /usr/local/etc/raddb/sites-available/inner-tunnel
...
...
authorize {
 ...
 # Read the 'users' file
 files # <--- questo
 ...
 pap # <--- e questo
}

Ora in /usr/local/etc/raddb/radiusd.conf, sezione security, aggiungere il parametro:
allow_vulnerable_openssl = ‘CVE-2014-0160′

# vim /usr/local/etc/raddb/radiusd.conf
...
...
security {
 allow_core_dumps = no
 max_attributes = 200
 reject_delay = 1
 status_server = yes
 allow_vulnerable_openssl = 'CVE-2014-0160' # <- questo parametro va confiurato
}
...

Ora possiamo effettuare un primo test, cercando di autenticare gli utenti che abbiamo inserito in “users”.

1.1 test autenticazione utenti in “file”

Avviamo il servizio radius in modalità debug:

# radiusd -X

Su altra macchina Linux installare le freeradius-utils per il test dell’autenticazione freeradius

$ sudo apt-get install freeradius-utils

NB Nel prossimo comando troviamo la parola chiave “testing123″, che dovrà essere configurata uguale in /usr/local/etc/raddb/clients.conf, nella sezione “client” che da poco abbiamo inserito.
Eseguire il test:

$ radtest testuser1 testuser1! 192.168.201.136 0 testing123
Sending Access-Request of id 197 to 192.168.201.136 port 1812
 User-Name = "testuser1"
 User-Password = "testuser1!"
 NAS-IP-Address = 127.0.1.1
 NAS-Port = 0
 Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 192.168.201.136 port 1812, id=197, length=20

L’autenticazione è riuscita.

1.2 Configurazione freeradius per autenticazione utenti di dominio

Per permettere a freeradius di autenticare gli utenti di dominio è necessario il binario ntlm_auth, fornito dal pacchetto “winbind”. Installiamo quindi winbind:

# apt-get install winbind

Testare l’autenticazione tramite binario ntlm_auth:

# ntlm_auth --request-nt-key --domain=DOMINIOSAMBA --username=administrator
Password: 
NT_STATUS_OK: Success (0x0)

e ancora:

# ntlm_auth --request-nt-key --domain=DOMINIOSAMBA.IT --username=pippo
assword: 
NT_STATUS_OK: Success (0x0)

Per altri test possiamo utilizzare wbinfo:

wbinfo -u -> lista tutti gli utenti di dominio
-u, –domain-users -> Lists all domain users
-g, –domain-groups -> Lists all domain groups
–user-info=USER-> Get user info
–user-groups=USER-> Get user groups
–authenticate=user%password-> authenticate user

Alcuni esempi:

# wbinfo --user-info=administrator
DOMINIOSAMBA\Administrator:*:0:100::/home/DOMINIOSAMBA/Administrator:/bin/false
# wbinfo --user-info=guest
DOMINIOSAMBA\Guest:*:3000011:3000012::/home/DOMINIOSAMBA/Guest:/bin/false
# wbinfo --user-groups=administrator
100
3000004
3000006
3000008
3000007

Ora configuriamo opportunamente il file di configurazione di ntlm_auth gestito da freeradius. Sostanzialmente inseriamo il path al binario e il nome del nostro dominio:

# vim /usr/local/etc/raddb/mods-enabled/ntlm_auth
exec ntlm_auth {
 wait = yes
 program = "/usr/bin/ntlm_auth --request-nt-key --domain=DOMINIOSAMBA.IT --username=%{mschap:User-Name} --password=%{User-Password}"
}

Se ora proviamo a fare il radtest di prima cercando l’autenticazione di un utente di dominio, l’utente non sarà autenticato. Analizzando il debug di freeradius (ottenuto avviandolo con l’opzione “-X”) si vedrà che il problema è relativo al fatto che freeradius non riesce a gestire correttamente la richiesta, non riuscendo ad identificare il tipo di autenticazione e dando quindi un:
(2) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject

$ radtest pippo pippo123! 192.168.201.136 0 testing123
Sending Access-Request of id 178 to 192.168.201.136 port 1812
 User-Name = "pippo"
 User-Password = "pippo123!"
 NAS-IP-Address = 127.0.1.1
 NAS-Port = 0
 Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Reject packet from host 192.168.201.136 port 1812, id=178, length=20

Il debug mostra:

.....
(2) WARNING: pap : No "known good" password found for the user. Not setting Auth-Type
(2) WARNING: pap : Authentication will fail unless a "known good" password is available
(2) [pap] = noop
(2) } # authorize = ok
(2) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject
.....
.....

Per risolvere il problema dobbiamo indicare a freeradius di utilizzare il protocollo PAP (possiamo quindi disabilitare tutto il resto) che a sua volta deve attivare il modulo ntlm_auth. O meglio: se l’Auth-Type non viene inviato dal client, aggiorna il “control” affinchè usi il proprio ntlm_auth che definito nella sezione authenticate.

fonte: http://www.simweb.ch/blog/2013/08/a-freeradius-for-your-switch-authentication/

Salviamo una copia del file default (sito di default) originale:

cp /usr/local/etc/raddb/sites-available/default /usr/local/etc/raddb/sites-available/default_orig

Poi tagliamo il contenuto della sezione “authorize” e “authenticate” incolliamo il contenuto seguente:

# vim /usr/local/etc/raddb/sites-available/default
authorize {
# If you are using multiple kinds of realms, you probably
# want to set "ignore_null = yes" for all of them.
# Otherwise, when the first style of realm doesn't match,
# the other styles won't be checked.
#
suffix

expiration
logintime
# Most switches support PAP only
 #
 # This module should be listed last, so that the other modules
 # get a chance to set Auth-Type for themselves.
 #
 pap
# If no Auth-Type was sent, we assume PAP but that we should
 # use ntlm_auth for AD authentication through ntlm_auth.
 if(!control:Auth-Type) {
 update control {
 Auth-Type = "ntlm_auth"
 }
 }
 }
authenticate {
 # For PAP against AD with ntlm_auth we need to
 # let Samba ntlm_auth do the authentication work.
 Auth-Type NTLM_AUTH {
 ntlm_auth
 }
># For local users with plaintext password we can still use LDAP
 # Reminder - you might disable update conrol in such casse in
 # authorize because it's an unconditinal update.
 Auth-Type PAP {
 pap
 }
 }

Se ora ripetiamo il test di prima otterremo la corretta autenticazione dell’utente:

$ radtest pippo pippo123! 192.168.201.136 0 testing123
Sending Access-Request of id 54 to 192.168.201.136 port 1812
 User-Name = "pippo"
 User-Password = "pippo123!"
 NAS-IP-Address = 127.0.1.1
 NAS-Port = 0
 Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 192.168.201.136 port 1812, id=54, length=20

E il debug di radiusd restituirà che nella fase di “authorize” (prima fase), freeradius non trova l’Auth-Type e quindi “sovrascrive” con “NTLM_AUTH”:

....
(0) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default
(0) authorize {
(0) suffix : Checking for suffix after "@"
(0) suffix : No '@' in User-Name = "pippo", looking up realm NULL
(0) suffix : No such realm "NULL"
(0) [suffix] = noop
(0) [expiration] = noop
(0) [logintime] = noop
(0) WARNING: pap : No "known good" password found for the user. Not setting Auth-Type
(0) WARNING: pap : Authentication will fail unless a "known good" password is available
(0) [pap] = noop
(0) if (!control:Auth-Type) 
(0) if (!control:Auth-Type) -> TRUE
(0) if (!control:Auth-Type) {
(0) update control {
(0) Auth-Type = NTLM_AUTH
(0) } # update control = noop
(0) } # if (!control:Auth-Type) = noop
(0) } # authorize = noop
(0) Found Auth-Type = NTLM_AUTH
(0) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
.....

L’Auth-Type NTLM_AUTH è configurato nella sezione “authorize” e quindi nella seconda fase di autenticazione freeradius lancia ntlm_auth seconda la configurazione che abbiamo precedentemente settato in /usr/local/etc/raddb/mods-enabled/ntlm_auth:

......
(0) Auth-Type NTLM_AUTH {
Executing: /usr/bin/ntlm_auth --request-nt-key --domain=DOMINIOSAMBA.IT --username=%{mschap:User-Name} --password=%{User-Password}:
(0) ntlm_auth : EXPAND --username=%{mschap:User-Name}
(0) ntlm_auth : --> --username=pippo
(0) ntlm_auth : EXPAND --password=%{User-Password}
(0) ntlm_auth : --> --password=pippo123!
Program returned code (0) and output 'NT_STATUS_OK: Success (0x0)'
(0) ntlm_auth : Program executed successfully
(0) [ntlm_auth] = ok
(0) } # Auth-Type NTLM_AUTH = ok
.......

La fase successiva e ultima, la fase “post-auth”, tutto procede senza problemi:

........
(0) # Executing section post-auth from file /usr/local/etc/raddb/sites-enabled/default
(0) post-auth {
(0) [exec] = noop
(0) remove_reply_message_if_eap remove_reply_message_if_eap {
(0) if (&reply:EAP-Message && &reply:Reply-Message) 
(0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE
(0) else else {
(0) [noop] = noop
(0) } # else else = noop
(0) } # remove_reply_message_if_eap remove_reply_message_if_eap = noop
(0) } # post-auth = noop
(0) Sending Access-Accept packet to host 192.168.201.205 port 36553, id=54, length=0
Sending Access-Accept Id 54 from 192.168.201.136:1812 to 192.168.201.205:36553
(0) Finished request
Waking up in 0.2 seconds.
Waking up in 4.7 seconds.
(0) Cleaning up request packet ID 54 with timestamp +5
.........

2. Configurazione dello switch Cisco 2960 series

In questa sede non indicheremo step by step la procedura per la configurazione del C2960 ma ci limiteremo a mostrare la running-config (configurazione principale) dalla quale si potranno facilmente dedurre i vari comandi da impartire all’apparato:

Switch#sh run
Building configuration...
Current configuration : 1727 bytes
!
version 12.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Switch
!
boot-start-marker
boot-end-marker
!
enable password password
!
username admin privilege 15 password 0 password
!
!
aaa new-model
!
!
aaa authentication login default group radius local
aaa authorization exec default group radius if-authenticated 
aaa accounting exec default start-stop group radius
aaa accounting system default start-stop group radius
!
!
aaa session-id common
system mtu routing 1500
!
!
spanning-tree mode pvst
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
!
interface FastEthernet0/1
!
(.....)
!
interface FastEthernet0/24
!
interface GigabitEthernet0/1
!
interface GigabitEthernet0/2
!
interface Vlan1
 ip address 192.168.201.5 255.255.255.0
!
ip default-gateway 192.168.201.20
ip http server
ip http secure-server
radius-server host 192.168.201.136 auth-port 1812 acct-port 1813
radius-server key testing123
radius-server vsa send authentication
!
line con 0
line vty 5 15
!
end

Da una qualsiasi macchina della rete possiamo accedere in telnet allo switch, utilizzando le utenze di dominio:

$ telnet 192.168.201.5
Trying 192.168.201.5...
Connected to 192.168.201.5.
Escape character is '^]'.


User Access Verification

Username: pippo
Password: 

Switch>

L’autenticazione è riuscita. Il livello di privilegi è però il più basso, come prova il simbolo “>” dopo l’hostname “Switch” dell’apparato.

3. Configurazione avanzata di freeradius per filtrare gli accessi ed assegnare livello 15 di privilegi sull’apparato di rete

Ora vogliamo che si possano loggare solo gli utenti appartenenti al gruppo “NetAdmins” e che si logghino direttamente al massimo livello di privilegi (level 15), ovvero in enable. Tutti gli altri utenti devono essere rifiutati.

Il livello massimo di privilegi assegnato agli utenti autenticati, si può semplicemente settare inserendo nella sezione “post-auth” (terza e ultima fase) sempre dello stesso file (/usr/local/etc/raddb/sites-enabled/default) queste poche righe:

post-auth {
....
          update reply {
                        Service-Type = Administrative-User
                       Cisco-AVpair = "shell:priv-lvl=15"
          }
....
}

Testiamo:

$ telnet 192.168.201.5
Trying 192.168.201.5...
Connected to 192.168.201.5.
Escape character is '^]'.

User Access Verification
Username: pippo
Password:
Switch#

OK: il segno “#” dopo “Switch” indica che l’utente viene automaticamente associato la livello di enable.

Ora vediamo come autenticare solo gli utenti appartenenti al gruppo “NetAdmins” del dominio.
Tramite Windows 7 e RSAT creiamo il gruppo “NetAdmins” e vi inseriamo il nuovo utente “pluto”.

Ora ricorriamo ad uno stratagemma, forse non molto “ortodosso” ma efficace: creiamo uno script basato su wbinfo che restituisca una stringa contenente i gruppi di appartenenza di un utente:
creiamo una directory che conterrà il nostro script:

mkdir /usr/local/etc/raddb/myscripts

ci entriamo e creiamo lo script get_groups.sh (grazie a Scott McLane Gardner):

 # cd /usr/local/etc/raddb/myscripts
# vim get_groups.sh
#!/bin/sh
 for T in $(wbinfo --user-domgroups `wbinfo -n $1`) ; do wbinfo -s $T |
perl -ne 'chomp and print'; done

a questo punto facciamo in modo che la sezione “post-auth” di /usr/local/etc/raddb/sites-enabled/default, lanci lo script passandogli come primo argomento lo username dell’utente che sta tentando l’autenticazione, sovrascrivendo in parte ciò che abbiamo settato nello step precedente. Se il match viene verificato l’utente viene accettato e gli vengono assegnati i privilegi level 15, altrimenti viene rifiutato:

# vim /usr/local/etc/raddb/sites-enabled/default
....
post-auth {
...
 if (`/bin/sh /usr/local/etc/raddb/myscripts/get_groups.sh %{User-Name}` =~ /NetAdmins/) {
 update reply {
 Service-Type = Administrative-User
 Cisco-AVpair = "shell:priv-lvl=15"
 }
 noop
 }
# No-one else is allowed.
 else {
 reject
 }
....

La restante parte della sezione deve rimanere invariata.

Come test conclusivo provo l’accesso telnet allo switch con le credenziali di pippo (utente non appartenente al gruppo “NetAdmins”):

$ telnet 192.168.201.5
Trying 192.168.201.5...
Connected to 192.168.201.5.
Escape character is '^]'.

User Access Verification

Username: pippo
Password:

% Authentication failed

Username:

giustamente l’autenticazione fallisce.
Se invece tento l’autenticazione dell’utente pluto (appartenente al gruppo “NetAdmins”), l’autenticazione andrà a buon fine e l’utente godrà dei privilegi livello 15:

$ telnet 192.168.201.5
Trying 192.168.201.5...
Connected to 192.168.201.5.
Escape character is '^]'.

User Access Verification

Username: pluto
Password:

Switch#

I file /etc/hosts e /etc/resolv.conf

Spunti da: good-linux-tips.com.

Il file /etc/hosts ha il compito di eseguire la risoluzione dei nomi: contiene entry dns statiche. Il sistema legge questo file prima di avviare le query dns ai server dns esterni. E’ quindi usato primariamente per definire alcuni hostname di macchine interne (locali) attestate sulla rete LAN.
Può anche essere usato per definire una sorta di brutale black-list per bloccare l’accesso della macchina a siti indesiderati: è sufficiente associare l’URL del sito indesiderato all’IP 127.0.0.1 (localhost) oppure allo 0.0.0.0.
Quando il sistema deve risolvere un nome, prima guarda le entry contenute in /etc/hosts. Se non trova alcun match invia la query dns al primo dns server disponibile così come listato nel file /etc/resolv.conf.

Sintassi file /etc/hosts
La prima colonna a sinistra contiene gli indirizzi ip. La seconda l’hostname.domainname (fqdn). La terza è un breve alias, generalmente corrispondente al solo hostname.
Le colonne sono separate da spazi o <tab>.

Esempio di un file /etc/hosts:

root@UbuOnMac:~# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 UbuOnMac.enterprise.it UbuOnMac
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Il file /etc/resolv.conf specifica i server dns esterni a cui il sistema si rivolge se non riesce a risolvere i nomi utilizzando /etc/hosts.
Un esempio di file /etc/resolv.conf è il seguente:

root@UbuOnMac:~# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 8.8.4.4
nameserver 151.99.125.2

In Ubuntu versione desktop (quindi con interfaccia grafica) la gestione della rete è interamente demandata all’applicativo “Network Manager”, quindi il contenuto di /etc/resolv.conf sarà un semplice puntamento al localhost.
Il file /etc/hosts viene invece letto in modo prioritario anche dalla versione desktop.

In ubuntu versione server (senza interfaccia grafica) il contenuto del file /etc/resolv.conf può essere modificato direttamente da qualsiasi editor di testo e le modifiche diverranno operative. Al riavvio della macchine, però, le modifiche andranno perdute, a meno che non si proceda come indicato di seguito:

– modificare il file /etc/resolvconf/resolv.conf.d/head aggiungendo i server dns desiderati:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 123.123.123.123
nameserver 321.321.321.321

– Aggiornare il file resolv.conf mediante il comando:

root@UbuOnMac:~# resolv.conf -u

Se si legge il file /etc/resolv.conf si troveranno inserite le nuove entry, confermate ad ogni riavvio.

Un altro modo molto utilizzato per settare i server dns esterni in modo permanente è quello di inserire delle entry “dns-nameservers” nel file principale di configurazione delle interfacce di rete /etc/network/interfaces. Ecco un esempio di tali entry:

# The primary network interface
auto eth0
iface eth0 inet static
 address 192.168.201.136
 netmask 255.255.255.0
 gateway 192.168.201.20
 dns-nameservers 192.168.201.136 151.99.125.2

Il file hosts di Linux è del tutto simile a quello di Windows.
Linux e Windows hanno anche una cache locale che stora le precedenti risoluzioni mantenendole in memoria fino alla scadenza del TTL del record dns.
Alcuni comandi Windows:

ipconfig /displaydns
ipconfig /flushdns

Per cancellare la cache dns in Ubuntu:

# /etc/init.d/dns-clean restart

 

Freeradius and Samba4: radius authentication of domain users

Il nostro obiettivo è quello di creare una piattaforma grazie alla quale sia possibile accedere agli apparati di rete (Cisco nel mio caso) utilizzando le credenziali di dominio.

A tal fine configureremo prima samba 4 come domain controller. Da precisare che tale configurazione potrà prevedere samba 4 come unico gestore del dominio oppure come domain controller aggiunto ad un dominio Active Directory Windows preesistente.
La documentazione di riferimento è quella ufficiale:Samba_AD_DC_HOWTO per la prima soluzione e Join_a_domain_as_a_DC per la seconda. Aggiungerei anche questa tagliata su Ubuntu 14.04 e personalmente testata con successo.

Il passo successivo sarà l’installazione di Freeradius che grazie all’utility samba ntlm_auth consentirà l’autenticazione degli utenti del dominio. Prima di iniziare consiglio la lettura attenta di questo sito per comprendere i metodi di autenticazione di Freeradius. Se l’avessi letto io quando ho iniziato la configurazione la prima volta avrei risparmiato davvero tanto tempo. La documentazione seguita: wiki ufficiale, simweb.ch,  e alcune indicazioni contenute in freeradius.1045715…, in particolare per lo script scritto da Scott McLane Gardner.

1. Preparazione

Partiamo da una installazione di Ubuntu 14.04 server senza interfaccia grafica. Durante l’installazione sceglieremo solamente di aggiungere il server ssh (Openssh-server).  Per semplicità io generalmente opto per abilitare l’utente root e poter lavorare senza dover ogni volta ulitizzare il sudo. Quindi:

$ sudo passwd root
 [sudo] password for luca:
 Inserire nuova password UNIX:
 Reinserire la nuova password UNIX:
 passwd: password aggiornata correttamente
 $ su -
 Password:
 #

In tal modo lavoreremo come root. Aggiorniamo il sistema:

# apt-get update && apt-get upgrade

2. Installazione e configurazione di samba

2.1 Installazione prerequisiti di samba come DC

# apt-get install attr build-essential libacl1-dev libattr1-dev libblkid-dev libgnutls-dev libreadline-dev python-dev libpam0g-dev python-dnspython gdb pkg-config libpopt-dev libldap2-dev dnsutils libbsd-dev attr krb5-user docbook-xsl libcups2-dev acl ntp

Durante l’installazione di Kerberos verranno richiesti alcuni parametri. Sostanzialmente quelli relativi alla mia configurazione sono:

Realm=DOMINIOSAMBA.IT / Server=samba4 (o anche samba4.dominiosamba.it)

2.2 Configurazione di rete e ntp

Settare un ip statico in /etc/network/interfaces ed aggiungerci come dns server l’ip del server stesso + l’ip di un server dns esterno (generalmente quello del nostro provider) + l’indicazione del dominio:

# vim /etc/network/interfaces

# The primary network interface
auto eth0
iface eth0 inet static
     address 192.168.201.136
     netmask 255.255.255.0
     gateway 192.168.201.20
     dns-nameservers 192.168.201.136 8.8.8.8
     dns-search dominiosamba.it

Ovviamente i dati relativi agli indirizzi dovranno essere adattati alla vostra rete.

Settare l’hostname (in /etc/hostname) in modo congruente, nel mio caso “samba4″.

Visto che samba fa uso di attributi di filesystem che generalmente ext3/4 non supportano, occorre indicarli in /etc/fstab. Qualcosa del tipo:

#questa è la partizione dove risiede samba:
UUID=xyzxyzxy-xyzx-xyzx-x    /    ext4     errors=remount-ro 0 1
#Occorre aggiungere qualche parametro:
UUID=xyzxyzxy-xyzx-xyzx /    ext4     user_xattr,acl,barrier=1,errors=remount-ro 0 1

Ora settare /etc/hosts con qualcosa del tipo:

# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 samba4.dominiosamba.it samba4
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

2.3 Configurazione ntp

# service ntp stop

In /etc/ntp.conf aggiungere il proprio server ntp (nel mio caso 192.168.17.22), altrimenti lasciare quelli di default (ntp server di ubuntu.pool.ntp.org):

# vim /etc/ntp.conf
  Continue reading 

Connettere Linux ad apparati Cisco tramite porta seriale (console) con minicom

Vista l’assenza della porta seriale sui moderni portatili, il più delle volte è necessario utilizzare un adattatore usb-to-serial per interfacciarsi alla porta console degli apparati Cisco (ed altri apparati di rete).
L’adattatore crea una porta seriale (com) “virtuale” che il sistema riconosce ed utilizza come porta fisica.
Il primo step sarà individuare tale porta.

1. Individuazione porta COM
Dopo aver installato il proprio adattatore, aprire la shell e digitare il seguente comando per visualizzare i messaggi del kernel in real time:


$ dmesg
 (...)
[ 4904.189273] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 4904.189377] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected
[ 4904.189441] usb 6-2: Detected FT232RL
[ 4904.189443] usb 6-2: Number of endpoints 2
[ 4904.189445] usb 6-2: Endpoint 1 MaxPacketSize 64
[ 4904.189447] usb 6-2: Endpoint 2 MaxPacketSize 64
[ 4904.189449] usb 6-2: Setting MaxPacketSize 64
[ 4904.192176] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0
(...)

Nel mio caso possiamo vedere che la porta seriale è la “ttyUSB0″. Prenderne nota.

2. Installazione minicom

$ sudo apt-get install minicom

3. Avvio e configurazione minicom

$ sudo minicom

Dall’interfaccia di shell digitare la combinazione dati CTRL-A e poi Z per entrare nell’help e poi nella configurazione di minicom.
Digitare “O” (la lettera) corrispondente a “cOnfigure Minicom”
Scegliere “Serial port setup”
Digitare “A” corrispondente a “Serial Device”
Digitare la seriale annotata precedentemente, con full path (nel caso dell’esempio: /dev/ttyUSB0)
confermare dando Invio
Digitare “E” corrispondente a “Bps/Par/Bits” e poi “C” per selezionare la velocità di 9600 8N1 e poi “Q” per “Q-N-1″
Confermare dando Invio
Selezionare “F” impostare “Hardware Flow Control” a “Yes”, poi selezionando “G” impostare “Software Flow Control” a “No”
Confermiamo dando Invio

4. Salvataggio della configurazione
Scegliere “Save setup as dfl” se si desidera che i parametri appena settati diventino il default altrimenti “Save setup as..”. Visto che la seconda opzione presenta qualche problema (verificato su una Ubuntu 14.04), scegliere la prima.

Quest’ultimo step salverà il file di configurazione di default, chiamato .minirc.dfl nella home del vostro utente. Nel caso specifico il file sarà:

$ cat .minirc.dfl
# Machine-generated file - use setup menu in minicom to change parameters.
pu port /dev/ttyUSB0
pu baudrate 9600
pu bits 8
pu parity N
pu stopbits 1

Usciamo selezionando “Exit”

Ora avviando minicom (sempre con sudo) la nuova configurazione sarà caricata. Sarà sufficiente premere Invio per entrare nell’apparato di rete.

5. Troubleshooting
Può succedere, soprattutto in fase di configurazione e test, che qualche connessione seriale resti “appesa”, ovvero resti attiva tenendo occupata la porta seriale. In tal caso apparirà un errore minicom che avvisa che la porta è occupata (più precisamente “lockata”):

"Device /dev/ttyUSB0 is locked"

Se il riavvio di minicom non risolve il problema, si può procedere in questo modo:

– Individuare quale processo occupa la porta, utilizzando “lsof” (“list open file”)

$ sudo lsof /dev/ttyUSB0
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
minicom 5061 root 3u CHR 188,0 0t0 114268 /dev/ttyUSB0

L’output ci dice che la porta /dev/ttyUSB0 è occupata dal processo minicom con PID 5061.

– Stoppare il processo con:

$ sudo kill -9 5061

Al successivo avvio di minicom la porta risulterà disponibile.