Primer Xinetd

Xinetd è un tutore che gestisce l’accesso al tuo computer da Internet. È un demone che funziona sempre e ascolta tutte le porte per richieste di connessione o di servizio. Se non si esegue un server, non sarà necessario xinetd. Tuttavia, anche se il tuo computer è solo per uso domestico, potresti dover consentire ad altri di accedere ai servizi sul tuo computer in futuro. Quando lo fai, dovrai installare xinetd per proteggere il tuo computer da attività dannose.

Sistema operativo

L’utilità xinetd è stata scritta per sistemi Unix e simili a Unix. Quindi, verrà installato su Linux e Mac OS, ma non su Windows. Il programma è gratuito e accessibile da GitHub.

È possibile ottenere il programma da questo repository principale e c’è anche un fork del codice. Questo è un programma noto e affidabile che è stato scaricato e installato molte volte, quindi non dovresti preoccuparti che i pericoli del programma siano falsi dannosi.

Scopo di xinetd

Il sistema xinet è destinato a funzionare come un server. Probabilmente sai che in una tipica connessione Internet, un computer contatta un altro. Il computer che avvia il contatto è chiamato “cliente“E il programma contattato è il”server.”La solita ragione della connessione è che il client può ottenere un servizio dal server. Tuttavia, il computer contattato deve avere un programma in esecuzione, in attesa di richieste. Questa è la funzione di xinetd.

Il requisito di base per xinetd è che riceverà le richieste e le inoltrerà all’applicazione corretta, che è indicato dal numero di porta scritto nell’intestazione della connessione in arrivo o della richiesta di servizio. Il programma xinetd non fornisce effettivamente il servizio richiesto, ma funge da gatekeeper.

Alternative: xinetd vs inetd

Gli sviluppatori di xinetd non sono stati i primi a inventare l’idea di un programma che ascolta sulla rete le richieste in arrivo. In effetti, xinetd è inteso come un miglioramento del programma originale che ha eseguito questa attività, che si chiama inetd.

Il nome “xinetd” è un’abbreviazione di “demone dei servizi Internet estesi”. Il “demone dei servizi Internet” descrive l’originale inetd. Con inetd ottieni lo stesso monitoraggio delle richieste del server fornito da xinetd. Tuttavia, questo demone non ha meccanismi di difesa e quindi ora è considerato insicuro.

Il vecchio inetd non funzionava da solo. Ha inviato richieste a tcpd, che ha controllato i file delle autorizzazioni (hosts.allow e hosts.deny). Come suggerisce il nome, tcpd gestisce le richieste di connessione TCP. Tuttavia, esamina anche le porte UDP, quindi è un’implementazione dell’interfaccia del livello di trasporto. Potresti anche vedere la menzione di un wrapper TCP: questo è solo un altro nome per tcpd. L’inclusione di tcpd ha aggiunto alcuni miglioramenti al controllo degli accessi. Tuttavia, il processo di autorizzazione è stato guidato da due file popolati manualmente, quindi non è stata una soluzione di sicurezza molto completa.

Funzionalità di Xinetd

La modalità operativa di xinetd è simile a quella di inetd combinata con tcpd. Tuttavia, la soluzione xinetd ha funzionalità di sicurezza molto migliori rispetto alla combinazione inetd / tcpd. Le caratteristiche del demone includono:

• controllo accessi per TCP e UDP
• registrazione eventi che registra l’esito positivo e negativo della connessione
• controllo degli accessi basato su segmenti temporali
• limite simultaneo del server – Difesa dagli attacchi Denial of Service (DoS)
• limite di dimensione del file di registro
• assegnazione di servizi a diverse interfacce, consentendo di limitare determinati servizi alla rete privata
• funzione proxy inclusa la traduzione dell’indirizzo di rete

Xinetd è in grado di operare come mediatore per Servizi RPC. Tuttavia, questa funzione non è molto ben implementata. La mancanza di funzionalità di sicurezza in RPC ha ridotto la richiesta di accesso a quel servizio, quindi è dubbio che gli sviluppatori di xinetd impiegheranno del tempo a perfezionare la sua interfaccia RPC.

Metodi di controllo dell’accesso

