Xinetd grunning

Xinetd grunning


Xinetd er en verge som administrerer tilgang til datamaskinen din fra internett. Det er en demon som kjører hele tiden og lytter på alle portene for tilkoblings- eller serviceforespørsler. Hvis du ikke kjører en server, trenger du ikke xinetd. Selv om datamaskinen din bare er til hjemmebruk, kan det hende du må tillate andre å få tilgang til tjenester på datamaskinen din på et tidspunkt i fremtiden. Når du gjør det, må du installere xinetd for å beskytte datamaskinen mot skadelig aktivitet.

Operativsystem

Xinetd-verktøyet ble skrevet for Unix og Unix-lignende systemer. Så det vil installeres på Linux og Mac OS, men ikke på Windows. Programmet er gratis å bruke og kan nås fra GitHub.

Du kan hente programmet fra dette hovedlageret, og det er også en gaffel av koden. Dette er et kjent og pålitelig program som har blitt lastet ned og installert mange ganger, så du skal ikke bekymre deg for farene ved at programmet er en ondsinnet forfalskning.

Formål med xinetd

Xinet-systemet er ment å fungere som en server. Du vet sikkert at i en typisk internettforbindelse kontakter en datamaskin en annen. Datamaskinen som initierer kontakt, kalles “klient”Og programmet som blir kontaktet er“serveren.”Den vanlige grunnen til tilkoblingen er slik at klienten kan få en tjeneste fra serveren. Imidlertid må den kontaktede datamaskinen ha et program i gang, og vente på forespørsler. Dette er funksjonen til xinetd.

Det grunnleggende kravet for xinetd er at den vil motta forespørsler og videresende dem til riktig applikasjon, som er angitt med portnummeret som er skrevet i overskriften på den ankomne forbindelsen eller tjenesteforespørselen. Xinetd-programmet gir faktisk ikke den forespurte tjenesten, men fungerer som en portvokter.

Alternativer: xinetd vs inetd

Utviklerne av xinetd var ikke de første som kom på ideen om et program som lytter på nettverket for innkommende forespørsler. Faktisk er xinetd ment som en forbedring av det originale programmet som utførte denne oppgaven, som kalles inetd.

Navnet “xinetd” er en forkortelse for “utvidet daemon for internettjenester”. “Demonst for Internett-tjenester” beskriver originalen inetd. Med inetd får du den samme serverforespørsel som xinetd gir. Imidlertid har denne demonen ingen forsvarsmekanismer, og anses nå som usikker.

Det gamle arbeidet fungerte ikke alene. Den sendte forespørsler videre til tcpd, som sjekket på tillatelsesfiler (hosts.allow og hosts.deny). Som navnet antyder, håndterer tcpd TCP-tilkoblingsforespørsler. Imidlertid undersøker den også UDP-porter, så det er en implementering av Transport Layer-grensesnitt. Du kan også se omtale av en TCP-innpakning - dette er bare et annet navn på tcpd. Inkluderingen av tcpd ga en viss forbedring av tilgangskontrollen. Tillatelsesprosessen ble imidlertid drevet av to manuelt befolket fil, og det var derfor ikke en veldig omfattende sikkerhetsløsning.

Xinetd-funksjoner

Den xinetd driftsmodusen er lik den for inetd kombinert med tcpd. Imidlertid har xinetd-løsningen mye bedre sikkerhetsfunksjoner enn inetd / tcpd-kombinasjonen. Funksjonene ved demonet inkluderer:

  • tilgangskontroll for TCP og UDP
  • hendelseslogging som registrerer suksess og fiasko i tilkoblingen
  • tilgangskontroll basert på tidssegmenter
  • samtidig servergrense - Doial-angrep forsvar
  • grense for loggfilstørrelse
  • tildeling av tjenester til forskjellige grensesnitt, slik at visse tjenester kan begrenses til det private nettverket
  • proxy-funksjon inkludert oversettelse av nettverksadresse

Xinetd er i stand til å operere som mekler for RPC-tjenester. Imidlertid er denne funksjonen ikke veldig godt implementert. Mangelen på sikkerhetsfunksjon i RPC har redusert etterspørselen etter tilgang til den tjenesten, så det er tvilsomt at utviklerne av xinetd vil bruke tid på å perfeksjonere RPC-grensesnittet.

Metoder for tilgangskontroll

