TCPWrappers ancora in uso?

Secondo la mia attuale comprensione, tcpwrappers possono essere utilizzati tramite inetd o xinetd. Ultimamente sono stato informato che inetd / xinetd è venuto in esistenza per utilizzare in modo più efficiente l'hardware nei giorni precedenti e sono pertanto visto raramente al giorno d'oggi.

La mia domanda è che se i tcpwrapper siano considerati una tecnica obsoleta. Se sì, qual è la loro sostituzione?

  • Ricerca di bypass / etc / services per xinetd
  • Inetd / xinetd non funziona sotto cygwin, perché?
  • Che cosa è un server ToD, "Ora del giorno" (non NTP)
  • xinetd non si avvia
  • xinetd 'collegamento resettato da peer'
  • tomcat6 dietro xinetd - vero cliente ip
  • BASH Script come servizio xinetd
  • Inoltra port pubblica a localhost
  • 5 Solutions collect form web for “TCPWrappers ancora in uso?”

    tcpwrappers è stato originariamente implementato come un programma autonomo che controllava hosts.allow e hosts.deny. Se la connessione è passata, verrà avviato il demone desiderato per eseguire una singola richiesta. La configuration di inetd sarebbe configurata per eseguire il wrapper tcpd con il programma del demone e le opzioni come parametri.

    xinted è un esteso inetd. Esso ha notevolmente più opzioni di configuration rispetto al vecchio inetd. I servizi triviali come eco, carica, tempo, giorno e scartano sono incorporati. Molti processi daemon che spesso eseguono continuamente possono essere eseguiti da xinetd. Questo è di solito fatto quando il servizio viene raramente utilizzato. Ciò limita il numero di processi che devono essere eseguiti a scapito dei tempi di avvio più lenti. I servizi che possono essere eseguiti in questo modo includono server di posta, vnc, apache e molti altri demoni.

    inetd esegue le stesse attività di xinetd ma con una semplice configuration di una linea per each servizio. Questo limita la capacità di essere configurata, ma semplifica la configuration automatica. Le procedure di installazione che possono configurare automaticamente inetd potrebbero non essere in grado di fare lo stesso per xinetd. Molti siti ora scelgono di utilizzare xinetd piuttosto che inetd.

    Il codice wrapper è stato creato in una libreria e spesso è collegato a demoni che sono sempre in esecuzione. Questi demoni utilizzeranno la libreria per controllare le connessioni in entrata prima di utilizzarle. Ciò consente restrizioni basate sul nome che non possono essere implementate in modo affidabile in un firewall. Ciò include un certo numero di controlli basati su DNS. Uno dei demoni che di solito è costruito utilizzando la libreria è xinetd.

    Servizi che funzionano costantemente in determinate porte. Il motivo inetd e tale memory salvata sono perché non richiedevano che i demoni si eseguissero tutto il tempo, solo a richiesta. In questi giorni, i demoni on-demand sono abbastanza rari.

    Cose come Apache, MySQL e Tomcat rimangono in esecuzione e ascoltano le loro porte designate. Alcuni anche spin-up nuovi processi per gestire each connessione, altri solo gestirlo nello stesso process. Non wherendo caricare un gruppo di codice each volta che si avvia una connessione, il costo per stabilire una connessione specifica è minore di quello che sarebbe con processi simili a inetd.

    Si sbagliano sia TCPwrappers che [x] inetd.

    tcpwrappers possono essere utilizzati tramite inetd o xinetd

    Sì – ma puoi utilizzarli con un qualsiasi daemon di networking – è solo una questione di utilizzare un diverso lib quando si crea l'applicazione.

    inetd / xinetd è nato per rendere più efficiente l'uso dell'hardware nei giorni precedenti e sono quindi visto raramente oggi

    Non è vero che i servizi di esecuzione tramite [x] inetd sono stati sempre molto inefficienti rispetto a un demone standalone. La differenza che fanno è che il codice è molto più semplice e viene mappato nella memory solo quando viene effettuata una connessione.

    Questo è ancora vero oggi – se si sta eseguendo un server web dedicato, allora non c'è molta importnza per tenere i demoni in esecuzione, per esempio i messaggi POP se c'è solo un singolo utente che collega un paio di volte al giorno per raccogliere la posta generata dai lavori cron. O avviare un server VNC quando è necessario l'accesso GUI remoto a una macchina senza testa.

    Una delle cose belle di tcpwrappers è che rendono le risposte complesse di script molto semplici rispetto a un firewall basato su un kernel.

    inetd / xinetd è nato nei giorni in cui le persone stavano eseguendo molti servizi accessibili a distanza su each macchina, incluse le cose come il tempo / data / carica ecc. In questi giorni, dato un Internet più ostile e una maggiore consapevolezza del potenziale per l'utilizzo di tali cose per lanciare gli attacchi DDOS, la maggior parte delle macchine eseguirà pochissimi server (pochissimi devono eseguire qualsiasi cosa diversa da SSH), con macchine specifiche per cose come DNS, SMTP ecc. Come tali, i demoni più recenti che implementano tali protocolli hanno di solito tutto ciò che i wrapper hanno fatto dentro di loro.

    Inoltre, le funzionalità firewall possono essere utilizzate per fornire la maggior parte di ciò che tcpd / udpd ha fatto.

    Essenzialmente il lavoro che i TCP-Wrapper fa per i servizi che vengono chiamati tramite un "super server" può essere sostituito (per altri processi e un "super server") da firewall stateful tramite iptables / netfilter nel caso delle più moderne installazioni Linux per le funzionalità di base, le regole di firewall senza stateless farebbero anche).

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.