Hosts.allow – Linux-kommando

Finne dine tillatte verter

Du har sannsynligvis landet her på jakt etter en måte å se vertene (andre datamaskiner) få tilgang til Linux system. Vel, med mindre du allerede har satt opp begrensninger, er det sannsynligvis hvilken som helst datamaskin som prøver, som standard.

Egentlig er det ikke helt sant. Uten noen regler definert i /etc/hosts.allow-filen eller /etc/hosts.deny-filen, vil datamaskinen din overføre tilkoblinger til deres respektive applikasjoner. Så hvis noen prøver å koble til SSH, vil tilkoblingen komme til Linux-systemet ditt hvor den vil bli overlevert til SSH for pålogging. Hvis den riktige legitimasjonen ikke er oppgitt, vil tilkoblingen bli nektet.

Hvis visse verter tillates eller nektes, vil Linux først sjekke disse reglene for å se om den innkommende forespørselen bør tillates gjennom. Deretter vil den følge samme mønster som før.

Du kan sjekke tillatte verter ved å liste opp innholdet i filen /etc/hosts.allow.

cat /etc/hosts.allow. 

Hvis du ikke ser noe der, vil systemet sannsynligvis slippe gjennom enhver tilkobling.

Bruke Hosts.allow-filen

/etc/hosts.allow-filen lar deg velge hvilke datamaskiner som har tilgang til systemet ditt. I filen kan du angi enkle regler i ren tekst for å fortelle datamaskinen hvordan den skal håndtere tilkoblinger. For å starte, lag en regel som tillater hvilken som helst datamaskin til alle tjenester.

ALLE: ALLE. 

Så enkelt er det. Deretter, hvis du ønsker å ekskludere en problemdatamaskin, kan du også gjøre det.

ALLE: ALLE UNNTATT 192.168.1.110. 

Det er flere andre nøkkelord som du kan bruke til å håndtere forskjellige sett med datamaskiner. Du kan for eksempel tillate all lokal trafikk som dette:

ALLE: 192.168.1.0/24. 

Eller du kan bruke søkeordet «LOKALT» i stedet.

ALLE: LOKALE. 

Du kan også bruke domenenavn. For eksempel:

ALLE: .example.com. 

Du kan bruke søkeordet «EXCEPT» her også for å ekskludere et potensielt problematisk underdomene.

ALLE: .example.com UNNTATT testing.example.com. 

Du kan også spesifisere regler for spesifikke demoner. Så hvis du ønsker å kontrollere SSH-tilgang, må du sette opp regler for 'sshd.'

sshd: LOKAL. 

Hosts.allow-filen støtter oppføring av daemoner på samme linje, hvis reglene deres er de samme. For eksempel:

sshd, in.ftpd: LOKAL. 

Legg merke til "inn". del i "in.ftpd?" Det lar deg spesifisere innkommende trafikk.

Da har du muligheten til å sette alt sammen.

sshd, in.ftpd: LOKAL UNNTATT 192.168.1.110. 

Dette er de vanligste måtene du vil bruke filen /etc/hosts.allow på Linux-systemet. For en fullstendig teknisk oversikt over hva du kan gjøre med filen /etc/hosts.allow, fortsett til neste seksjon.

Teknisk sammenbrudd

Denne manualsiden beskriver Linux som et enkelt tilgangskontrollspråk som er basert på klient (vertsnavn/adresse, brukernavn) og server (prosessnavn, vertsnavn/adresse) mønstre. Eksempler er gitt til slutt. Den utålmodige leseren oppfordres til å hoppe til Eksempler-delen for en rask introduksjon. En utvidet versjon av tilgangskontrollspråket er beskrevet i hosts_options (5) dokument. Utvidelsene slås på når programmet bygges ved å bygge med —DPROCESS_OPTIONS.

I den følgende teksten, demon er prosessnavnet til en nettverksdemonprosess, og klient er navnet og/eller adressen til en vert som ber om tjeneste. Nettverksdaemon-prosessnavn er spesifisert i inetd-konfigurasjonsfilen.