Come inetd, xinetd ti consente di autorizzare o bloccare le connessioni in base all’indirizzo IP del richiedente. Con inetd, puoi anche identificare le origini di connessione consentite e bloccate per nome host o nome dominio. Ognuna di queste opzioni richiede una procedura di ricerca. Nel caso dell’opzione hostnames, dovresti avere quei nomi impostati nel sistema DNS della tua rete. Per i domini, probabilmente sarebbe meglio affidarsi al sistema DNS pubblico.

La scelta di identificare i richiedenti tramite indirizzo IP, nome host o nome dominio dipende da te. tuttavia, attenersi all’indirizzo IP crea connessioni più velocemente perché elimina la necessità di una fase di ricerca.

Configurazione di sistema

Per usare xinetd, devi prima installarlo e poi aggiorna il file di configurazione. In sostanza, il file di configurazione è il tuo centro di comando per xinetd. Poiché questo programma è un demone, una volta avviato, continuerà a funzionare per sempre. Non è un’utilità interattiva che puoi regolare dalla riga di comando. Tutte le comunicazioni con il programma avvengono tramite il file di configurazione.

Il demone continuerà a controllare il file di configurazione ogni volta che riceve una richiesta dal mondo esterno. Non carica la configurazione in memoria all’avvio. Questo significa puoi regolare le prestazioni del demone mentre è in esecuzione modificando le istruzioni contenute nel file di configurazione.

Il file di configurazione per xinet è molto più importante dei sistemi di configurazione per altre utilità. Questo perché è possibile modificare le istruzioni per il demone attraverso la configurazione senza dover arrestare il programma xinetd e riavviarlo.

Impostazione del file di configurazione

Cerca il file /etc/xinetd.conf. Questo è il file di configurazione principale per il programma e funge da tabella di ricerca che l’applicazione legge per stabilire quali connessioni consentire e quali servizi chiamare.

È possibile creare il file xinetd.conf da un esistente inetd.conf file con il xconv.pl programma, che fa parte del pacchetto che è possibile scaricare dal repository GitHub per xinetd. Esegui il programma di conversione con il seguente comando:

/usr/local/sbin/xconv.pl < /etc/inetd.conf > /etc/xinetd.conf

Il nuovo file di configurazione non è perfetto e richiederà ulteriori modifiche prima di poter avviare xinetd.

Sezione impostazioni predefinite file di configurazione

Quando guardi il tuo file xinetd.conf appena generato, devi concentrarti su due sezioni di configurazione chiave. Il primo di questi è il default sezione e il secondo è il Servizi sezione.

Come probabilmente hai già intuito, la sezione dei valori predefiniti dice a xinetd cosa fare se non trova istruzioni specifiche per la sua attività corrente nella sezione servizi.

Alcune opzioni chiave che è possibile impostare nella sezione dei valori predefiniti sono:

• only_from
• nessun accesso
• log_type
• log_on_success
• log_on_failure
• casi
• per_source

Le sezioni seguenti spiegano queste opzioni in modo più dettagliato.

Condizioni d’accesso

only_from e nessun accesso svolgere efficacemente lo stesso compito, che è quello di bloccare (nessun accesso) o consentire (solo_dal) indirizzo specifico o intervalli di indirizzi. Si consiglia di utilizzare una di queste opzioni per bloccare tutto per impostazione predefinita e quindi creare un elenco di servizi più in basso nel file di configurazione. Con questa strategia, ti copri se si verifica un evento per il quale non hai tenuto conto.

Queste due opzioni sono anche comandi validi da includere nella sezione servizi. Così puoi inizia a vietare tutto per impostazione predefinita e quindi aggiungi i servizi. Se esiste una sezione di servizio relativa al tipo di richiesta di connessione che xinetd riceve, non esaminerà la sezione dei valori predefiniti della configurazione.

Le istruzioni di only_from e no_access in una descrizione per un servizio hanno la precedenza sulle istruzioni only_from e no_access nella sezione default.

Il formato per queste due opzioni è

=

Ricorda che gli indirizzi possono essere espressi come indirizzi IP, nomi host o nomi di dominio. Tuttavia, è meglio attenersi agli indirizzi IP. È possibile utilizzare la notazione CIDR per specificare un intervallo. Ecco due esempi di come potresti usare queste opzioni:

no_access = 0.0.0.0/0