Som inetd, xinetd lar deg tillate eller sperre tilkoblinger i henhold til forespørselens IP-adresse. Med inetd kan du også identifisere tillatte og blokkerte tilkoblingskilder etter vertsnavn eller domenenavn. Hvert av disse alternativene krever en oppslagsprosedyre. Når det gjelder vertsnavn-alternativet, må du ha disse navnene satt opp i ditt eget nettverks DNS-system. For domener vil du sannsynligvis ha det bedre å stole på det offentlige DNS-systemet.

Valget av om du identifiserer forespørsler etter IP-adresse, vertsnavn eller domenenavn er opp til deg. men, ved å holde fast ved IP-adressen opprettes forbindelser raskere fordi det eliminerer behovet for en oppslagsfase.

Systemkonfigurasjon

For å bruke xinetd, må du først installere den og deretter oppdater konfigurasjonsfilen. I hovedsak er konfigurasjonsfilen din kommandosenter for xinetd. Siden dette programmet er en demon, når du starter det, det vil fortsette å løpe for alltid. Det er ikke et interaktivt verktøy du kan justere på kommandolinjen. All kommunikasjonen din med programmet skjer gjennom konfigurasjonsfilen.

Demonen vil fortsette å sjekke konfigurasjonsfilen når den mottar en forespørsel fra omverdenen. Den laster ikke konfigurasjonen i minnet når den starter opp. Det betyr du kan justere ytelsen til demonet mens den kjører ved å endre instruksjonene i konfigurasjonsfilen.

Konfigurasjonsfilen for xinet er mye viktigere enn konfigurasjonssystemene for andre verktøy. Dette er fordi du kan endre instruksjonene for demonet gjennom konfigurasjonen uten å måtte stoppe xinetd-programmet og starte det på nytt.

Sette opp konfigurasjonsfilen

Se etter filen /etc/xinetd.conf. Dette er hovedkonfigurasjonsfilen for programmet, og den fungerer som en oppslagstabell som applikasjonen leser for å finne ut hvilke tilkoblinger du skal tillate og hvilke tjenester du skal ringe.

Du kan opprette xinetd.conf-filen fra en eksisterende inetd.conf fil med xconv.pl program, som utgjør en del av pakken som du kan laste ned fra GitHub-depotet for xinetd. Kjør konverteringsprogrammet med følgende kommando:

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

Den nye konfigurasjonsfilen er ikke perfekt, og den vil trenge ytterligere endringer før du kan starte xinetd.

Standardinnstillingen for konfigurasjonsfil

Når du ser i den nylig genererte xinetd.conf-filen, må du fokusere på to viktige konfigurasjonsdeler. Den første av disse er mislighold delen og den andre er den tjenester seksjon.

Som du antagelig allerede har gjettet, forteller standardinnstillingen xinetd hva du skal gjøre hvis den ikke finner spesifikke instruksjoner for sin nåværende oppgave i tjenestedelen.

Noen viktige alternativer som du kan angi i standardinnstillingen er:

  • only_from
  • ingen adgang
  • log_type
  • log_on_success
  • log_on_failure
  • forekomster
  • per_source

De neste avsnittene forklarer disse alternativene mer detaljert.

Tilgangsbetingelser

Only_from og ingen adgang effektivt utføre den samme oppgaven, som er å blokkere (ingen tilgang) eller tillate (bare_fra) spesifikk adresse eller adresseramme. Det anbefales å bruke et av disse alternativene for å blokkere alt som standard og deretter bygge opp en liste over tjenester lavere nede i konfigurasjonsfilen. Med denne strategien dekker du deg selv hvis en hendelse du ikke har gjort rede for oppstår.

Disse to alternativene er også gyldige kommandoer som skal inkluderes i serviceseksjonen. Så du kan Begynn å forby alt som standard, og legg deretter til tjenester. Hvis det er en serviceseksjon som angår tilkoblingsforespørselstypen som xinetd mottar, ser den ikke på standardavsnittet i konfigurasjonen.

Instruksjonene til only_from og no_access i en beskrivelse for en tjeneste overstyrer bare_from- og no_access-setningene i standardinnstillingen.

Formatet for disse to alternativene er

=

Husk at adressene kan uttrykkes som IP-adresser, vertsnavn eller domenenavn. Imidlertid er det bedre å holde seg til IP-adresser. Du kan bruke CIDR-notasjon for å spesifisere et område. Her er to eksempler på hvordan du kan bruke disse alternativene:

no_access = 0.0.0.0/0

