fail2ban में कुछ भी अपने आप पैकेट नहीं गिराता: वह एक क्रिया बुलाता है, और वही क्रिया प्रोटोकॉल और पोर्ट का नाम देती है। जब jail बैन की रिपोर्ट करता है और डेमन लॉगिन स्वीकार करता रहता है, तब बैन आमतौर पर वास्तविक होता है और लॉग से जो लगता है उससे सँकरा। दूसरे ट्रांसपोर्ट पर फिर से जुड़ने वाला क्लाइंट कभी उस नियम से नहीं टकराता जो स्थापित हुआ था। कुछ भी बदलने से पहले तुलना करें कि क्रिया ने क्या स्थापित किया और डेमन किस पर सुनता है, क्योंकि सबूत उसी फ़ायरवॉल चेन में है जो क्रिया ने लिखी, jail की सूची में नहीं।

चेन पढ़ें, jail का सारांश नहीं

fail2ban अपनी चेन सेवा की चेन से पहले डालता है, इसलिए काउंटर सूची ठीक-ठीक दिखाती है कि क्या मौजूद है। jail के नाम पर बनी चेन, जिसमें एक नियम है और उसका प्रोटोकॉल कॉलम udp पढ़ता है, आते रहने वाले TCP लॉगिन के लिए पूरी व्याख्या है। केवल प्रतिबंधित स्रोत के UDP पैकेट अस्वीकार होते हैं। सेवा के पास TCP श्रोता है, और उस चेन में कुछ भी उसे छूता नहीं।

पड़ोसी jail का असर भी देखें। एक होस्ट पूरी तरह कॉन्फ़िगर दिख सकता है सिर्फ़ इसलिए कि कोई दूसरा jail छूटा हुआ आधा हिस्सा देता है, और वही बिल्ड वहाँ कुछ नहीं करता जहाँ वह jail स्थापित नहीं है।

क्रिया एक ही प्रोटोकॉल का नाम देती है, और वहीं यह टूटती है

हर banaction फ़ायरवॉल कमांड का टेम्पलेट है, और प्रोटोकॉल उसके एक प्लेसहोल्डर में बैठता है। यह सँकरापन जानबूझकर है, क्योंकि वेब jail और DNS jail का एक जैसे पोर्ट रोकने से कोई लेना-देना नहीं। यह जाल तब बनता है जब सेवा एक से अधिक ट्रांसपोर्ट पर सुनती है, जो VPN डेमन नियमित रूप से करते हैं। फ़िल्टर दोनों ट्रांसपोर्ट की असफल लॉगिन देख सकता है जबकि क्रिया एक को ढकती है।

SoftEther और OpenVPN की तैनातियाँ आमतौर पर एक साथ UDP और TCP पर सुनती हैं, और चूँकि लॉग पंक्ति दोनों स्थितियों में एक जैसी दिखती है, फ़िल्टर दोनों को देखता है। यह असमानता jail की अपनी रिपोर्ट में कभी नहीं दिखती। fail2ban ने असफलताएँ सही गिनीं और फिर ऐसा नियम स्थापित किया जो उस आधे ट्रैफ़िक पर लागू होता है जिस पर वे असफलताएँ आई थीं।

बैन को दोनों ट्रांसपोर्ट ढकने दें

इसे jail की परिभाषा में ही ठीक करें; हाथ से लिखे नियम अगली रीलोड में उलट-पुलट हो जाएँगे। हर प्रोटोकॉल के लिए एक, दो क्रियाएँ स्पष्ट लिखें:

action = %(banaction)s[name=%(__name__)s-tcp, actionname=%(__name__)s-tcp, protocol="tcp", port="%(port)s", chain="%(chain)s"]
         %(banaction)s[name=%(__name__)s-udp, actionname=%(__name__)s-udp, protocol="udp", port="%(port)s", chain="%(chain)s"]

इसे protocol = all से छोटा करने की कोशिश न करें। डिफ़ॉल्ट banaction एक multiport क्रिया है, और वह -p <protocol> -m multiport --dports <port> तक फैलती है; L4 प्रोटोकॉल के बिना पोर्ट मिलान के पास जाँचने को कुछ नहीं, इसलिए iptables नियम अस्वीकार करता है जबकि jail अब भी सफल बैन की रिपोर्ट करता है। iptables-allports या nftables-allports जैसी सर्व-पोर्ट क्रिया एक प्रविष्टि स्वीकार करती है, पर वह उस स्रोत के हर पोर्ट को रोक देती है, जो अलग निर्णय है और अपना औचित्य माँगता है। protocol को tcp या udp पर रखें और दोनों प्रविष्टियाँ स्वीकार करें।

सेटिंग पर भरोसा करने के बजाय साबित करें कि नियम मौजूद है, क्योंकि सेटिंग तब तक इरादा बताती है जब तक कोई चेन उसे थामे न रखे:

iptables -S f2b-vpn-tcp
iptables -S f2b-vpn-udp

हर चेन को एक नियम सूचीबद्ध करना चाहिए, पहली में -p tcp और दूसरी में -p udp, दोनों प्रतिबंधित पता बताएँ। फिर पुष्टि करें कि वही पता दोनों ट्रांसपोर्ट पर अस्वीकार होता है। चेन में न देखा गया बैन एक उम्मीद है, और उसी लक्षण की अगली रिपोर्ट फिर वही घंटा खर्च कराएगी।

बैन अब भी क्या चूकता है, और अगला मामला

क्रिया एक ही स्रोत को अस्वीकार करती है, और केवल उन्हीं पोर्ट पर जो उसमें सूचीबद्ध हैं। पते बदलने वाले हमलावर के खिलाफ़ यह कुछ नहीं करती, और यह शत्रुतापूर्ण मशीन को उस carrier-grade NAT निकास से अलग नहीं कर सकती जिसे सैकड़ों उपयोगकर्ता साझा करते हैं, जहाँ एक बैन उन लोगों को बाहर कर देता है जिन्होंने कुछ नहीं किया। सुनिश्चित करें कि फ़िल्टर वह पता पढ़ता है जो क्लाइंट के पास वास्तव में है, कोई अग्रेषित हेडर या प्रॉक्सी पता नहीं। विंडो इतनी छोटी रखें कि गलती अपने आप खत्म हो जाए।

इनमें से कुछ भी प्रोटोकॉल सुधार छोड़ने के पक्ष में नहीं है; यह एक साथ दो विचार रखने के पक्ष में है। बैन jail के सारांश के सुझाव से सँकरा है, और पूरा बैन भी खतरे से सँकरा है। फ़ायरवॉल चेन को डेमन की श्रोता सूची के पास रखें और प्रोटोकॉल-दर-प्रोटोकॉल तुलना करें, क्योंकि वही दो सूचियाँ तय करती हैं कि बैन सेवा तक पहुँच भी सकता है या नहीं।

रीलोड कमांड और चेन सूची jail के पास रनबुक में रखें। अगले व्यक्ति को दोनों चाहिए होंगे, और jail का सारांश उसे एक भी नहीं बताएगा।

संबंधित लेख