Questa è probabilmente la linea più comune nella sezione dei valori predefiniti perché blocca tutti. La sezione dei valori predefiniti è presente solo nel file di configurazione per indicare a xinetd cosa fare in caso di una richiesta di servizio non coperta nella sezione servizi. Dovresti supporre che sarai in grado di fornire istruzioni specifiche per ogni tipo di servizio che il tuo computer può fornire, quindi è ragionevole affermare che tutte le altre richieste sono bloccate. Come direbbe il portiere di una festa VIP esclusiva, “Se non sei nella lista, non entrerai”.

Un’alternativa a questa strategia è quella di far entrare tutti. Lo implementeresti con:

solo_da = 0.0.0.0/0

Questa norma non ha davvero senso nella sezione dei valori predefiniti. La sezione predefinita viene indicata solo se non hai inserito le istruzioni per un servizio, quindi quando xinetd ricorre alle impostazioni predefinite, ha un caso in cui non sono state fornite istruzioni. Pertanto, consentire l’accesso in tali circostanze comporterebbe un errore perché non hai detto a xinetd cosa fare della richiesta. È logico utilizzare questa opzione catch-all only_from nella descrizione di un servizio, quindi questo messaggio direbbe a xinetd di consentire alle richieste di ogni possibile fonte di utilizzare quel servizio.

Sfortunatamente, esiste una caratteristica delle opzioni only_from e no_access che creerebbe un conflitto se si implementasse una politica come descritto sopra. Questo è, entrambi no_access e only_from sono globali e xinetd li controlla entrambi ogni volta che ha un compito da svolgere. Quindi, se entrambi sono stati impostati, il demone convaliderà la richiesta in arrivo rispetto a quella istruzione no_access nella sezione default anche se è stata impostata una configurazione di servizio valida.

Questa stranezza di no_access e only_from essendo globale può essere superata decidendo una politica di sempre e solo usando l’uno o l’altro nel file xinetd.conf. È pratica comune attenersi a only_from e ignorare l’opzione no_access. Puoi creare un’istruzione catch-all lasciando vuoto l’elenco degli indirizzi nella sezione dei valori predefiniti, ovvero “only_from = “E ciò consentirà al programma xinetd di utilizzare l’impostazione only_from nelle descrizioni dei servizi. Ciò si verificherà senza sollevare un conflitto perché la sezione dei valori predefiniti only_from viene sovrascritta dall’impostazione only_from del servizio.

fastidiosamente, se non inserisci un’istruzione only_from o no_access nella sezione dei valori predefiniti, xinetd consentirà tutte le connessioni che non hai coperto nella sezione servizi, che probabilmente creerà un errore.

Il formato per elencare diversi indirizzi come parametri di entrambe queste opzioni è di lasciare uno spazio tra ciascun indirizzo (senza virgole). È inoltre possibile includere intervalli CIDR nell’elenco.

Comandi del file di registro

Il log_type, log_on_success, e log_on_failure le opzioni funzionano tutte insieme. Ognuno ha una serie di costanti che è necessario inserire nell’opzione come parametri.

Utilizzare l’attributo log_type per fornire il percorso e il nome di un file di registro e utilizzare l’attributo log_on_success e log_on_failure per specificare quali campi devono essere scritti nel record del file di registro per ciascun evento.

Ad esempio, dovresti scrivere un indirizzo per il file di registro con:

log_type = FILE / usr / log / internetlog

Un’altra opzione disponibile con l’attributo log_type è SYSLOG, che imposta il livello del messaggio per questi eventi che verranno segnalati da syslogd. I valori possibili sono:

• demone
• auth
• utente
• local0-7

Un esempio potrebbe essere:

log_type = SYSLOG local1

Il Sylog L’attributo non è essenziale ed è molto meno importante di FILE opzione. Devi davvero dare a xinetd il nome di un file di registro in cui scrivere; non è necessario specificare il livello Syslog per i messaggi di evento.

Le opzioni di report disponibili per log_on_success sono:

• PID – 0 se si tratta di un servizio xinetd interno
• HOST – indirizzo del client
• USERID: identità dell’utente remoto
• EXIT – elabora lo stato di uscita
• DURATA – periodo di durata della sessione

Le opzioni di reporting per log_on_failure sono:

• HOST – indirizzo del client
• USERID: identità dell’utente remoto
• TENTATIVO: registra un tentativo di accesso non riuscito
• REGISTRAZIONE: tutte le informazioni disponibili sul client