Dette er sannsynligvis den vanligste linjen i standardinnstillingen fordi den blokkerer alle. Standardverdiavdelingen er bare der i konfigurasjonsfilen for å fortelle xinetd hva du skal gjøre i tilfelle en tjenesteforespørsel som ikke dekkes i serviceseksjonen. Du bør jobbe ut fra at du vil kunne gi spesifikke instruksjoner for hver tjenestetype som datamaskinen din kan tilby, så det er rimelig å oppgi at alle andre forespørsler er blokkert. Som dørvakten på en eksklusiv VIP-fest vil si: "Hvis du ikke er på listen, kommer du ikke inn."

Et alternativ til denne strategien er å slippe alle inn. Du vil implementere dette med:

only_from = 0.0.0.0/0

Denne policyen gir ikke virkelig mening i standardavsnittet. Standardseksjonen blir bare referert til hvis du ikke har satt inn instruksjoner for en tjeneste, så når xinetd ikke angriper standardverdiene, har den en sak som ikke har noen instruksjoner gitt for det. Så hvis du tillater tilgang under disse omstendighetene, vil det føre til en feil fordi du ikke har fortalt xinet hva du skal gjøre med forespørselen. Det er logisk å bruke dette catch-all only_from-alternativet i beskrivelsen av en tjeneste, så denne meldingen vil fortelle xinetd å tillate forespørsler fra alle mulige kilder om å bruke denne tjenesten.

Dessverre er det en funksjon i alternativene only_from og no_access som vil skape en konflikt hvis du implementerte en policy som beskrevet ovenfor. Det er, både no_access og only_from er globale og xinetd sjekker dem begge hver gang den har en oppgave å utføre. Så hvis du begge har satt, vil daemon validerer den innkommende forespørselen mot den no_access-uttalelsen i standardinnstillingen, selv om det er satt en gyldig tjenestekonfigurasjon.

Dette skjelvet om ingen tilgang og bare fra det å være globalt kan overvinnes ved å bestemme en politikk bare noen gang bruker det ene eller det andre i xinetd.conf-filen. Det er vanlig å holde seg med bare_fra og ignorere alternativet no_access. Du kan opprette en fange-bare instruksjon ved å la adresselisten stå tom i standard-delen, dvs. "bare_fra = ”Og det lar xinetd-programmet bruke bare_fra innstillingen i tjenestebeskrivelsene. Dette vil skje uten å opprette en konflikt fordi standardinnstillingen bare_fra verdi blir overskrevet av tjenestens eneste_fra innstilling.

annoyingly, Hvis du ikke legger en bare_from- eller ingen_tilgang-setning i standardinnstillingen, vil xinetd tillate alle tilkoblinger som du ikke har dekket i serviceseksjonen, noe som sannsynligvis vil opprette en feil.

Formatet for å liste opp flere adresser som parametere for begge disse alternativene er å la et mellomrom mellom hver adresse (ingen komma). Du kan også inkludere CIDR-områder i listen.

Loggfilkommandoer

De log_type, log_on_success, og log_on_failure alternativene fungerer sammen. Hver har en serie konstanter som du trenger å mate inn alternativet som parametere.

Bruk log_type-attributtet til oppgi banen og navnet på en loggfil og bruk attributtet log_on_success og log_on_failure for å spesifisere hvilke felt som skal skrives inn i loggfilen for hver hendelse..

For eksempel vil du skrive en loggfiladresse med:

log_type = FIL / usr / log / internetlog

Et annet alternativ tilgjengelig med log_type-attributtet er SYSLOG, som angir meldingsnivå for disse hendelsene som skal rapporteres av syslogd. Mulige verdier er:

  • daemon
  • auth
  • bruker
  • local0-7

Et eksempel vil være:

log_type = SYSLOG local1

De Sylog attributtet er ikke viktig, og det er mye mindre viktig enn FIL alternativ. Du må virkelig gi xinetd navnet til en loggfil du kan skrive til; trenger du ikke å spesifisere Syslog-nivået for hendelsesmeldinger.

De tilgjengelige rapporteringsalternativene for log_on_success er:

  • PID - 0 hvis det er en intern xinetd-tjeneste
  • HOST - adresse til klienten
  • USERID - identiteten til den eksterne brukeren
  • EXIT - prosess exit status
  • DURATION - varighet av økten

Rapporteringsalternativene for log_on_failure er:

  • HOST - adresse til klienten
  • USERID - identiteten til den eksterne brukeren
  • ATTEMPT - logger et mislykket tilgangsforsøk
  • OPPTAK - all tilgjengelig informasjon om klienten

