Bastion host versione 2022 —
Riprendo dopo un bel po di anni questo discorso che attualmente è diventato ancora più fondamentale.
Il concetto fondamentale resta lo stesso:
Un Bastion host è normalmente nelle realtà aziendali la macchina di collegamento tra la/le LAN e Internet.
Quindi questa macchina deve essere il più possibile (per quanto questo significhi un qualcosa) sicura e di difficile accesso o meglio impossibile (e vedremo in seguito che questo non è del tutto vero)
Negli anni vuoi per esperienza, vuoi per comodità vuoi per mutato modo di ragionare/lavorare ho cambiato diverse cose e quindi i due bastion host aziendali oggi come oggi condividono solo l’IP di gateway della LAN e solo quello è in HA.
Un altra cosa che è cambiata è l’adozione di kernel modulari al posto di kernel compilati sulla macchina stessa, i principali motivi di questa scelta sono stati la velocità che si ottiene con un kernel modulare rispetto a uno totalmente compilato, la volontà di restare con la linea di kernel della distribuzione, e non da ultimo la facilità della cosa.
È sparito il proxy che è diventato una macchina virtuale in LAN
È cambiato il framework di packet filtering da iptables a nftables
Una particolare attenzione è stata prestata ai parametri da passare al kernel in fase di avvio per mitigare gli attacchi DDoS che sono purtroppo sempre più frequenti e che colpiscono indirettamente anche se la classe di IP è in una subnet adiacente.
Attualmente i due bastion host aziendali sono due Dell PowerEdge R240 collegati a due diversi provider e come dicevo poco sopra sono configurati in HA Master/slave solo per la condivisione del gateway della LAN, in altre parole l’uscita principale è su un provider con un IP e solo in caso di down passa all’altro, questo però non significa ad esempio che in entrata non succeda che i servizi vengano pilotati su entrambe le connessioni.
Come è intuitivo una macchina del genere deve avere a bordo il minimo possibile come software, tutto quello che non c’è non:
si rompe
si può attaccare
si deve controllare/mantenere
Detto ciò nell’istallazione iniziale (al solito da qualche anno Devuan stable ad oggi la 4) arrivati alla scelta dell’installazione software utilità di sistema standard e server SSH (non è realistico anche se sarebbe bello pensare di non avere accesso remoto) nulla di più, i tools necessari anche solo per scrivere li metteremo dopo uno alla volta e quando servono.
Sin qui i concetti generali, da qui le personalizzazioni sulle nostre macchine aziendali, possono essere una traccia da seguire ma non è assolutamente detto che possano funzionare in altre realtà.
Accesso remoto alla macchina
Come al solito si usa SSH
Firewall
Arrivati a questo punto il primo passo è quello di modificare sulle nostre esigenze il file /et/network/interfaces sulla macchina hostname perseo ad esempio è fatto così:
allow hotplug eth0
iface eth0 inet static
address xxx.yyy.zzz.92/29
gateway xxx.yyy.zzz.91
up ip addr add xxx.yyy.zzz.96/29 brd xxx.yyy.zzz.97 dev eth0 label eth0:0
allow-hotplug eth1
iface eth1 inet static
address 192.168.2.240/23
Quindi senza particolari modifiche mi rifaccio a quanto scritto qui per lanciare il firewall e a questo momento abbiamo un router funzionante che permette l’uscita della LAN su Internet e previene gli accessi non autorizzati esplicitamente.
IDS/IPS
L’aspetto a mio avviso più importante di questa categoria è quello rappresentato dagli IPS che sui nostri bastion host sono:
Le configurazioni per fail2ban e portsentry sono relative a Devuan 3 beowulf ma restano inalterate sulla versione 4 chimaera.
Immediatamente a seguire gli IDS che sono:
aide
rkhunter
tiger
tripwire
Anche in questo caso le vecchie configurazioni sono valide.
Una macchina configurata in questa maniera e messa a presidio della connessione Inernet/LAN la considero il minimo accettabile.
Categorised as: firewall | IDS | IPS | Linux | Networking | Sistemi operativi | Work
Comments are disabled on this post