Tilgangskontrollfiler

Programvaren for tilgangskontroll konsulterer to filer. Søket stopper ved første kamp.

Tilgang vil bli gitt når et (demon, klient) par matcher en oppføring i /etc/hosts.allowfil.

Ellers vil tilgang nektes når et (demon, klient) par samsvarer med en oppføring i/etc/hosts.deny fil.

Ellers vil tilgang bli gitt.

En ikke-eksisterende tilgangskontrollfil behandles som om den var en tom fil. Dermed kan tilgangskontroll slås av ved å ikke gi tilgangskontrollfiler.

Regler for tilgangskontroll

Hver tilgangskontrollfil består av null eller flere linjer med tekst. Disse linjene behandles i rekkefølge etter utseende. Søket avsluttes når et samsvar blir funnet.

Et linjeskifttegn ignoreres når det innledes med et omvendt skråstrektegn. Dette lar deg bryte opp lange linjer slik at de er lettere å redigere.

Tomme linjer eller linjer som begynner med et "#"-tegn ignoreres. Dette lar deg sette inn kommentarer og mellomrom slik at tabellene er lettere å lese.

Alle andre linjer skal tilfredsstille følgende format, ting mellom [] er valgfritt:

daemon_list: client_list [: shell_command ]

daemon_list er en liste over ett eller flere demonprosessnavn (argv[0]-verdier) eller jokertegn (se nedenfor).

client_list er en liste over ett eller flere vertsnavn, vertsadresser, mønstre eller jokertegn (se nedenfor) som vil bli matchet mot klientens vertsnavn eller adresse.

De mer komplekse formene daemon@vert og bruker@vert er forklart i avsnittene om henholdsvis serverendepunktsmønstre og klientbrukernavnoppslag.

Listeelementer skal skilles med tomme og/eller kommaer.

Med unntak av NIS (YP) nettgruppeoppslag, alle tilgangskontroller skiller mellom store og små bokstaver.

Mønstre

Språket for tilgangskontroll implementerer følgende mønstre:

En streng som begynner med et `.' karakter. Et vertsnavn samsvarer hvis de siste komponentene i navnet samsvarer med det angitte mønsteret. For eksempel samsvarer mønsteret `.tue.nl' med vertsnavnet `wzv.win.tue.nl'.

En streng som slutter med en `.' karakter. En vertsadresse matches hvis de første numeriske feltene samsvarer med den gitte strengen. For eksempel, mønsteret "131.155." samsvarer med adressen til (nesten) hver vert på Eindhoven University-nettverket (131.155.x.x).

En streng som begynner med et `@'-tegn behandles som et NIS (tidligere YP) nettgruppenavn. EN vertsnavn matches hvis det er et vertsmedlem av den angitte nettgruppen. Nettgruppetreff støttes ikke for demonprosessnavn eller for klientbrukernavn.

Et uttrykk for formen `n.n.n.n/m.m.m.m' tolkes som et `nett/maske'-par. En IPv4-vertsadresse matches hvis 'net' er lik den bitvise AND for adressen og 'masken'. Nett/maskemønsteret «131.155.72.0/255.255.254.0» samsvarer for eksempel med hver adresse i området «131.155.72.0» til og med «131.155.73.255».

Et uttrykk for formen `[n: n: n: n: n: n: n: n]/m' tolkes som et `[net]/prefikslen'-par. En IPv6-vertsadresse matches hvis 'prefikslen' biter av 'net' er lik 'prefikslen'-bitene til adressen. For eksempel, [net]/prefiks-mønsteret `[3ffe: 505:2:1::]/64' samsvarer med hver adresse i området `3ffe: 505:2:1::' til og med `3ffe: 505:2: 1:ffff: ffff: ffff: ffff'.