Du kan inkludere flere alternativer på hver log_on_success og log_on_failure linjer, og de skal skilles med mellomrom uten noen form for tegnsetting. For eksempel:

log_type = FIL / usr / log / internetlog
log_on_success = HOST PID USERID DURATION EXIT
log_on_failure = HOST USERID ATTEMPT RECORD

Det er vanlig å oppbevare log_type, log_in_success og log_on_failure på flere suksessrike linjer i filen.

Kapasitetskontroller

Ytterligere to alternativer som du trenger å sette inn i xinetd.conf begrenser antall samtidige tilkoblinger som serveren din skal godta. Dette er en viktig faktor, og det er en enkel, men kraftfull måte å trounce angrep på Denial of Service (Doial). De to alternativene som implementerer denne strategien er forekomster og per_source.

Forekomstalternativet i standardinnstillingen spesifiserer antall tilkoblinger som xinetd vil tillate å kjøre samtidig, og alternativet per_source spesifiserer antall tilkoblingsforespørsler som demonet vil svare på fra samme kildeadresse. Distribuerte fornektelse av tjenesteangrep (DDoS) vil komme seg rundt per_source-grensen, men ikke forekomstalternativet. Dessverre vil implementeringen av denne tjenestegrensen sperre for ekte brukere i løpet av angrepet.

Formatet for disse to alternativene er veldig rett frem:

= antall.

Verdien per_source skal være lavere enn forekomstverdien.

Standardeksempel

Når du setter sammen alle detaljene som er forklart i dette avsnittet, skal standardinnstillingen for xinetd.conf se slik ut:

mislighold
{
forekomster = 20
per_source = 5
log_type = FIL / usr / log / internetlog
log_on_success = HOST PID USERID DURATION EXIT
log_on_failure = HOST USERID ATTEMPT RECORD
bare_fra =
}

Hver xinetd.conf-fil skal ha en standarderklæring. Du trenger ikke å ha noen tjenesteerklæringer.

Avdelinger for tjenestekonfigurasjon

For hver av tjenestene du vil at serveren din skal levere, bør du skrive en tjenesteinstruksjonsdel i xinetd.conf. Hvis du ikke skriver noen tjenester i konfigurasjonsfilen, bruker xinetd spesifikasjonene som er angitt i standardinnstillingen. Du kan også overskrive innstillingene som er definert i standard-seksjonene ved å legge om attributtene med forskjellige verdier i seksjonen som er skrevet for å definere en tjeneste.

Tjenestetyper

Attributtene som er tilgjengelige for serviceseksjonen er forskjellige for hver av tre kategorier av tjenester. Disse er:

  • INNVENDIG
  • unoterte
  • RPC

Tjenestekategorien (INTERN / UNLISTED / RPC) kan spesifiseres med attributtet type. Denne attributtet er imidlertid ikke obligatorisk og blir ofte utelatt.

Definisjoner av tjenesteattributt

Når du skriver en attributtspesifikasjon, blir alle felt skilt av mellomrom eller vognretur - du bruker ikke noen form for skilletegn eller tegnsetting i definisjonen.

Oppsettet til en tjenesteerklæring er den samme for standardinnstillingen:

service
{
  attributt operatørverdi
}