È possibile includere più opzioni su ciascuna riga log_on_success e log_on_failure e devono essere separate da spazi senza alcun tipo di punteggiatura. Per esempio:

log_type = FILE / usr / log / internetlog
log_on_success = ESCI DURATA USERID PID HOST
log_on_failure = REGISTRAZIONE TENTATORI USERID HOST

È pratica comune mantenere le istruzioni log_type, log_in_success e log_on_failure su righe successive nel file.

Controlli di capacità

Altre due opzioni che devi inserire in xinetd.conf limitano il numero di connessioni simultanee che il tuo server dovrebbe accettare. Questo è un fattore importante ed è un modo semplice ma potente per sconfiggere gli attacchi Denial of Service (DoS). Le due opzioni che implementano questa strategia sono casi e per_source.

L’opzione di istanze nella sezione dei valori predefiniti specifica il numero di connessioni che xinetd consentirà l’esecuzione simultanea e l’opzione per_source specifica il numero di richieste di connessione a cui il demone risponderà dallo stesso indirizzo di origine. Attacchi di Denial of Service distribuiti (DDoS) aggirerà il limite per_source, ma non l’opzione delle istanze. Sfortunatamente, l’implementazione di questo limite di servizio bloccherà gli utenti reali per la durata dell’attacco.

Il formato per queste due opzioni è molto semplice:

= numero.

Il valore per_source dovrebbe essere inferiore al valore delle istanze.

Esempio di sezione dei valori predefiniti

Mettendo insieme tutti i dettagli spiegati in questa sezione, la tua dichiarazione di default di xinetd.conf dovrebbe apparire così:

default
{
istanze = 20
per_source = 5
log_type = FILE / usr / log / internetlog
log_on_success = ESCI DURATA USERID PID HOST
log_on_failure = REGISTRAZIONE TENTATORI USERID HOST
only_from =
}

Ogni file xinetd.conf dovrebbe avere un’istruzione di default. Non è necessario disporre di dichiarazioni sui servizi.

Sezioni di configurazione del servizio

Per ciascuno dei servizi che vuoi che il tuo server fornisca, dovresti scrivere una sezione di istruzioni di servizio in xinetd.conf. Se non scrivi alcun servizio nel file di configurazione, xinetd utilizzerà le specifiche indicate nella sezione dei valori predefiniti. È inoltre possibile sovrascrivere le impostazioni definite nelle sezioni predefinite riaffermando quegli attributi con valori diversi nella sezione scritta per definire un servizio.

Tipi di servizio

Gli attributi disponibili per la sezione servizi sono diversi per ciascuna delle tre categorie di servizi. Questi sono:

• INTERNO
• QUOTATI
• RPC

La categoria del servizio (INTERNO / NON ELENCO / RPC) può essere specificata con l’attributo genere. Tuttavia, questo attributo non è obbligatorio ed è spesso escluso.

Definizioni degli attributi di servizio

Quando si scrive una specifica di attributo, tutti i campi sono separati da spazi o ritorni a capo – non si utilizza alcuna forma di separatore o punteggiatura nella definizione.

Il layout di un’istruzione di servizio è lo stesso per la sezione dei valori predefiniti:

servizio
{
  valore dell’operatore dell’attributo
}

L’operatore utilizzato per le istruzioni degli attributi è in genere uguale (“=“). Pochissimi attributi consentono di aggiungere valori a un elenco esistente con “+=“O rimosso un elenco con”-=“- in entrambi questi casi, scrivi l’operatore senza le virgolette mostrate qui.

Ecco gli attributi disponibili per un INTERNO tipo di servizio:

• socket_type
• bandiere
• simpatico
• aspettare
• protocollo (se non elencato in / etc / services)
• porta (se non elencato in / etc / services)
• cps
• access_times

Gli attributi disponibili per un RPC i servizi sono:

• socket_type
• bandiere
• utente
• server
• server_args
• simpatico
• aspettare
• protocollo
• rpc_version
• rpc_number
• cps
• access_times

Il QUOTATI i tipi di servizio possono avere uno dei seguenti attributi:

• socket_type
• bandiere
• utente
• server
• server_args
• carico massimo
• simpatico
• aspettare
• protocollo (se non elencato in / etc / services)
• porta (se non elencato in / etc / services)
• access_times
• cps

Scopo dell’attributo di servizio

I significati di questi attributi sono mostrati nella tabella seguente:

AttributeDescription

genere	INTERNAL, RPC, UNLISTED o INTERNAL UNLISTED
socket_type	stream (TCP), dgram (UDP), raw (accesso diretto IP) o seqpacket ().
id	creare un nome univoco per questo servizio
bandiere	spiegato sotto la tabella
utente	specifica la priorità del server
server	Il percorso e il programma del servizio
server args	argomenti da passare con la chiamata di servizio
carico massimo	numero di processi simultanei per un servizio
simpatico	aumenta la priorità per il servizio
aspettare	si | no – blocca o consente l’elaborazione simultanea di nuove richieste
protocollo	può essere lasciato fuori se il protocollo è elencato in / etc / protocols
porta	il numero di porta deve esistere anche in / etc / services ed essere lo stesso numero
rpc_version	versione di RPC
rpc_number	Numero RPC
cps	limite di connessione, il secondo argomento è facoltativo e indica il numero di secondi di attesa al raggiungimento del limite
access_times	ore del giorno in cui è possibile eseguire un servizio
legare	rispondere alle connessioni a un indirizzo IP specifico
reindirizzare	inoltra le richieste per un servizio su un altro computer

Il bandiere L’attributo può avere i seguenti valori:

IDONLY: accetta solo connessioni da client che dispongono di un server di identificazione

noretry: impedisce la creazione di un nuovo processo in caso di errore di connessione

NAMEINARGS: il primo argomento in server_args è il server valore. Utilizzato quando si chiama tcpd

Oltre agli attributi di cui sopra, le opzioni disponibili nella sezione dei valori predefiniti possono anche essere scritte nella definizione di un servizio. Questi sono:

• only_from
• nessun accesso
• log_type
• log_on_success
• log_on_failure
• casi
• per_source

L’uso di nuovo di questi attributi sovrascriverà tutti i valori impostati nella sezione dei valori predefiniti. Tuttavia, ricorda che il only_from e nessun accesso gli attributi sono globali, quindi è necessario organizzare l’uso di queste opzioni per evitare parametri in conflitto.

Esempi di dichiarazioni di servizio

Ecco due esempi della definizione di un servizio.

servizio ntalk
{
socket_type = dgram
aspetta = si
utente = nessuno
server = /usr/sbin/in.ntalkd
access_times = 7: 00-12: 30 13: 30-21: 00
only_from = 192.168.1.0/24
}

servizio ftp
{
socket_type = stream
wait = no
utente = root
server = /usr/sbin/in.ftpd
server_args = -l
istanze = 4
bello = 10
}

Nota l’uso di access_times nel ntalk definizione. Questo utilizza due intervalli di tempi con i tempi da e a separati da un trattino (“-”) senza spazi. I due intervalli di tempo sono separati da uno spazio. Le definizioni dell’ora utilizzano il formato dell’orologio a 24 ore.

Il only_from attributo in ntalk la definizione limita l’accesso a questo servizio in modo che solo gli indirizzi sulla rete locale possano utilizzarlo.

Il ntalk il servizio ha un socket_type di dgram, il che significa che è un servizio UDP. Il socket_type nel ftp la definizione è ruscello, ciò significa che si tratta di un servizio TCP.

Crea più istanze di un servizio

La definizione dei servizi utilizza il nome del servizio come identificatore per impostazione predefinita. Tuttavia, potresti voler creare diverse copie di un servizio e assegnare a ciascuno diversi attributi. Poiché il nome del servizio deve corrispondere al nome utilizzato in / etc / services file, ottenere diverse versioni di un servizio in esecuzione sarebbe impossibile. Tuttavia, l’attributo id abilita questa strategia operativa.

Un utilizzo molto comune di questo scenario sarebbe quando si desidera creare diversi server FTP per accesso interno ed esterno. Con questo metodo, puoi mantenere la tua archiviazione dei file per l’ufficio completamente separata dai file scaricabili che rendi disponibili al pubblico.

In questo caso di utilizzo, definire due volte “Service ftp”. Darei quindi un’istanza all’attributo id = ftp-internal e l’altro id = ftp-external. Da quel momento in poi, xinetd può distinguere tra i due. Per rendere ogni istanza disponibile a un pubblico diverso, devi utilizzare il only_from attributo per limitare l’accesso al servizio ftp-interno ai soli indirizzi sulla rete e l’accesso al servizio ftp-esterno a tutti gli indirizzi non di rete.