En streng som begynner med et `/'-tegn behandles som en filnavn. Et vertsnavn eller adresse matches hvis det samsvarer med et vertsnavn eller adressemønster som er oppført i den navngitte filen. Filformatet er null eller flere linjer med null eller flere vertsnavn eller adressemønstre atskilt med mellomrom. Et filnavnmønster kan brukes hvor som helst et vertsnavn eller adressemønster kan brukes.

Jokertegn `*' og `?' kan brukes til å matche vertsnavn eller IP-adresser. Denne metoden for matching kan ikke brukes sammen med `net/mask'-matching, hostname-matching begynner med `.' eller IP-adresse som slutter med `.'.

Jokertegn

Språket for tilgangskontroll støtter eksplisitte jokertegn inkludert:

• 'ALLE' — Det universelle jokertegnet, matcher alltid.
• 'LOKAL' – Matcher enhver vert hvis navn ikke inneholder et prikktegn.
• 'UKJENT' — Matcher enhver bruker hvis navn er ukjent, og samsvarer med alle vertsnavn eller adressen er ukjent. Dette mønsteret bør brukes med forsiktighet: vertsnavn kan være utilgjengelige på grunn av midlertidige navneserverproblemer. EN nettverksadresse vil være utilgjengelig når programvaren ikke kan finne ut hvilken type nettverk den snakker med.
• 'KJENT' — Matcher enhver bruker hvis navn er kjent, og samsvarer med alle vertsnavn og adressen er kjent. Dette mønsteret bør brukes med forsiktighet: vertsnavn kan være utilgjengelige på grunn av midlertidige navneserverproblemer. En nettverksadresse vil være utilgjengelig når programvaren ikke kan finne ut hvilken type nettverk den snakker til.
• 'PARANOID' — Matcher enhver vert hvis navn ikke samsvarer med adressen. Når tcpd er bygget med -DPARANOID (standardmodus), slipper den forespørsler fra slike klienter selv før de ser på tilgangskontrolltabellene. Bygg uten -DPARANOID når du vil ha mer kontroll over slike forespørsler.

'OPERATORER'

• 'UNNTATT' —Tenkt bruk er av formen: `liste_1 UNNTATT liste_2'; denne konstruksjonen samsvarer med alt som passer liste_1 med mindre det stemmer liste_2. EXCEPT-operatoren kan brukes i daemon_lists og i client_lists. EXCEPT-operatoren kan nestes: hvis kontrollspråket tillater bruk av parenteser, vil `a EXCEPT b EXCEPT c' analysere som `(a EXCEPT (b EXCEPT c))'.
• Shell-kommandoer —Hvis den første-matchede tilgangskontrollregelen inneholder en shell-kommando, blir den kommandoen utsatt for %substitusjoner (se neste avsnitt). Resultatet utføres av en /bin/sh barneprosess med standard inngang, utgang og feil koblet til /dev/null. Angi en "&" på slutten av terminalkommando hvis du ikke vil vente til den er fullført. Shell-kommandoer bør ikke stole på PATH-innstillingen til inetd. I stedet bør de bruke absolutte banenavn, eller de bør begynne med en eksplisitt PATH=whatever-setning.

De hosts_options(5) dokumentet beskriver et alternativt språk som bruker shell-kommandofeltet på en annen og inkompatibel måte.

% utvidelser

Følgende utvidelser er tilgjengelige i skallkommandoer:

• %a (%A) — Klienten (serveren) vert adresse.
• %c — Klientinformasjon: bruker@vert, bruker@adresse, et vertsnavn eller bare en adresse, avhengig av hvor mye informasjon som er tilgjengelig.
• %d — Daemonprosessnavnet (argv[0]-verdi).
• %h (%H) — Klientens (server) vertsnavn eller adresse, hvis vertsnavnet ikke er tilgjengelig.
• %n (%N) — Klientens (server) vertsnavn (eller «ukjent» eller «paranoid»).
• %p — Daemon-prosess-ID.
• %s — Serverinformasjon: daemon@host, daemon@address, eller bare et daemonnavn, avhengig av hvor mye informasjon som er tilgjengelig.
• %u — Klientens brukernavn (eller "ukjent").
• %% — Utvides til et enkelt `%'-tegn.

Tegn i % utvidelser som kan forvirre skallet, erstattes av understrekinger.

Serverendepunktsmønstre

For å skille klienter med nettverksadressen de kobler til, bruk mønstre av skjemaet:

prosessnavn@vertsmønster: klientliste... 

Mønstre som disse kan brukes når maskinen har forskjellige internettadresser med forskjellige internettvertsnavn. Tjenesteleverandører kan bruke denne funksjonen til å tilby FTP-, GOPHER- eller WWW-arkiver med internettnavn som til og med kan tilhøre forskjellige organisasjoner. Se også 'vri'-alternativet i dokumentet hosts_options (5). Noen systemer (Solaris, FreeBSD) kan ha mer enn én internettadresse på ett fysisk grensesnitt; med andre systemer må du kanskje ty til SLIP- eller PPP-pseudogrensesnitt som lever i et dedikert nettverksadresserom.

Host_pattern følger de samme syntaksreglene som vertsnavn og adresser i klientlistekontekst. Vanligvis er serverendepunktinformasjon kun tilgjengelig med tilkoblingsorienterte tjenester.

Oppslag av klientbrukernavn

Når klientverten støtter RFC 931-protokollen eller en av dens etterkommere (TAP, IDENT, RFC 1413) kan innpakningsprogrammene hente ytterligere informasjon om eieren av en tilkobling. Klientbrukernavninformasjon, når tilgjengelig, logges sammen med klientvertsnavnet, og kan brukes til å matche mønstre som:

daemon_list:... user_pattern@host_pattern... 

Daemon-innpakningene kan konfigureres på kompileringstidspunktet for å utføre regeldrevne brukernavnoppslag (standard) eller for alltid å spørre klientverten. Når det gjelder regeldrevne brukernavnoppslag, vil regelen ovenfor føre til brukernavnoppslag bare når både daemon_list og vertsmønsterkamp.

Et brukermønster har samme syntaks som et daemon-prosessmønster, så de samme jokertegnene gjelder (nettgruppemedlemskap støttes ikke). Man bør imidlertid ikke la seg rive med av oppslag av brukernavn.

Klientbrukernavninformasjonen kan ikke stoles på når den er mest nødvendig, det vil si når klientsystemet har blitt kompromittert. Generelt er ALL og (UN)KNOWN de eneste brukernavnmønstrene som gir mening.

Brukernavnoppslag er bare mulig med TCP-baserte tjenester, og kun når klientverten kjører en passende demon; i alle andre tilfeller er resultatet "ukjent".

En velkjent UNIX kjernefeil kan forårsake tap av tjeneste når brukernavnoppslag blokkeres av en brannmur. Wrapper README-dokumentet beskriver en prosedyre for å finne ut om kjernen din har denne feilen.

Brukernavnoppslag kan forårsake merkbare forsinkelser for ikke-UNIX-brukere. Standard tidsavbrudd for brukernavnoppslag er 10 sekunder: for kort til å takle trege nettverk, men lang nok til å irritere PC-brukere.

Selektive brukernavnoppslag kan lindre det siste problemet. For eksempel en regel som:

daemon_list: @pcnetgroup ALL@ALL. 

ville matche medlemmer av PC-nettgruppen uten å gjøre brukernavnoppslag, men ville utføre brukernavnoppslag med alle andre systemer.

Oppdager adresseforfalskningsangrep

En feil i sekvensnummergeneratoren til mange TCP/IP-implementeringer lar inntrengere enkelt utgi seg for pålitelige verter og bryte seg inn via for eksempel den eksterne skalltjenesten. IDENT (RFC931 etc.)-tjenesten kan brukes til å oppdage slike og andre vertsadresseforfalskningsangrep.

Før de godtar en klientforespørsel, kan wrapperne bruke IDENT-tjenesten for å finne ut at klienten ikke sendte forespørselen i det hele tatt. Når klientverten tilbyr IDENT-tjeneste, er et negativt IDENT-oppslagsresultat (klienten samsvarer med `UNKNOWN@host') et sterkt bevis på et vertsforfalskningsangrep.