Operatøren som brukes for attributtuttalelser er vanligvis lik ("=“). Svært få attributter tillater verdier å bli lagt til en eksisterende liste med "+=”Eller tatt av en liste med“-=”- i begge disse tilfellene skriver du operatøren uten sitatene som vises her.

Her er attributtene som er tilgjengelige for en INNVENDIG tjenestetype:

  • socket_type
  • flagg
  • hyggelig
  • vente
  • protokoll (hvis ikke oppført i / etc / services)
  • port (hvis ikke er oppført i / etc / services)
  • cps
  • access_times

Attributtene som er tilgjengelige for en RPC tjenesten er:

  • socket_type
  • flagg
  • bruker
  • serveren
  • server_args
  • hyggelig
  • vente
  • protokollen
  • rpc_version
  • rpc_number
  • cps
  • access_times

De unoterte tjenestetyper kan ha noen av følgende attributter:

  • socket_type
  • flagg
  • bruker
  • serveren
  • server_args
  • max_load
  • hyggelig
  • vente
  • protokoll (hvis ikke oppført i / etc / services)
  • port (hvis ikke er oppført i / etc / services)
  • access_times
  • cps

Tjenesteegenskapsformål

Betydningen av disse attributtene er vist i tabellen nedenfor:

AttributeDescription
type INTERN, RPC, UNLISTED eller INTERNAL UNLISTED
socket_type stream (TCP), dgram (UDP), rå (IP direkte tilgang) eller seqpacket ().
id opprette et unikt navn for denne tjenesten
flagg forklart under tabellen
bruker spesifiserer serverprioriteten
serveren Stien og programmet til tjenesten
server argumenterer argumenter som skal gis med tjenesteanropet
max_load antall samtidige prosesser for en tjeneste
hyggelig øker prioriteringen for tjenesten
vente ja | ingen blokkerer eller tillater samtidig behandling av nye forespørsler
protokollen kan utelates hvis protokollen er oppført i / etc / protokoller
havn portnummer må også finnes i / etc / services og være samme nummer
rpc_version versjon av RPC
rpc_number RPC-nummer
cps tilkoblingsgrense, andre argument er valgfritt og gir antall sekunder å vente når grensen er nådd
access_times timer på dagen når en tjeneste kan kjøres
binde svare på tilkoblinger til en spesifikk IP-adresse
redirect videresender forespørsler om en tjeneste til en annen datamaskin

De flagg attributt kan ha følgende verdier:

IDONLY: bare godta tilkoblinger fra klienter som har en identifikasjonsserver

NORETRY: forhindrer at det opprettes en ny prosess ved tilkoblingssvikt

NAMEINARGS: det første argumentet i server_args er den serveren verdi. Brukes når du ringer tcpd

I tillegg til attributtene ovenfor, kan alternativene som er tilgjengelige i standardavsnittet også skrives inn i en tjenestes definisjon. Disse er:

  • only_from
  • ingen adgang
  • log_type
  • log_on_success
  • log_on_failure
  • forekomster
  • per_source

Bruke disse attributtene igjen vil overskrive alle verdier som er satt for dem i standardinnstillingen. Husk imidlertid at only_from og ingen adgang attributtene er globale, så du må organisere bruken av disse alternativene for å unngå motstridende parametere.

Eksempler på serviceerklæring

Her er to eksempler på definisjonen av en tjeneste.

service ntalk
{
socket_type = dgram
vent = ja
bruker = ingen
server = /usr/sbin/in.ntalkd
tilgangstider = 7: 00-12: 30 13: 30-21: 00
bare_fra 192.168.1.0/24
}

service ftp
{
socket_type = strøm
vent = nei
bruker = rot
server = /usr/sbin/in.ftpd
server_args = -l
forekomster = 4
hyggelig = 10
}

Merk bruken av access_times i ntalk definisjon. Denne bruker to tidsintervaller med fra og til tider atskilt med en bindestrek (“-”) uten mellomrom. De to tidsområdene skilles med et mellomrom. Tidsdefinisjonene bruker 24-timers klokkeformat.

De only_from attributt i ntalk definisjon begrenser tilgangen til denne tjenesten slik at bare adresser i det lokale nettverket kan bruke den.

De ntalk tjenesten har en socket_type av dgram, som betyr at det er en UDP-tjeneste. De socket_type i ftp definisjon er strøm, noe som betyr at dette er en TCP-tjeneste.

Lag flere forekomster av en tjeneste

Tjenestedefinisjonen bruker tjenestenavnet som identifikator som standard. Det kan imidlertid være lurt å lage flere kopier av en tjeneste og gi hver forskjellige attributter. Siden tjenestenavnet må samsvare med navnet som brukes i / etc / services fil, ville det være umulig å få flere versjoner av en tjeneste som kjører. ID-attributtet aktiverer imidlertid denne driftsstrategien.

En veldig vanlig bruk av dette scenariet vil være når du vil opprette forskjellige FTP-servere for intern og ekstern tilgang. Ved å bruke denne metoden kan du holde fillagringen for kontoret helt adskilt fra de nedlastbare filene du gjør tilgjengelig for allmennheten.

I dette tilfellet vil du definere “Service ftp” to ganger. Du vil deretter gi en forekomst attributtet id = ftp-intern og den andre id = ftp-ekstern. Fra da av kan xinetd skille mellom de to. For å gjøre hver forekomst tilgjengelig for forskjellige målgrupper, bruker du only_from attributt for å begrense tilgangen til ftp-interntjenesten til bare adresser i nettverket og tilgang til ftp-ekstern tjeneste til alle ikke-nettverksadresser.

Bind en adresse til en tjeneste

Scenarioet med å lage forskjellige tjenester for interne og eksterne brukere kan bli sterkt hjulpet av bind attributtet. Begrepet "binde”Brukes ofte i TCP-programmering. Det betyr vanligvis å knytte en forbindelse til en port, og dermed opprette en ID for økten. I dette tilfellet betyr "bind" imidlertid noe annerledes. I eksemplet med intern og ekstern tilgang til FTP-serveren, kan du binde datamaskinens nettverksadresse til ftp-intern forekomst og den offentlige IP-adressen til den datamaskinen til ftp-ekstern forekomst.

I dette eksemplet kan det være mulig å utelate den eneste_fra attributtet i tjenestens definisjon. Imidlertid er det tryggere å legge igjen disse begrensningene i. Så den fullstendige definisjonen av interne og eksterne FTP-servere vil være:

service ftp
{
id = ftp-ekstern
server = /usr/sbin/in.ftpd
server_args = -l
forekomster = 4
only_from = 0.0.0.0/0
bind = 202.19.244.130
}

service ftp
{
id = ftp-intern
socket_type = strøm
server = /usr/sbin/in.ftpd
server_args = -l
bare_fra 192.168.1.0/24
bind = 192.168.1.5
}

Denne strategien krever at FTP-serveren din har en statisk IP-adresse tildelt den for offentlig tilgang. Du må også konfigurere DHCP-serveren for å reservere den samme adressen til den interne FTP-serveren. Selv om scenariet ovenfor fungerer når en enkelt datamaskin brukes til både intern og ekstern tilgang, kan du også tildele adressene til separate datamaskiner for hver FTP-forekomst.

Deaktiver inetd-spesifikke tjenester

Det er tre xinetd tjenester som gir informasjon om systemet.

  • servere: rapporter om serverne som er i bruk
  • tjenester: rapporter om tilgjengelige tjenester, protokollene og portene deres
  • xadmin: kombinerer de to kommandoene ovenfor

Disse tjenestene er en sikkerhetssvakhet fordi de kan brukes av hackere for å få informasjon om nettverket og serveren din. Derfor er det bedre å deaktivere dem. Du kan gjøre dette med deaktivert attributt, som går inn i din mislighold definisjon. Bare inkluder følgende linje i standardinnstillingen for å fjerne disse fasilitetene:

deaktivert = servertjenester xadmin

Med konfigurasjonsfilendringene beskrevet ovenfor, kan du nå begynne å bruke xinetd.

Kjører xinetd

Du starter xinetd på kommandolinjen. Kommandoen kan også kjøres fra en batch-fil, slik at du kan legge den til datamaskinens oppstartsprosedyrer. Programmet kan kjøres med følgende alternativer:

SwitchOptionDescription
-d Feilsøkingsmodus
-syslog               syslog_facility Det samme som log_type SYSLOG i konfigurasjonsfilens standardverdier
-FileLog loggfil Det samme som log_type FIL i konfigurasjonsfilen standard
-f  config_file Angir konfigurasjonsfilen - standard er /etc/xinetd.conf
-pidfile pid_file Skriv prosess-ID til pid_file
-hold deg i live Avslutt aldri
-grense proc_limit Maksimum antall prosesser som kan kjøres samtidig
-logprocs grense Maksimalt antall servere som kan kjøres samtidig
-versjon Skriv ut xinetd-versjonen
-inetd_compat Les /etc/inetd.conf så vel som xinetd-konfigurasjonsfilen
-cc intervall Utfør konsistenskontroller hvert intervallsekund

Det er også mulig å starte xinetd uten noen alternativer.

Bruk xinetd

Hvis du har en Linux-datamaskin, har du kanskje allerede installert xinetd. Du kan sjekke ved å løpe xinetd-versjon. Hvis datamaskinen din kjører inetd i stedet, er sjansen stor for at du ikke kjører Linux. Bytt ut programmet med xinetd og konverter konfigurasjonsfilen fra inetd-kompatibilitet til xinetd-bruk som forklart ovenfor.

Bruker du xinetd for øyeblikket? Legg igjen en melding i kommentarer delen nedenfor for å dele dine erfaringer med samfunnet.

Se også: 15 beste gratis Syslog-servere

Bilde: Nettverkstilkobling fra Pixabay. Lisensiert under CC0 Creative Commons

Brayan Jackson
Brayan Jackson Administrator
Sorry! The Author has not filled his profile.
follow me

Add a Comment

Your email address will not be published. Required fields are marked *

52 − = 51