NAME
hosts_access - होस्टल पहुँच नियन्त्रण फाइलहरूको ढाँचा
वर्णन
यो म्यानुअल पृष्ठले क्लाइन्ट (होस्ट नाम / ठेगाना, प्रयोगकर्ता नाम), र सर्भर (प्रक्रियाको नाम, होस्ट नाम / ठेगाना) ढाँचामा आधारित साधारण पहुँच नियन्त्रण भाषा वर्णन गर्दछ। अन्तमा उदाहरणहरू दिइएका छन्। अस्थिर पाठकलाई प्रोत्साहन को लागि EXAMPLES खण्ड मा छोड्न को लागी प्रोत्साहित गरिएको छ .उपलब्ध नियंत्रण भाषा को विस्तारित संस्करण hosts_options (5) दस्तावेज मा वर्णन गरिएको छ। विस्तारहरू -DPROCESS_OPTIONS सँग निर्माण गरेर कार्यक्रम निर्माण समयमा सक्रिय छन्।
निम्न पाठमा, डेमन नेटवर्क सञ्जाल प्रक्रियाको प्रक्रिया नाम हो, र क्लाइन्ट नाम हो / वा होस्ट अनुरोध सेवाको ठेगाना हो। सञ्जाल डेमोन प्रक्रिया नामहरू इन्टिड विन्यास फाइलमा निर्दिष्ट गरिएको छ।
पहुँच नियन्त्रण फाइलहरू
पहुँच नियन्त्रण सफ्टवेयर दुई फाईलहरूको अनुगमन गर्दछ । खोज पहिलो म्याचमा रोकिएको छ।
पहुँच दिइनेछ जब एक (डेमोन, क्लाइन्ट) जोडीले /etc/hosts.allow फाईलमा प्रविष्टिहरूसँग मेल खान्छ।
अन्यथा, पहुँच अस्वीकार गरिनेछ जब (डेमोन, क्लाइन्ट) जोडाले /etc/hosts.deny फाइलमा प्रविष्टि प्रविष्टि गर्दछ।
अन्यथा, पहुँच प्रदान गरिनेछ।
एउटा अवस्थित अवस्थित नियन्त्रण फाइल मानिएको छ भने यो खाली फाइल हो। यस प्रकार, पहुँच नियन्त्रण फाइलहरू उपलब्ध गराएर पहुँच नियन्त्रण बन्द गर्न सकिन्छ।
पहुँच नियमहरू
प्रत्येक पहुँच नियन्त्रण फाइलमा शून्य वा पाठको थप रेखाहरू हुन्छन्। यी रेखाहरू उपस्थितिको क्रममा प्रशोधन गरिएका छन्। म्याच भेटिएपछि खोजी समाप्त हुन्छ।
एक backlinelash क्यारेक्टरबाट पहिले जब एक नयाँ रेखा वर्ण उपेक्षा गरिन्छ। यसले तपाईंलाई लामो लाइनहरू तोड्नको लागि अनुमति दिन्छ ताकि तिनीहरू सम्पादन गर्न सजिलो छ।
`# 'क्यारेक्टरसँग सुरु हुने खाली रेखाहरू वा रेखाहरू उपेक्षा गरिएका छन्। यसले तपाईंलाई टिप्पणी र व्हाइटस्पेस सम्मिलित गर्न अनुमति दिन्छ ताकि तालिका पढ्न सजिलो छ।
सबै अन्य लाइनहरू निम्न ढाँचालाई पूरा गर्नैपर्छ, चीजहरू [वैकल्पिक] बीचका कुराहरू:
daemon_list: client_list [: shell_command]
daemon_list एक वा धेरै डेमन प्रक्रिया नामहरू (argv [0] मानहरू) वा wildcards (तल हेर्नुहोस्) को सूची हो।
client_list एक वा बढी होस्ट नामहरू, होस्ट ठेगानाहरू, ढाँचाहरू वा जंगलीकार्डहरू (तल हेर्नुहोस्) को सूची हो जुन क्लाइन्ट होस्ट नाम वा ठेगानाको विरूद्ध मेल खानेछ।
अधिक जटिल फारमहरू डेमोन @ होस्ट र प्रयोगकर्ता @ होस्ट क्रमबद्ध रूपमा सर्भर अन्तबिन्दु ढाँचामा खण्डहरूमा व्याख्या गरिएका छन् र क्रमशः ग्राहक क्लाइन्ट प्रयोगकर्तानाम लुकअपहरूमा।
सूची तत्वहरू खाली र / वा अल्पविरामद्वारा अलग हुनुपर्छ।
एनआईएस (YP) नेटसमूह लुकअपहरूको अपवादको साथ, सबै पहुँच नियन्त्रण जाँचहरू असामान्य छन्।
PATTERNS
पहुँच नियन्त्रण भाषा निम्न ढाँचाहरू लागू गर्दछ:
एक string जुन `` सँग सुरु हुन्छ। क्यारेक्टर। यदि यस नामको अन्तिम घटकले निर्दिष्ट ढाँचासँग मेल खान्छ भने होस्ट नाम मेल खाएको छ। उदाहरणको लागि, ढाँचा `.tue.nl 'होस्ट नामसँग मेल खान्छ` wzv.win.tue.nl'।
String सँग `end 'सँग अन्त्य हुन्छ। क्यारेक्टर। एक होस्ट ठेगाना मिल्यो भने यसको पहिलो संख्यात्मक फिल्डले दिइएको स्ट्रिङसँग मेल खान्छ। उदाहरणका लागि, ढाँचा `131.155। ' ईन्डहोभ विश्वविद्यालय नेटवर्क (131.155.xx) मा हरेक होस्ट (लगभग) को ठेगाना सँग मेल खान्छ।
एक स्ट्राइक जुन `@ 'वर्णको साथ सुरु हुन्छ NIS (पूर्व YP) नेट समूह नामको रूपमा व्यवहार गरिन्छ। यदि होस्ट गरिएको निर्दिष्ट समूहको होस्ट सदस्य हो भने होस्ट नाम मेल खाएको छ। डेमोन प्रक्रिया नामहरू वा क्लाइन्ट प्रयोगकर्ता नामका लागि नेटसमूह म्याचहरू समर्थित छैनन्।
`Net / mask 'जोडाको रूपमा फारम` nnnn / mmmm' को अभिव्यक्तिको रूपमा व्याख्या गरिएको छ। यदि आईपीआई 4 होस्ट ठेगाना मिलिएको छ भने `नेट 'बिटदिवार र ठेगाना र` मुख' को बराबर हो। उदाहरणको लागि, प्रत्येक ठेगानासँग नेट / मास्क ढाँचा `131.155.72.0/255.255.254.0 'दायरामा छ` 131.155.72.0' मार्फत `131.155.73.255 '।
फारम `` n: n: n: n: n: n: n] / m 'को एक अभिव्यक्ति `[net] / prefixlen' जोडाको रूपमा व्याख्या गरिएको छ। यदि 'net' को 'prefixlen' बिटहरू ठेगानाको 'उपसर्गन' बिटको बराबर हो भने IPv6 होस्ट ठेगाना मेल खाएको छ। उदाहरणका लागि, [नेट] / prefixlen ढाँचा `[3ffe: 505: 2: 1 ::] / 64 'दायरामा प्रत्येक ठेगानासँग मेल खान्छ` 3ffe: 505: 2: 1 ::' through `3ffe: 505: 2: 1: ffff: ffff: ffff: ffff '।
एउटा `string 'सँग सुरु हुने स्ट्रिङ फाइल नामको रूपमा व्यवहार गरिन्छ। यदि होस्ट गरिएको नाममा सूचीबद्ध होस्ट नाम वा ठेगाना ढाँचासँग मिल्दो हो भने होस्ट नाम वा ठेगाना मिल्दो छ। फाईल ढाँचा शून्य वा बढी रेखाहरू शून्य वा धेरै होस्ट नाम वा व्हाइटस्पेसद्वारा विभाजित ठेगाना ढाँचासँग छ। फाइल नाम ढाँचा प्रयोग गर्न सकिन्छ जहाँ पनि होस्ट नाम वा ठेगाना ढाँचा प्रयोग गर्न सकिन्छ।
वाइल्डकार्ड्स `* 'र`?' होस्टनामहरू वा आईपी ठेगानाहरू मेल गर्न प्रयोग गर्न सकिन्छ। मिल्दोको यो विधि `net / mask 'सँग मिल्दो संयोजनमा प्रयोग गर्न सकिदैन, होस्टनामसँग` सुरू' सँग मिल्दो हो। वा आईपी ठेगाना मिलान संग समाप्त '।'।
WILDCARDS
पहुँच नियन्त्रण भाषा स्पष्ट wildcards को समर्थन गर्दछ:
सबै
विश्वव्यापी वाइल्डकार्ड, सधैँ मेल खान्छ।
स्थानिय
कुनै होस्टसँग मेल खान्छ जसको नामले डट क्यारेक्टर समावेश गर्दैन।
UNKNOWN
कुनै प्रयोगकर्ता जसको नाम अज्ञात छ मेल खाउँछ, र कुनै होस्टसँग मेल खाएको जसको नाम वा ठेगाना अज्ञात छ। यो पद्धति हेरविचारको साथ प्रयोग गर्नु पर्दछ: अस्थायी नाम सर्भर समस्याहरूको कारण होस्ट नामहरू अनुपलब्ध हुन सक्छन्। सञ्जाल ठेगाना उपलब्ध हुनेछ जब सफ्टवेयरले कुन प्रकारको सञ्जालसँग कुरा गरिरहेको कुरा पत्ता लगाउन सक्दैन।
KNOWN
कुनै प्रयोगकर्ताको नाम जसको नाम चिनिन्छ, र कुनै पनि होस्टसँग मेल खान्छ जसको नाम र ठेगाना थाहा छ। यो पद्धति हेरविचारको साथ प्रयोग गर्नु पर्दछ: अस्थायी नाम सर्भर समस्याहरूको कारण होस्ट नामहरू अनुपलब्ध हुन सक्छन्। सञ्जाल ठेगाना उपलब्ध हुनेछ जब सफ्टवेयरले कुन प्रकारको सञ्जालसँग कुरा गरिरहेको कुरा पत्ता लगाउन सक्दैन।
PARANOID
कुनै पनि होस्टसँग मेल खान्छ जसको नाम यसको ठेगाना मेल खाँदैन। जब tcpd -DPARANOID (डिफल्ट मोड) सँग बनाइएको हो, यसले ग्राहकहरूलाई अनुरोधहरू नियन्त्रण नियन्त्रण तालिकाहरू हेर्नु अघि पनि ड्रप गर्दछ। बिना -DPARANOID बनाउनुहोस् जब तपाइँ यस्तो अनुरोधहरूमा अधिक नियन्त्रण चाहानुहुन्छ।
OPERATORS
EXCEPT
आश्रित प्रयोग फारमको हो: `list_1 EXCEPT list_2 '; यो निर्माणले जो कोहीसँग मेल खान्छ जुन सूची सूचीसँग मेल खान्छ जब सम्म यो सूची_2 सँग मेल खान्छ । EXCEPT परिचालक daemon_lists र client_lists मा प्रयोग गर्न सकिन्छ। EXCEPT अपरेटरलाई नेस्ट गर्न सकिन्छ: यदि नियन्त्रण भाषाले प्यारेकहरू प्रयोगको लागि अनुमति दिन्छ, `एक एक्सेप्ट बी एक्ससीएससी सी 'को रूपमा` (एक एक्सेप्ट (बी एक्सेप्ट सी))' पार्स गर्नेछ।
यदि पहिलो मिलान गरिएको पहुँच नियंत्रण नियममा शेल आदेश समावेश छ भने, यो आदेश% substitutions को अधीन हुन्छ (अर्को भाग हेर्नुहोस्)। परिणाम एक इनपुट / बिन / बाल बाल प्रक्रिया द्वारा मानक इनपुट, आउटपुट र त्रुटि / dev / null सँग जोडिएको छ। आदेशको अन्त्यमा `& 'निर्दिष्ट गर्नुहोस् यदि तपाईं पूरा नभएसम्म रुवाउन चाहानुहुन्छ।
शेल आदेशहरू पूर्वनिर्धारित PATH सेटिङमा निर्भर हुँदैन। यसको सट्टामा, उनीहरूले पूर्ण पथ नामहरू प्रयोग गर्नुपर्छ, वा तिनीहरू स्पष्ट PATH = सबै कथनको साथ सुरू गर्नु पर्छ।
Hosts_options (5) कागजातले फरक भाषा र असंगत तरिकामा शेल आदेश फिल्ड प्रयोग गर्दछ वैकल्पिक भाषाको वर्णन गर्दछ।
% EXPANSIONS
निम्न विस्तारहरू शेल आदेशहरू भित्र उपलब्ध छन्:
% a (% A)
ग्राहक (सर्भर) होस्ट ठेगाना।
% c
ग्राहक जानकारी: उपयोगकर्ता @ होस्ट, प्रयोगकर्ता @ ठेगाना, एक होस्ट नाम, वा केवल एक ठेगाना, कति जानकारी उपलब्ध छ भन्ने आधारमा।
% d
डेमन प्रक्रिया नाम (argv [0] मूल्य)।
% h (% एच)
ग्राहक (सर्भर) होस्ट नाम वा ठेगाना, होस्ट नाम उपलब्ध छैन भने।
% n (% N)
ग्राहक (सर्भर) होस्ट नाम (वा "अज्ञात" वा "paranoid")।
% p
डेमन प्रक्रिया आईडी।
% s
सर्भर जानकारी: डेमन @ होस्ट, डेमोन @ ठेगाना, वा केवल डेमोन नाम, कत्तिको जानकारी उपलब्ध छ भन्ने आधारमा।
% u
ग्राहक प्रयोगकर्ता नाम (वा "अज्ञात")।
%%
एकल `% 'क्यारेक्टरमा विस्तार गर्दछ।
% खण्डहरूमा क्यारेक्टरहरू जुन शेललाई उलङ्ग गर्न सकिने अन्डरसेर्सहरू द्वारा बदलिएका छन्।
SERVER ENDPOINT PATTERNS
आदेश मा नेटवर्क ठेगाना को द्वारा ग्राहकहरु को अलग गर्न को लागी उनि कनेक्ट गर्न को रूप मा, पैटर्न को पैटर्न को उपयोग गर्नुहोस:
process_name @ host_pattern: client_list ...
यी जस्तै ढाँचाहरू प्रयोग गर्न सकिन्छ जब मञ्चसँग फरक इन्टरनेट ठेगानाहरू फरक इन्टरनेट होस्टनामहरू छन्। सेवा प्रदायकहरूले यो सुविधा प्रयोग गर्न को लागी एफटीपी, GOPHER वा WWW संग्रहण गर्न इन्टरनेट नामहरूसँग पनि हुन सक्छ जुन विभिन्न संस्थाहरूको हुन सक्छ। Hosts_options (5) कागजातमा `मोडिङ 'विकल्प पनि हेर्नुहोस्। केहि प्रणालीहरू (सोलिसिस, फ्रीबीएसडी) एक भौतिक इन्टरनेटमा एक भन्दा बढी इन्टरनेट ठेगाना हुन सक्छ; अन्य प्रणालीहरूको साथमा तपाईंलाई SLIP वा पीपीपी छद्म इन्टरफेसहरूमा समर्पित हुन सक्छ जुन समर्पित सञ्जाल ठेगाना अन्तरिक्षमा रहन्छ।
Host_pattern ले क्लाइन्ट_सूची सन्दर्भमा होस्ट नाम र ठेगानाको रूपमा समान वाक्यका नियमहरू पालन गर्दछ। सामान्यतया, सर्भर अन्त्यबिन्दु जानकारी केवल जडान-आधारित सेवाहरु संग उपलब्ध छ।
क्लाइन्ट USERNAME LOOKUP
जब क्लाइन्टले RFC 931 प्रोटोकल वा यसको सन्तान मध्ये एक (TAP, IDENT, RFC 1413) लाई समर्थन गर्दछ, भर्याङ प्रोग्रामहरूले जडानको मालिकको बारेमा थप जानकारी पुन: प्राप्त गर्न सक्दछ। क्लाइन्ट प्रयोगकर्तानाम जानकारी, उपलब्ध हुँदा, क्लाइन्ट होस्ट नामको साथमा लग इन गरिएको छ, र जस्तै ढाँचाहरू मेल गर्न प्रयोग गर्न सकिन्छ:
daemon_list: ... user_pattern @ host_pattern ...
डेमन wrappers कन्फिगरेसनमा नियन्त्रित समयमा नियम-संचालित प्रयोगकर्ता नामको लुकअप (डिफल्ट) प्रदर्शन गर्न सकिन्छ वा सँधै क्लाइन्ट होस्ट अन्वेषण गर्न। नियम-संचालित उपयोगकर्ता नामको लुकअपको अवस्थामा, माथिको नियमले प्रयोगकर्ता नामको डाउपअप मात्र गर्दा डेमोन_सूची र होस्टल_प्टरर्न म्याच दुवै हुनेछ।
प्रयोगकर्ता पद्धतिसँग डेमोन प्रक्रिया ढाँचाको रूपमा समान सिन्टैक्स छ, त्यसैले एउटै वाइल्डकार्डहरू लागू हुन्छन् (नेट समूह सदस्यता समर्थित छैन)। एक प्रयोगकर्ता नामको लुक अपका साथ लिईयो।
क्लाइन्ट प्रयोगकर्तानाम जानकारी विश्वसनीय हुन सक्दैन किनकि यो भन्दा आवश्यक छ, यदी जब क्लाइन्ट प्रणाली सम्झौता गरिएको छ। सामान्यमा, सबै र (संयुक्त राष्ट्र) ज्ञात मात्र प्रयोगकर्ता नामको ढाँचा हुन् जुन अर्थपूर्ण बनाउँछ।
प्रयोगकर्तानाम लुकअप केवल TCP- आधारित सेवाहरूसँग सम्भव छन्, र मात्र जब ग्राहक होस्टले उपयुक्त डेमोन चलाउँदछ; सबै अन्य अवस्थाहरूमा परिणाम "अज्ञात" हो।
एक ज्ञात युनिक्स कर्नेल बग सेवाको हानि हुन सक्छ जब प्रयोगकर्ता नाम लुकअप फायरवालद्वारा ब्लक गरिएको छ। रैप README कागजातले तपाईंको कर्नेल यो बगसँग पत्ता लगाउने प्रक्रियाको वर्णन गर्दछ।
प्रयोगकर्तानाम लुकअपले गैर-यूनिक्स प्रयोगकर्ताहरूको लागि उल्लेखनीय ढिलाइ हुन सक्छ। प्रयोगकर्तानाम समयको लागि खोजी समय 10 सेकेन्ड हो: ढिलो सञ्जालसँग सामना गर्न निकै छोटो छ, तर पीसी प्रयोगकर्ताहरू जोगाउन लामो समयसम्म।
चयनक्षेत्र प्रयोगकर्ता नाम लुकअपले अन्तिम समस्या घटाउन सक्छ। उदाहरणको लागि, एउटा नियम जस्तै:
डेमन_सूची: @pcnetgroup सबै @ सबै
पीसी नेटसमूहको सदस्यसँग मिलेर प्रयोगकर्ता नाम लुकअप नगरी, तर प्रयोगकर्ता नाम लगाउने सबै अन्य प्रणालीहरूसँग प्रदर्शन गर्नेछ।
DETECTING ADDRESS SPOOFING ATTACKS
धेरै TCP / IP कार्यान्वयनहरूको क्रम अनुक्रम नम्बर जेनरेटरमा एक दोषले इन्टर्रुडरहरूलाई सजिलैसँग विश्वसनीय होस्टहरूलाई प्रतिरूपण गर्न र माध्यमबाट तोड्न अनुमति दिन्छ, उदाहरणको लागि, रिमोट शेल सेवा। IDENT (RFC931 आदि) सेवा यस्तो र अन्य होस्ट ठेगाना स्पुफिंग आक्रमणहरू पत्ता लगाउन प्रयोग गर्न सकिन्छ।
ग्राहक अनुरोध स्वीकार गर्नु अघि, स्क्रैपर्सले IDENT सेवा प्रयोग गर्न खोज्न सक्दछ कि क्लाइन्टले अनुरोध अनुरोध पठाउन सकेन। जब ग्राहक होस्टले IDENT सेवा प्रदान गर्दछ, एक नकारात्मक IDENT लुकअप परिणाम (ग्राहक `UNKNOWN @ होस्ट 'सँग मेल खान्छ) होस्ट स्पाउफिंग आक्रमणको बलियो प्रमाण हो।
एक सकारात्मक IDENT लुकअप परिणाम (क्लाइन्ट `KNOWN @ होस्ट 'सँग मेल खान्छ) कम विश्वसनीय छ। एक घुसपैठको लागि यो सम्भव छ क्लाइन्ट जडान र IDENT लुकअप दुवै छानबिन गर्न, हुनत यो गर्दा ग्राहक ग्राहक जडान spoofing भन्दा धेरै कठिन छ। यो पनि हुन सक्छ कि ग्राहकको IDENT सर्भर झूटो छ।
नोट: IDENT लुकअप UDP सेवाहरूसँग काम गर्दैन।
उदाहरणहरू
भाषा एकदम लचीला छ कि विभिन्न प्रकारको पहुँच नियन्त्रण नीति न्यूनतम उपद्रवको साथ व्यक्त गर्न सकिन्छ। यद्यपि भाषाले दुई पहुँच नियन्त्रक तालिकाहरू प्रयोग गर्दछ, सबै भन्दा सामान्य नीतिहरू एक तालिकाहरू तुरुन्त वा खाली हुनका साथ लागू गर्न सकिन्छ।
तल उदाहरणहरू पढ्दा यो महत्त्वपूर्ण छ कि अनुमति तालिका अस्वीकार गर्नु भन्दा पहिले स्क्यान गरिएको स्क्यान गरिएको छ, जुन खोजी भेटिएको बेला बन्द हुन्छ, र पहुँचलाई दिइएको छ जब कुनै मिल्दो सबै फेला परेन।
उदाहरण होस्ट र डोमेन नामहरू प्रयोग गर्दछ। तिनीहरू अस्थायी नाम सर्भर लुकअप विफलताको प्रभाव कम गर्न ठेगाना र / वा सञ्जाल / नेटमास्क जानकारी सहित सुधार गर्न सकिन्छ।
प्रायः बन्द भयो
यस अवस्थामा, पूर्वनिर्धारित रूपमा पहुँच अस्वीकार गरिएको छ। केवल स्पष्ट रूपमा अधिकृत होस्टहरूलाई अनुमति दिइएको छ।
पूर्वनिर्धारित अस्वीकार फाइलको साथ पूर्वनिर्धारित नीति (पहुँच छैन):
/etc/hosts.deny: ALL: ALL
यसले सबै होस्टहरूमा सबै सेवा अस्वीकार गर्दछ, जबसम्म उनीहरूलाई अनुमति फाइलमा प्रविष्टिहरू द्वारा अनुमति दिइएको छैन।
स्पष्ट रूपमा अधिकृत होस्टहरूलाई अनुमति फाइलमा सूचीबद्ध गरिएको छ। उदाहरणका लागि:
/etc/hosts.allow: सबै: स्थानीय @some_netgroup
सबै: .foobar.edu एक्स्प्रेस terminalserver.foobar.edu
पहिलो नियमले स्थानीय डोमेनमा होस्टहरूबाट पहुँच अनुमति दिन्छ (होईन। 'होस्ट नाममा) र some_netgroup netgroup को सदस्यहरूबाट। दोस्रो नियम foobar.edu डोमेनमा सबै होस्टहरूको पहुँच (अनुमति दिईएको डट कम), terminalserver.foobar.edu अपवादको साथ।
सबभन्दा खुल्ला छ
यहाँ, पहुँच पूर्वनिर्धारित द्वारा प्रदान गरिएको छ; केवल स्पष्ट रूपमा निर्दिष्ट होस्टहरू सेवा अस्वीकार गरीन्छन्।
पूर्वनिर्धारित नीति (पहुँच दिइयो) ले अनुमति फाइललाई अनावश्यक बनाउँछ ताकि यसलाई हटाउन सकिन्छ। स्पष्ट रूपमा गैर-अधिकृत होस्टहरू अस्वीकार फाइलमा सूचीबद्ध छन्। उदाहरणका लागि:
/etc/hosts.deny: ALL: some.host.name, .some.domain
सबै एक्स्प्रेस मा.fingerd: other.host.name, .other.domain
पहिलो नियमले केही होस्टहरू र डोमेनहरू सबै सेवाहरू अस्वीकार गर्दछ; दोस्रो नियम अझै अझै अन्य होस्ट र डोमेनबाट औँला अनुरोधहरूको अनुमति दिन्छ।
BOOBY TRAPS
अर्को उदाहरणले स्थानीय डोमेनमा होस्टहरूको टिफ्टप अनुरोधहरूको अनुमति दिन्छ (प्रमुख डट नोटिस)। कुनै अन्य होस्टहरूको अनुरोधहरू अस्वीकार गरिएका छन्। अनुरोध गरिएको फाइलको सट्टा, एक औँला जांच अपरेन्टिभ होस्टमा पठाइएको छ। परिणाम सुपरसर्भरमा पठाइएको छ।
/etc/hosts.allow:
in.tftpd: LOCAL, .my.domain /etc/hosts.deny: in.tftpd: ALL: spawn (/ some / where / safe_finger-l @% h | usr / ucb / mail -s% d-% h root)सुरक्षित_फिंगर आदेश Tcpd आवरणको साथ आउँछ र उपयुक्त स्थानमा स्थापित हुनुपर्छ। रिमोट औंला सर्भरद्वारा पठाएको डाटाबाट सम्भावित क्षतिलाई सीमित गर्दछ। यसले मानक औंला आदेश भन्दा राम्रो सुरक्षा दिन्छ।
% H (क्लाइन्ट होस्ट) र% d (सेवा नाम) अनुक्रमको विस्तार शेल आदेशहरूमा खण्डमा वर्णन गरिएको छ।
चेतावनी: ब्वाइबी-जाँच्न तपाईँको औंला डेमोन नगर्नुहोस्, जब सम्म तपाईं अनन्त उंगली लुपुको लागि तैयार हुनुहुन्न।
सञ्जाल फायरवाल प्रणालीहरूमा यो चाल अझ बढ्न सक्छ। सामान्य सञ्जाल फायरवालले मात्र बाह्य संसारमा सीमित सेवा प्रदान गर्दछ। सबै अन्य सेवाहरू केवल माथिको टिफ्टप उदाहरण जस्तै "बगैचा" हुन सक्छ। परिणाम एक उत्कृष्ट प्रारम्भिक चेतावनी प्रणाली हो।
पनि हेर्नुहोस्
tcpd (8) tcp / ip daemon wrapper program। tcpdchk (8), tcpdmatch (8), परीक्षण प्रोग्रामहरू।महत्वपूर्ण: तपाईको विशेष कम्प्युटरमा आदेश कसरी प्रयोग गरिन्छ भनेर हेर्नको लागि मानिसको आदेश ( % मानिस ) प्रयोग गर्नुहोस्।