Et positivt IDENT-oppslagsresultat (klienten samsvarer med `KNOWN@host') er mindre pålitelig. Det er mulig for en inntrenger å forfalske både klienttilkoblingen og IDENT-oppslaget, selv om det er mye vanskeligere enn å forfalske bare en klienttilkobling. Det kan også være at klientens IDENT-server lyver.

Flere eksempler

Språket er fleksibelt nok til at ulike typer tilgangskontrollpolitikk kan uttrykkes med et minimum av oppstyr. Selv om språket bruker to tilgangskontrolltabeller, kan de vanligste policyene implementeres med en av tabellene som er triviell eller til og med tom.

Når du leser eksemplene nedenfor, er det viktig å innse at tillatelsestabellen skannes før avslaget tabell, at søket avsluttes når en treff er funnet, og at tilgang gis når ingen treff er funnet på alle.

Eksemplene bruker verts- og domenenavn. De kan forbedres ved å inkludere adresse- og/eller nettverks-/nettmaskeinformasjon for å redusere virkningen av midlertidige navneserveroppslagsfeil.

Stort sett stengt

I dette tilfellet nektes tilgang som standard. Bare eksplisitt autoriserte verter har tilgang.

Standardpolicyen (ingen tilgang) implementeres med en triviell avvisningsfil:

/etc/hosts.deny:

ALLE: ALLE. 

Dette nekter all service til alle verter, med mindre de får tilgang av oppføringer i tillat-filen.

De eksplisitt autoriserte vertene er oppført i tillatelsesfilen. For eksempel:

/etc/hosts.allow:

ALLE: LOKALE @some_netgroup
ALLE: .foobar.edu UNNTATT terminalserver.foobar.edu. 

Den første regelen tillater tilgang fra verter i lokalt domene (ingen `.' i vertsnavnet) og fra medlemmer av noen_nettgruppe nettgruppe. Den andre regelen tillater tilgang fra alle verter ifoobar.edu domene (legg merke til den innledende prikken), med unntak av terminalserver.foobar.edu.

Stort sett åpen

Her gis tilgang som standard; bare eksplisitt spesifiserte verter nektes tjeneste.

Standardpolicyen (tilgang gitt) gjør tillat-filen overflødig slik at den kan utelates. De eksplisitt ikke-autoriserte vertene er oppført i avvisningsfilen. For eksempel:

/etc/hosts.deny:

ALLE: noen.vertsnavn, .noen.domene
ALLE: ALLE UNNTATT i.fingerd: annet.vertsnavn, .annet.domene. 

Den første regelen nekter noen verter og domener alle tjenester; den andre regelen tillater fortsatt fingerforespørsler fra andre verter og domener.

Booby feller

Det neste eksemplet tillater det tftp-forespørsler fra verter i det lokale domenet (legg merke til den innledende prikken). Forespørsler fra andre verter blir avvist. I stedet for den forespurte filen, sendes en fingersonde til den fornærmende verten. Resultatet sendes til superbrukeren.

/etc/hosts.allow:

in.tftpd: LOKAL, .mitt.domene
/etc/hosts.deny:
in.tftpd: ALLE: spawn (/some/where/safe_finger -l @%h | \
/usr/ucb/mail -s %d-%h rot) &

safe_finger-kommandoen følger med tcpd-omslaget og bør installeres på et passende sted. Det begrenser mulig skade fra data sendt av den eksterne fingerserveren. Det gir bedre beskyttelse enn standard fingerkommando.

Utvidelsen av sekvensene %h (klientvert) og %d (tjenestenavn) er beskrevet i avsnittet om skallkommandoer.

På nettverk brannmursystemer dette trikset kan bæres enda lenger. Den typiske nettverksbrannmuren gir bare et begrenset sett med tjenester til den ytre verden. Alle andre tjenester kan "bugges" akkurat som tftp-eksemplet ovenfor. Resultatet er et utmerket tidlig varslingssystem.

Se også

tcpd (8) tcp/ip daemon wrapper-program.
tcpdchk (8), tcpdmatch (8), testprogrammer.