Associare un indirizzo a un servizio

Lo scenario di creazione di servizi diversi per utenti interni ed esterni può essere notevolmente aiutato dall’attributo bind. Il termine “legare“Viene spesso utilizzato nella programmazione TCP. Di solito significa associare una connessione a una porta, creando così un ID per la sessione. In questo caso, tuttavia, “legare” significa qualcosa di diverso. Nell’esempio dell’accesso interno ed esterno al server FTP, potresti associare l’indirizzo di rete del computer all’istanza interna ftp e l’indirizzo IP pubblico di quel computer all’istanza esterna ftp.

In questo esempio, potrebbe essere possibile tralasciare l’attributo only_from nella definizione del servizio. Tuttavia, è più sicuro lasciare tali restrizioni. Pertanto, la definizione completa dei server FTP interni ed esterni sarebbe:

servizio ftp
{
id = ftp-external
server = /usr/sbin/in.ftpd
server_args = -l
istanze = 4
solo_da = 0.0.0.0/0
bind = 202.19.244.130
}

servizio ftp
{
id = ftp-internal
socket_type = stream
server = /usr/sbin/in.ftpd
server_args = -l
only_from = 192.168.1.0/24
bind = 192.168.1.5
}

Questa strategia richiede che al server FTP sia assegnato un indirizzo IP statico per l’accesso pubblico. Inoltre, è necessario configurare il server DHCP per riservare lo stesso indirizzo per il server FTP interno. Sebbene lo scenario sopra riportato funzioni quando si utilizza un singolo computer per l’accesso sia interno che esterno, è anche possibile allocare gli indirizzi di computer separati per ogni istanza FTP.

Disabilita i servizi specifici di inetd

Ci sono tre servizi xinetd che forniscono informazioni sul sistema.

• server: report sui server in uso
• servizi: rapporto sui servizi disponibili, i loro protocolli e le loro porte
• xadmin: combina i due comandi precedenti

Questi servizi rappresentano un punto debole della sicurezza perché possono essere utilizzati dagli hacker per ottenere informazioni sulla rete e sul server. Pertanto, è meglio disabilitarli. Puoi farlo con l’attributo disabilitato, che va nel tuo default definizione. Includi la seguente riga nella sezione dei valori predefiniti per rimuovere queste funzionalità:

disabled = server services xadmin

Con le modifiche al file di configurazione descritte sopra, ora puoi iniziare a usare xinetd.

Esecuzione di xinetd

Si avvia xinetd dalla riga di comando. Il comando può anche essere eseguito da un file batch, quindi puoi aggiungerlo alle procedure di avvio del tuo computer. Il programma può essere eseguito con le seguenti opzioni:

SwitchOptionDescription

-d		Modalità di debug
-syslog	syslog_facility	Lo stesso di log_type SYSLOG nelle impostazioni predefinite del file conf
-filelog	file di log	Lo stesso di log_type FILE nel file di configurazione predefinito
-f	config_file	Specifica il file di configurazione – l’impostazione predefinita è /etc/xinetd.conf
-pidfile	pid_file	Scrivi l’ID del processo su pid_file
-rimani vivo		Non terminare mai
-limite	proc_limit	Numero massimo di processi che possono essere eseguiti contemporaneamente
-logprocs	limite	Numero massimo di server che possono essere eseguiti contemporaneamente
-versione		Stampa la versione xinetd
-inetd_compat		Leggi /etc/inetd.conf e il file di configurazione xinetd
-cc	intervallo	Eseguire controlli di coerenza ogni intervallo di secondi

È anche possibile avviare xinetd senza alcuna opzione.

Usa xinetd

Se hai un computer Linux, potresti avere xinetd già installato. Puoi controllare eseguendo xinetd -version. Se invece il tuo computer esegue inetd, è probabile che tu non stia eseguendo Linux. Sostituisci il programma con xinetd e converti il ​​tuo file di configurazione dalla compatibilità inetd all’utilizzo di xinetd come spiegato sopra.

Usi xinetd al momento? Lascia un messaggio nel Commenti sezione sottostante per condividere le tue esperienze con la community.

Guarda anche: 15 migliori server Syslog gratuiti

Immagine: connessione Internet di rete da Pixabay. Licenza concessa da CC0 Creative Commons