Quando un sistema viene usato come un server su di una rete pubblica, esso può diventare bersaglio di attacchi. Per questa ragione, è molto importante per un coordinatore,bloccare i servizi in caso di aggressione e rendere i sistemi più difficili da violare.
Prima di esaminare i problemi in modo specifico, vi consigliamo di ricontrollare i seguenti suggerimenti in modo da aumentare così la sicurezza del server:
Mantenere i servizi sempre aggiornati, per essere in grado di affrontare le ultimissime minacce.
Quando possibile usare protocolli sicuri.
Servire solo un tipo di servizio di rete per macchina se possibile.
Controllare attentamente tutti i server per la presenza di attività sospetta.
I wrapper TCP forniscono il controllo d'accesso per una varietà di servizi. I servizi di rete più moderni, come SSH, Telnet, e FTP, fanno uso di wrapper TCP, per controllare la richiesta in arrivo e il servizio richiesto.
I benefici offerti dai wrapper TCP sono maggiori quando usati insieme con xinetd, un super servizio che fornisce un accesso aggiuntivo, una registrazione, un allacciamento, una ridirezione, e un controllo di utilizzo delle risorse.
![]() | Suggerimento |
---|---|
È un buona idea usare le regole firewall IPTables insieme con i wrapper TCP e xinetd, in modo da creare ridondanza all'interno dei controlli per l'accesso del servizio. Consultare Capitolo 7 per maggiori informazioni sull'implementazione dei firewall con i comandi IPT tables. |
Maggiori informazioni sulla configurazione dei wrapper TCP e su xinetd, è disponibile nel capitolo intitolatoWrapper TCP e xinetd nella Red Hat Enterprise Linux Reference Guide.
Le seguenti sottosezioni hanno bisogno di una conoscenza basica, da parte del lettore, di ogni argomento, per questo motivo il capitolo si concentra su opzioni di sicurezza specifiche.
I wrapper TCP sono capaci non solo di negare l'accesso ai servizi, questa sezione affronta come essi possono essere usati anche per inviare i banner dei collegamenti, avvisare di attacchi da host particolari, e consente di aumentare le funzionalità di loggin. Per ottenere una lista accurata della funzionalità di wrapper TCP e della lingua di controllo, consultate la pagina man hosts_options.
Inviare un banner ai collegamenti client di un servizio, rappresenta un buon metodo per camuffare il sistema sul quale il server è in esecuzione, facendo sapere altresì ad un potenziale aggressore, che l'amministratore del sistema è vigile. Per implementare un banner di wrapper TCP per un servizio, usare l'opzione banner.
Questo esempio implementa un banner per vsftpd. Per poter iniziare, dovete creare un file banner. Può essere posizionato in qualsiasi parte del sistema, ma deve avere lo stesso nome del demone. In questo esempio, il file viene chiamato /etc/banners/vsftpd.
I contenuti del file somiglieranno al seguente:
220-Hello, %c 220-All activity on ftp.example.com is logged. 220-Act up and you will be banned. |
Il token %c fornisce una varietà d'informazioni client, come ad esempio il nome utente e l'hostname, oppure il nome utente e l'indirizzo IP, per rendere il collegamento ancora più intimidatorio. Il Red Hat Enterprise Linux Reference Guide possiede un elenco di altri token disponibili per i wrapper TCP.
Aggiungete la seguente riga al file di seguito riportato, per far sì che questo banner sia presente ai collegamenti in entrata, /etc/hosts.allow:
vsftpd : ALL : banners /etc/banners/ |
Se un host oppure una rete in particolare, sono stati intercettati durante l'attacco ad un server, i wrapper TCP possono essere usati per poter allertare l'amministratore di probabili attacchi, da parte della stessa rete o host, tramite la direttiva spawn.
In questo esempio, assumiamo che un cracker dalla rete 206.182.68.0/24, sia stato scoperto nel tentativo di attaccare il server. Inserendo la seguente riga nel file /etc/hosts.deny, il tentativo di collegamento viene negato e registrato all'interno di un file speciale.
ALL : 206.182.68.0 : spawn /bin/ 'date' %c %d >> /var/log/intruder_alert |
Il token %d fornisce il nome del servizio al quale il cracker stava cercando di accedere.
Per permettere il collegamento e la sua registrazione, inserire la direttiva spawn, nel file /etc/hosts.allow.
![]() | Nota |
---|---|
Dato che la direttiva spawn esegue qualsiasi comando della shell, potete creare uno script speciale per eseguire una notifica all'amministratore o eseguire una serie di comandi, nell'evento in cui un client particolare cerca di collegarsi al server. |
Se alcuni tipi di collegamento possono destare più preoccupazione di altri, il livello di registrazione può essere elevato tramite l'opzione severity.
In questo esempio, assumiamo che tutti gli utenti che cercano di collegarsi alla porta 23 (la porta Telnet) su di un server FTP, siano dei cracker. Per fare ciò, posizionare un flag emerg invece di un flag di default info nei file di registrazione, e negare il collegamento.
Per fare ciò, posizionare la seguente riga in /etc/hosts.deny:
in.telnetd : ALL : severity emerg |
Questo renderà possibile l'uso della loggin facility di default authpriv, elevando però la priorità del valore di default da info a emerg, il quale invia i messaggi log direttamente alla console.
Il super server xinetd, è un altro tool utile per il controllo dell'accesso ai servizi a lui subordinati. Questa sezione si concentra su come usare xinetd per impostare un servizio esca 'trap service' e controllare la quantità di risorse che ogni servizio xinetd può usare per poter contrastare gli attacchi del tipodenial of service. Per una lista completa delle opzioni disponibili, consultate le pagine man per xinetd e xinetd.conf.
Un contenuto importante di xinetd, è rappresentato dalla sua abilità di aggiungere degli host ad un elenco globale no_access. Agli host di questa lista, vengono negati i collegamenti ai servizi gestiti da xinetd per un determinato periodo, oppure fino a quando xinetd viene riavviato. Ciò viene fatto usando SENSOR. Questa tecnica rappresenta un modo facile per bloccare il tentativo di esplorazione del server.
Il primo passo per l'impostazione di un SENSOR, è quello di scegliere un servizio da non usare. Per questo esempio, viene usato Telnet.
Modificare il file /etc/xinetd.d/telnet, e cambiare la riga flags in modo tale da poter leggere:
flags = SENSOR |
Aggiungere la seguente riga all'interno delle parentesi:
deny_time = 30 |
Questo negherà il collegamento all'host che avrà tentato di collegarsi alla porta per circa 30 minuti. Altri valori accettati per deny_time, sono FOREVER, il quale mantiene tale proibizione fino a quando il comando xinetd viene riavviato, e NEVER, il quale abilita al collegamento e successivamente lo registra.
In fine, l'ultima riga dovrebbe essere letta:
disable = no |
Usare SENSOR, rappresenta un modo corretto per rilevare e fermare i collegamenti da host sospetti, tale metodo però, presenta due inconvenienti:
Esso non funziona contro le esplorazioni invisibili 'stealth scans'.
Un aggressore che è a conoscenza dell'esecuzione di SENSOR può eseguire un attacco del tipo 'denial of service' contro host particolari, forzando i loro indirizzi IP, collegandosi così alla porta proibita.
Un altro contenuto importatnte di xinetd, è rappresentato dalla sua abilità di controllo della quantità dei servizi delle risorse che può utilizzare sotto il suo controllo.
Di seguito sono elencate le direttive da usare per effettuare quanto sopra riportato:
cps = <number_of_connections> <wait_period> — Indica i collegamenti abilitati al servizio al secondo. Questa direttiva accetta solo valori interi.
instances = <number_of_connections> — Indica il numero totale di collegamenti abilitati ad un servizio. Questa direttiva accetta sia un valore intero, che UNLIMITED.
per_source = <number_of_connections> — Indica i collegamenti abilitati ad un servizio da ogni host. Questa direttiva accetta sia un valore intero che UNLIMITED.
rlimit_as = <number[K|M]> — Indica la quantità di spazio dell'indirizzo di memoria che il servizio può occupare in kilobyte o in megabyte. Questa direttiva accetta sia un valore intero che UNLIMITED.
rlimit_cpu = <number_of_seconds> — Indica l'ammontare di tempo in secondi, durante il quale un servizio può occupare il CPU. Questa direttiva accetta sia un valore intero che UNLIMITED.
L'uso di queste direttive aiuta a prevenire una inondazione del sistema da parte di qualsiasi servizio xinetd, causando una negazione del servizio.