NAME
hosts_access - યજમાન પ્રવેશ નિયંત્રણ ફાઈલોનું બંધારણ
DESCRIPTION
આ માર્ગદર્શિકા પેજ સરળ વપરાશ નિયંત્રણ ભાષા વર્ણવે છે જે ક્લાયન્ટ (યજમાન નામ / સરનામું, વપરાશકર્તા નામ) અને સર્વર (પ્રક્રિયા નામ, યજમાન નામ / સરનામું) પેટર્ન પર આધારિત છે. ઉદાહરણો ઓવરને અંતે આપવામાં આવે છે ઉત્સુક વાચકને ઝડપી પરિચય માટે EXAMPLES વિભાગમાં જવા માટે પ્રોત્સાહિત કરવામાં આવે છે .એસેસ નિયંત્રણ ભાષાના વિસ્તૃત વર્ઝનને hosts_options (5) દસ્તાવેજમાં વર્ણવેલ છે. -PROCESS_OPTIONS સાથે નિર્માણ કરીને એક્સ્ટેન્શન્સ પ્રોગ્રામ બિલ્ડ ટાઇમમાં ચાલુ થાય છે.
નીચેના લખાણમાં, ડિમન એ નેટવર્ક ડિમન પ્રક્રિયાનું પ્રક્રિયા નામ છે, અને ક્લાઈન્ટ એ યજમાન વિનંતી સેવાનો નામ અને / અથવા સરનામું છે. નેટવર્ક ડિમન પ્રક્રિયા નામો inetd રૂપરેખાંકન ફાઈલમાં સ્પષ્ટ થયેલ છે.
ઍક્સેસ નિયંત્રણ ફાઇલો
વપરાશ નિયંત્રણ સૉફ્ટવેર બે ફાઇલોનો વિચાર કરે છે શોધ પ્રથમ મેચમાં અટકે છે
જ્યારે ડિમન, ક્લાયન્ટ પેજ /etc/hosts.allow ફાઇલમાં પ્રવેશ સાથે મેળ ખાય છે ત્યારે ઍક્સેસ આપવામાં આવશે.
નહિંતર, જ્યારે કોઈ (ડિમન, ક્લાયન્ટ) જોડી /etc/hosts.deny ફાઇલમાં કોઈ પ્રવેશ સાથે મેળ ખાશે ત્યારે ઍક્સેસ નકારી શકાશે.
નહિંતર, ઍક્સેસ મંજૂર કરવામાં આવશે.
બિન-અસ્તિત્વમાંની ઍક્સેસ નિયંત્રણ ફાઇલને માનવામાં આવે છે કે તે એક ખાલી ફાઇલ છે. આમ, એક્સેસ કંટ્રોલ ફાઇલો આપીને એક્સેસ કંટ્રોલ બંધ કરી શકાય છે.
ACCESS CONTROL RULES
દરેક એક્સેસ કન્ટ્રોલ ફાઇલમાં શૂન્ય અથવા વધુ લીટીઓની ટેક્સ્ટનો સમાવેશ થાય છે. આ લીટીઓ દેખાવના આધારે પ્રક્રિયા કરવામાં આવે છે. જ્યારે શોધ મળે ત્યારે શોધ અંત થાય છે
એક નવી અક્ષરને અવગણવામાં આવે છે જ્યારે તે બેકસ્લેશ અક્ષર દ્વારા આગળ આવે છે. આ તમને લાંબા રેખાઓ તોડવા માટે પરવાનગી આપે છે જેથી તે ફેરફાર કરવા માટે સરળ હોય.
ખાલી રેખાઓ અથવા રેખાઓ જે '#' અક્ષરથી શરૂ થાય છે તે અવગણવામાં આવે છે. આ તમને ટિપ્પણીઓ અને સફેદજગ્યાના દાખલ કરવા માટે પરવાનગી આપે છે જેથી કોષ્ટકો વાંચવામાં સરળ હોય.
અન્ય બધી લીટીઓ નીચેના બંધારણને સંતોષવી જોઈએ, [] વૈકલ્પિક હોવાના મુદ્દાઓ:
daemon_list: client_list [: shell_command]
daemon_list એક અથવા વધુ ડિમન પ્રક્રિયા નામોની યાદી છે (argv [0] કિંમતો) અથવા વાઇલ્ડકાર્ડ (નીચે જુઓ).
client_list એ એક અથવા વધુ યજમાન નામો, યજમાન સરનામાંઓ, પેટર્ન અથવા વાઇલ્ડકાર્ડ્સની યાદી છે (નીચે જુઓ) કે જે ક્લાઈન્ટ યજમાન નામ અથવા સરનામાથી મેળ ખાશે.
વધુ જટિલ સ્વરૂપો ડિમન @ યજમાન અને વપરાશકર્તા @ યજમાનને અનુક્રમે સર્વર એન્ડપોઇન્ટ પેટર્ન અને ક્લાયંટ યુઝરર્સ લૂકઅપ પરનાં વિભાગોમાં સમજાવાયેલ છે.
યાદી ઘટકો બ્લેન્ક્સ અને / અથવા અલ્પવિરામ દ્વારા અલગ પાડવામાં આવવી જોઈએ.
NIS (YP) નેટગ્રુપ લુકઅપોના અપવાદ સાથે, બધી ઍક્સેસ નિયંત્રણ તપાસમાં કેસ પ્રત્યે સંવેદનશીલ છે.
PATTERNS
ઍક્સેસ નિયંત્રણ ભાષા નીચેની પધ્ધતિનો અમલ કરે છે:
એક શબ્દમાળા જે `. અક્ષર યજમાનનું નામ સરખું છે જો તેનું નામના છેલ્લા ઘટકો સ્પષ્ટ પેટર્ન સાથે મેળ ખાય છે. ઉદાહરણ તરીકે, `` .tue.nl 'નમૂનો યજમાન નામ `wzv.win.tue.nl' સાથે મેળ ખાય છે.
એક શબ્દમાળા જે '.' સાથે અંત થાય છે અક્ષર યજમાન સરનામું મેળ ખાતું હોય છે જો તેના પ્રથમ આંકડાકીય ક્ષેત્રો આપેલ શબ્દમાળા સાથે બંધબેસે છે. ઉદાહરણ તરીકે, પેટર્ન '131.155.' આઈંડહોવન યુનિવર્સિટી નેટવર્ક (131.155.xx) પરના દરેક હોસ્ટના (લગભગ) સરનામાના મેળ ખાતા.
એક શબ્દમાળા જે `@ 'અક્ષરથી શરૂ થાય છે તે NIS (અગાઉ વાયપી) નેટગુપ નામ તરીકે ગણવામાં આવે છે. યજમાનનું નામ સરખું છે જો તે સ્પષ્ટ થયેલ નેટ ગૃપનું યજમાન સભ્ય છે. ડિમેટ પ્રક્રિયા નામો માટે અથવા ક્લાયંટ વપરાશકર્તા નામો માટે નેટગુપ મેચો સપોર્ટેડ નથી.
`Nnnn / mmmm 'ફોર્મની અભિવ્યક્તિને` નેટ / માસ્ક' જોડી તરીકે વર્ણવવામાં આવે છે. IPv4 હોસ્ટનું સરનામું સરખું આવે છે જો 'નેટ' એ બીટવુ અને એડેસ અને `માસ્ક 'બરાબર હોય. ઉદાહરણ તરીકે, નેટ / માસ્ક પેટર્ન `131.155.72.0/255.255.254.0 '` 131.155.72.0' થી `131.155.73.255 'સુધીની દરેક સરનામાંને મેળ ખાય છે.
ફોર્મ `[n: n: n: n: n: n: n: n] 'મીટર' ની અભિવ્યક્તિ '[નેટ] / પ્રિફિક્સલન' જોડી તરીકે અર્થઘટન કરવામાં આવે છે. 'નેટ' ના `પ્રિફિક્સલાન 'બિટ્સ સરનામાંના' પ્રિફિક્સલાન 'બિટ્સ જેટલા હોય તો IPv6 હોસ્ટનું સરનામું મેળ ખાય છે. ઉદાહરણ તરીકે, [ચોખ્ખો] / પ્રીફિક્સલેન પેટર્ન '[3ffe: 505: 2: 1 ::] / 64' શ્રેણીમાં દરેક સરનામાં સાથે મેળ ખાય છે '3ffe: 505: 2: 1 ::' '3ffe: 505: 2 દ્વારા: 1: એફએફએફ: એફએફએફ: એફએફએફ: એફએફએફ '.
એક શબ્દમાળા કે જે `/ 'અક્ષરથી શરૂ થાય છે તે ફાઈલ નામ તરીકે ગણવામાં આવે છે. કોઈ યજમાન નામ અથવા સરનામું મેળ ખાતું હોય તો તે નામવાળી ફાઇલમાં સૂચિબદ્ધ કોઈપણ હોસ્ટ નામ અથવા સરનામું પેટર્ન સાથે મેળ ખાય છે. ફાઇલ ફોર્મેટ શૂન્ય અથવા વધુ રેખાઓ શૂન્ય અથવા વધુ યજમાન નામ અથવા સરનામાંના પેટર્ન સાથે સફેદ જગ્યા દ્વારા અલગ થયેલ છે. એક ફાઇલ નામ પેટર્ન ગમે ત્યાં ઉપયોગ કરી શકે છે યજમાન નામ અથવા સરનામું પેટર્ન ઉપયોગ કરી શકાય છે.
વાઇલ્ડકાર્ડ્સ `* 'અને`?' હોસ્ટનામ અથવા IP સરનામાઓ સાથે મેળ કરવા માટે વાપરી શકાય છે. મેચિંગની આ પદ્ધતિ `નેટ / માસ્ક 'મેચિંગ સાથે ઉપયોગમાં લઈ શકાતી નથી, યજમાનનામ'. અથવા '.'
વાઇલ્ડકાર્ડ્સ
ઍક્સેસ નિયંત્રણ ભાષા સ્પષ્ટ વાઈલ્ડકાર્ડ્સને સપોર્ટ કરે છે:
બધા
સાર્વત્રિક વાઇલ્ડકાર્ડ, હંમેશાં મેળ ખાય છે
લોકલ
કોઈપણ યજમાન સાથે મેળ ખાય છે જેના નામમાં કોઈ પાત્ર નથી.
UNKNOWN
કોઈ પણ વપરાશકર્તા સાથે જોડાય છે જેની નામ અજ્ઞાત છે, અને તે કોઈ પણ હોસ્ટ સાથે મેળ ખાય છે જેની નામ અથવા સરનામું અજ્ઞાત છે. આ પધ્ધતિનો ઉપયોગ સંભાળ સાથે થવો જોઈએ: હંગામી નામ સર્વર સમસ્યાઓને લીધે હોસ્ટ નામો અનુપલબ્ધ હોઈ શકે છે. કોઈ નેટવર્ક સરનામું અનુપલબ્ધ હશે, જ્યારે સૉફ્ટવેર સમજી શકશે નહીં કે જેની સાથે તે વાત કરી રહેલી નેટવર્ક છે.
KNOWN
કોઈ પણ વપરાશકર્તા સાથે જોડાય છે જેની નામ ઓળખાય છે, અને તે કોઈપણ હોસ્ટ સાથે મેળ ખાય છે જેની નામ અને સરનામું ઓળખાય છે. આ પધ્ધતિનો ઉપયોગ સંભાળ સાથે થવો જોઈએ: હંગામી નામ સર્વર સમસ્યાઓને લીધે હોસ્ટ નામો અનુપલબ્ધ હોઈ શકે છે. કોઈ નેટવર્ક સરનામું અનુપલબ્ધ હશે, જ્યારે સૉફ્ટવેર સમજી શકશે નહીં કે જેની સાથે તે વાત કરી રહેલી નેટવર્ક છે.
PARANOID
કોઈ પણ યજમાન સાથે જોડાય છે જેની નામ તેના સરનામાં સાથે મેળ ખાતું નથી. જ્યારે tcpd -DPARANOID (ડિફૉલ્ટ મોડ) સાથે બનેલ છે, ત્યારે તે ઍક્સેસ નિયંત્રણ કોષ્ટકોને જોઈને તે પહેલાં પણ આવા ક્લાયંટ્સની વિનંતીઓ નહીં કરે વગર -DPARANOID બનાવો જ્યારે તમને આવા અરજીઓ પર વધુ નિયંત્રણની જરૂર હોય.
ઓપરેટર
સિવાય
હેતુપૂર્વકનો ઉપયોગ ફોર્મની છે: 'list_1 દૂર કરો યાદી' '; આ નિર્માણ મેચ સાથે લડે છે જે સૂચિ સાથે મેળ ખાય છે . EXCEPT ઑપરેટરનો ઉપયોગ daemon_lists અને client_lists માં કરી શકાય છે. EXCEPT ઑપરેટરને નેસ્ટ કરી શકાય છે: જો કંટ્રોલ લેંગ્વેજ કૌંસના ઉપયોગની પરવાનગી આપશે, તો 'EXCEPT b સિવાય C' `(EXCEPT (B EXCEPT C)) તરીકે વિશ્લેષિત કરશે '.
જો પ્રથમ મેળ ખાતી એક્સેસ કન્ટ્રોલ નિયમમાં શેલ આદેશનો સમાવેશ થાય છે, તો તે આદેશને% અવેજીમાં (આગલા વિભાગને જુઓ) આધિન છે. પરિણામ / bin / sh બાળક પ્રક્રિયા દ્વારા પ્રમાણભૂત ઇનપુટ, આઉટપુટ અને / dev / null સાથે જોડાયેલ ભૂલ સાથે ચલાવવામાં આવે છે. જો તમે પૂર્ણ ન થાય ત્યાં સુધી રાહ જોવી ન માંગતા હોવ તો આદેશના અંતે `અને 'સ્પષ્ટ કરો.
શેલ આદેશો INETD ની પીએટીએચ (PATH) સેટિંગ પર આધારિત ન હોવો જોઈએ. તેના બદલે, તેઓએ સંપૂર્ણ પાથ નામોનો ઉપયોગ કરવો જોઈએ, અથવા તેઓ સ્પષ્ટ રીતે પીએટીએચ (PATH) = ગમે તે વિધાનથી શરૂ થવું જોઈએ.
Hosts_options (5) દસ્તાવેજ એક વૈકલ્પિક ભાષા વર્ણવે છે જે શેલ આદેશ ક્ષેત્રનો ઉપયોગ અલગ અને અસંગત રીતે કરે છે.
% વિસ્તરણ
નીચેના વિસ્તરણ શેલ આદેશોમાં ઉપલબ્ધ છે:
% a (% A)
ક્લાયન્ટ (સર્વર) હોસ્ટ એડ્રેસ
% c
ગ્રાહક માહિતી: કેટલી માહિતી ઉપલબ્ધ છે તેના આધારે વપરાશકર્તા @ હોસ્ટ, વપરાશકર્તા @ સરનામું, એક યજમાનનું નામ, અથવા માત્ર એક સરનામું,
% d
ડિમન પ્રક્રિયા નામ (argv [0] મૂલ્ય).
%એચએચ)
ક્લાયંટ (સર્વર) હોસ્ટ નામ અથવા સરનામું, જો હોસ્ટનું નામ અનુપલબ્ધ હોય.
% n (% N)
ક્લાયંટ (સર્વર) હોસ્ટ નામ (અથવા "અજ્ઞાત" અથવા "પેરાનોઇડ").
% p
ડિમન પ્રક્રિયા id
% s
સર્વર માહિતી: ડિમન @ યજમાન, ડિમન @ સરનામું, અથવા માત્ર એક ડિમન નામ, કેટલી માહિતી ઉપલબ્ધ છે તેના આધારે.
% u
ગ્રાહક વપરાશકર્તા નામ (અથવા "અજ્ઞાત").
%%
એક ``% અક્ષર વિસ્તૃત.
% વિસ્તરણના પાત્રો જે શેલને મૂંઝવણમાં મૂકે છે તે અંડરસ્કોર્સ દ્વારા બદલાઈ જાય છે.
સર્વર ENDPOINT પેટર્ન
નેટવર્ક સરનામા દ્વારા ક્લાયન્ટ્સને અલગ પાડવા માટે કે જે તેઓ સાથે જોડાય છે, ફોર્મના પેટર્નનો ઉપયોગ કરો:
process_name @ host_pattern: client_list ...
આ પ્રકારના દાખલાઓનો ઉપયોગ ત્યારે કરી શકાય છે જ્યારે મશીનની અલગ ઇન્ટરનેટ હોસ્ટ નામો સાથે અલગ ઇન્ટરનેટ સરનામાંઓ હોય છે. સર્વિસ પ્રોવાઇડર્સ આ સુવિધાને ઇન્ટરનેટ નામો સાથે FTP, GOPHER અથવા WWW આર્કાઇવ્સ પ્રદાન કરવા માટે ઉપયોગ કરી શકે છે જે વિવિધ સંગઠનોની પણ હોઈ શકે છે. યજમાન_ઉપકરણો (5) દસ્તાવેજમાં `ટ્વિસ્ટ 'વિકલ્પ પણ જુઓ. કેટલાક સિસ્ટમો (સોલારિસ, ફ્રીબીએસડી) એક ભૌતિક ઇન્ટરફેસ પર એક કરતાં વધુ ઇન્ટરનેટ સરનામાં ધરાવી શકે છે; અન્ય સિસ્ટમો સાથે તમારે કદાચ એસએલઆઇપી અથવા પી.પી.પી. સ્યુડો ઇન્ટરફેસોનો ઉપયોગ કરવો પડશે જે સમર્પિત નેટવર્ક એડ્રેસ સ્પેસમાં રહે છે.
Host_pattern એ એજ વાક્યરચના નિયમોને હોસ્ટ નામો અને સરનામાંઓ તરીકે ક્લાયંટના સંદર્ભમાં રજૂ કરે છે. સામાન્ય રીતે, સર્વર એન્ડપોઇન્ટ માહિતી માત્ર કનેક્શન-લક્ષી સેવાઓ સાથે ઉપલબ્ધ છે.
ક્લાયન્ટ USERNAME લુકઅપ
જ્યારે ક્લાઈન્ટ યજમાન RFC 931 પ્રોટોકોલ અથવા તેના વંશજો (ટેપ, IDENT, RFC 1413) ને ટેકો આપે છે ત્યારે રેપર પ્રોગ્રામ્સ જોડાણના માલિક વિશે વધારાની માહિતી મેળવી શકે છે. ગ્રાહક વપરાશકર્તાનામની જાણકારી, જ્યારે ઉપલબ્ધ હોય, ત્યારે ક્લાઈન્ટ યજમાનનામ સાથે મળીને લોગ થયેલ છે, અને આની જેમ પેટર્નને મેચ કરવા માટે વાપરી શકાય છે:
daemon_list: ... user_pattern @ host_pattern ...
નિયમ-આધારિત વપરાશકર્તાનામ દેખાવ (મૂળભૂત) કરવા અથવા હંમેશા ક્લાઈન્ટ યજમાન પૂછપરછ કરવા માટે સમયને સંકલન કરવા માટે ડિમન આવરણો રૂપરેખાંકિત કરી શકાય છે. નિયમ-આધારિત વપરાશકર્તાનામના કિસ્સામાં, ઉપરોક્ત નિયમ વપરાશકર્તાનામના લુકઅપને કારણભૂત બનાવશે જ્યારે ડિમન_list અને host_pattern બંને મેચ હશે.
વપરાશકર્તા પેટર્ન એ ડિમન પ્રોસેસ પેટર્ન જેવું જ વાક્યરચના ધરાવે છે, તેથી સમાન વાઇલ્ડકાર્ડ્સ લાગુ થાય છે (નેટજોડ સભ્યપદ સપોર્ટેડ નથી). એક વપરાશકર્તાનામ લુકઅપો સાથે દૂર ન થવું જોઈએ, છતાં.
ગ્રાહકના વપરાશકર્તાનામ પર વિશ્વસનીયતા ન આવી શકે જ્યારે તેની સૌથી વધુ જરૂર હોય, એટલે કે જ્યારે ક્લાઈન્ટ સિસ્ટમને સમાધાન કરવામાં આવ્યું હોય. સામાન્ય રીતે, ALL અને (UN) KNOWN એ માત્ર વપરાશકર્તાના નામની રીતો છે જે અર્થમાં બનાવે છે.
વપરાશકર્તાનામ લેપટોપ માત્ર TCP- આધારિત સેવાઓ સાથે શક્ય છે, અને જ્યારે ક્લાઈન્ટ યજમાન યોગ્ય ડિમન ચલાવે છે; અન્ય તમામ કિસ્સાઓમાં પરિણામ "અજ્ઞાત" છે.
જાણીતા UNIX કર્નલ બગ ફાયરવૉલ દ્વારા વપરાશકર્તાનામનાં જોબ્સને અવરોધિત કરે ત્યારે સેવાની ખોટ થઇ શકે છે. રેપર README દસ્તાવેજ એ શોધવા માટે એક પ્રક્રિયા વર્ણવે છે કે તમારી કર્નલમાં આ બગ છે.
વપરાશકર્તા નામ લૂકઅપ બિન- UNIX વપરાશકર્તાઓ માટે નોંધપાત્ર વિલંબનું કારણ બની શકે છે. વપરાશકર્તાની સૂચિ માટે ડિફૉલ્ટ સમયસમાપ્તિ 10 સેકન્ડ છે: ધીમા નેટવર્ક્સથી સામનો કરવા માટે ખૂબ જ ટૂંકો હોય છે, પરંતુ પીસી વપરાશકર્તાઓને ખીજાવવો તેટલી લાંબી છે
પસંદગીયુક્ત વપરાશકર્તાનામ લુકઅપ્સ છેલ્લા સમસ્યાને દૂર કરી શકે છે. ઉદાહરણ તરીકે, આના જેવા નિયમ:
daemon_list: @pcnetgroup ALL @ ALL
યુઝરનેમ લૂકઅપની વગર પીસી નેટજુપના સભ્યો સાથે મેળ ખાય છે, પરંતુ અન્ય બધી સિસ્ટમો સાથે વપરાશકર્તાનામ દેખાવ રજૂ કરશે
સરનામું શોધવાની સ્પાઇફિંગ હુમલો
ઘણા ટીસીપી / આઈપી અમલીકરણના અનુક્રમ નંબર જનરેટરના પ્રવાહમાં વિશ્વસનીય યજમાનોને સહેલાઈથી નકલ કરાવવા અને મારફતે તોડવા માટે પરવાનગી આપે છે, ઉદાહરણ તરીકે, દૂરસ્થ શેલ સેવા IDENT (RFC931 વગેરે) સેવાનો ઉપયોગ આવા અને અન્ય હોસ્ટ સરનામાંના સ્પુફીંગ હુમલાઓને શોધવા માટે થઈ શકે છે.
ક્લાઈન્ટની વિનંતી સ્વીકારતા પહેલાં, રેપરર્સ IDENT સર્વિસનો ઉપયોગ કરી શકે છે તે જાણવા માટે કે ક્લાઈન્ટે તે વિનંતી મોકલી ન હતી. જ્યારે ગ્રાહક યજમાન IDENT સેવા પૂરી પાડે છે, નકારાત્મક IDENT લૂકઅપ પરિણામ (ક્લાયન્ટ 'UNKNOWN @ host' સાથે મેળ ખાય છે) યજમાન સ્પુફીંગ હુમલાના મજબૂત પુરાવા છે.
હકારાત્મક IDENT લૂકઅપ પરિણામ (ક્લાયન્ટ 'હોસ્ટ યજમાન' સાથે મેળ ખાય છે) ઓછી વિશ્વસનીય છે. એક ઘુસણખોર માટે ક્લાયન્ટ કનેક્શન અને IDENT લૂકઅપ બંનેને હરાવવા માટે શક્ય છે, જો કે આમ કરવાથી ફક્ત ક્લાઈન્ટ કનેક્શનને હરાવવા કરતાં વધુ મુશ્કેલ છે. તે પણ હોઈ શકે છે કે ક્લાયન્ટ IDENT સર્વર જૂઠું બોલે છે.
નોંધ: IDENT લૂકઅપ UDP સેવાઓ સાથે કામ કરતા નથી.
ઉદાહરણો
આ ભાષા એટલી સરળ છે કે વિવિધ પ્રકારનાં એક્સેસ કન્ટ્રોલ પોલિસીને ઓછામાં ઓછા ખોટી રીતે દર્શાવવામાં આવી શકે છે. તેમ છતાં ભાષા બે વપરાશ નિયંત્રણ કોષ્ટકોનો ઉપયોગ કરે છે, મોટાભાગની સામાન્ય નીતિઓ એક ચુસ્ત કે નજીવી અથવા ખાલી ખાલી જગ્યા સાથે લાગુ કરી શકાય છે.
નીચેના ઉદાહરણો વાંચતી વખતે એ સમજવું અગત્યનું છે કે પરવાનગી ટેબલને ટેબલ નામંજૂર પહેલાં સ્કેન કરવામાં આવે છે, જ્યારે મેચ બંધ થાય ત્યારે શોધ બંધ થઈ જાય છે, અને જ્યારે કોઈ મેળ ખાતું નથી ત્યારે તે ઍક્સેસ આપવામાં આવે છે.
ઉદાહરણો હોસ્ટ અને ડોમેન નામોનો ઉપયોગ કરે છે. કામચલાઉ નામ સર્વર લુકઅપ નિષ્ફળતાઓની અસરને ઘટાડવા માટે તેઓ સરનામાં અને / અથવા નેટવર્ક / નેટમાસ્ક માહિતીનો સમાવેશ કરીને સુધારી શકાય છે.
મોટે ભાગે બંધ
આ કિસ્સામાં, ઍક્સેસ ડિફોલ્ટથી નકારવામાં આવે છે. ફક્ત સ્પષ્ટપણે અધિકૃત યજમાનોની પરવાનગી છે.
ડિફોલ્ટ પોલિસી (કોઈ એક્સેસ) એક નજીવી નામંજૂર ફાઇલ સાથે લાગુ કરવામાં આવે છે:
/etc/hosts.deny: ALL: ALL
આ બધી યજમાનોની બધી સેવાને નકારે છે, સિવાય કે તે પરવાનગી ફાઈલમાં એન્ટ્રીઓ દ્વારા પરવાનગીની પરવાનગી આપે.
સ્પષ્ટ રીતે અધિકૃત યજમાનો પરવાનગી ફાઇલમાં સૂચિબદ્ધ છે. દાખ્લા તરીકે:
/etc/hosts.allow: ALL: LOCAL @some_netgroup
ALL: .foobar.edu Terminalserver.foobar.edu દૂર કરો
પ્રથમ નિયમ લોકલ ડોમેન (યજમાનના નામમાં કોઈ '.') અને some_netgroup નેટ જૂથના સભ્યોમાંથી યજમાનોની ઍક્સેસને પરવાનગી આપે છે. બીજા નિયમ foobar.edu ડોમેન (અગ્રણી ડોટ નોટિસ) ટર્મિનલરવર.ફોબરો.ઈડુના અપવાદ સાથે તમામ યજમાનોથી પ્રવેશની પરવાનગી આપે છે.
મોટે ભાગે ખુલે છે
અહીં, ઍક્સેસ ડિફૉલ્ટ રૂપે આપવામાં આવે છે; ફક્ત સ્પષ્ટપણે ઉલ્લેખિત યજમાનોને સેવા નકારવામાં આવે છે.
ડિફૉલ્ટ નીતિ (મંજૂર કરેલી ઍક્સેસ) પરવાનગી ફાઇલને બિનજરૂરી બનાવે છે જેથી તેને અવગણી શકાય. સ્પષ્ટપણે બિન-અધિકૃત યજમાનો નામંજૂર ફાઇલમાં સૂચિબદ્ધ છે. દાખ્લા તરીકે:
/etc/hosts.deny: ALL: some.host.name, .some.domain
બધા અણઘડથી દૂર કરો. ફિંગરઃ અન્ય.host.name, .other.domain
પ્રથમ નિયમ કેટલાક યજમાનોને નકારે છે અને તમામ સેવાઓને ડોમેન્સ કરે છે; બીજો નિયમ હજુ પણ અન્ય યજમાનો અને ડોમેન્સની આંગળી અરજીઓને મંજૂરી આપે છે.
બૂબી ટ્રેપ્સ
આગળના ઉદાહરણ સ્થાનિક ડોમેનમાં હોસ્ટ્સ તરફથી tftp વિનંતીને મંજૂરી આપે છે (અગ્રણી ડોટ નોટિસ કરો). અન્ય કોઈપણ હોસ્ટ્સની વિનંતીઓ નકારવામાં આવે છે. વિનંતી કરેલી ફાઇલને બદલે, આંગળીની ચકાસણી વાંધાજનક હોસ્ટને મોકલવામાં આવે છે. પરિણામ સુપરુઝરને મોકલવામાં આવે છે.
/etc/hosts.allow:
in.tftpd: LOCAL, .my.domain /etc/hosts.deny: in.tftpd: ALL: spawn (/ some / where / safe_finger-l @% h | \ / usr / ucb / મેઈ -એસ% d-% એચ રુટ) &Safe_finger આદેશ tcpd wrapper સાથે આવે છે અને યોગ્ય સ્થાન પર સ્થાપિત થવું જોઈએ. તે રીમોટ આંગળી સર્વર દ્વારા મોકલવામાં આવેલા ડેટાથી સંભવિત નુકસાનને મર્યાદિત કરે છે. તે સ્ટાન્ડર્ડ આંગળી કમાન્ડ કરતાં વધુ રક્ષણ આપે છે.
% H (ક્લાયન્ટ હોસ્ટ) અને% d (સર્વિસ નામ) સિક્વન્સનું વિસ્તરણ શેલ આદેશોના વિભાગમાં વર્ણવવામાં આવ્યું છે.
ચેતવણી: તમારી આંગળીના ડિમનને નાબૂડો નહીં, જ્યાં સુધી તમે અનંત આંગળી આંટીઓ માટે તૈયાર નથી.
નેટવર્ક ફાયરવૉલ સિસ્ટમ્સ પર આ યુક્તિ પણ આગળ ધપાવી શકાય છે. વિશિષ્ટ નેટવર્ક ફાયરવૉલ માત્ર બાહ્ય વિશ્વની સેવાઓનો મર્યાદિત સેટ પ્રદાન કરે છે. ઉપરની tftp ઉદાહરણની જેમ અન્ય બધી સેવાઓ "બગડી" થઈ શકે છે તેનું પરિણામ એક ઉત્તમ પ્રારંભિક-ચેતવણી સિસ્ટમ છે.
આ પણ જુઓ
tcpd (8) tcp / ip ડિમન રેપર પ્રોગ્રામ. tcpdchk (8), tcpdmatch (8), પરીક્ષણ કાર્યક્રમોમહત્વનું: તમારા ચોક્કસ કમ્પ્યૂટર પર આદેશ કેવી રીતે વાપરવામાં આવે છે તે જોવા માટે man આદેશ ( % man ) નો ઉપયોગ કરો.