स्थानीय नैटेड एफ़टीपी सर्वर को उपलब्ध कराने के लिए एनएफटी विन्यास
सब कुछ एक अलग नेटवर्क पर होगा, सुरक्षा कोई मुद्दा नहीं है।
eth0 "पब्लिक" नेटवर्क से जुड़ा है। पता डीएचसीपी द्वारा सौंपा गया।
eth1 एक "निजी नेटवर्क" सर्वर से जुड़ा है जो ssh, telnet, "others" और ftp प्रदान करता है।
इस उदाहरण में इस सर्वर का एक निश्चित IP (192.168.1.2) होगा।
गेटवे डेबियन बस्टर और लिनक्स कर्नेल 4.19.94 पर चल रहा है
एनएटीटी का उपयोग एनएटी के साथ किया जाता है
यह मेरा "गेटवे" एनएफटी कॉन्फ़िगरेशन है।
table ip my_nat {
chain my_prerouting { type nat hook prerouting priority 0;
tcp dport { 2222 } dnat to :22 # 2222 backdoor for ssh to the gateway
tcp dport { 1-1023 } dnat to 192.168.1.2
}
chain my_postrouting {
type nat hook postrouting priority 100;
ip daddr 192.168.1.2 masquerade
}
}
एफ़टीपी काम करने के लिए मुझे क्या जोड़ना होगा
जवाब
टी एल; डॉ
# nft add ct helper ip my_nat ftp-incoming '{ type "ftp" protocol tcp; }'
# nft add chain ip my_nat my_helpers '{ type filter hook prerouting priority 10; }'
# nft add rule ip my_nat my_helpers iif eth0 ip daddr 192.168.1.2 tcp dport 21 ct helper set ftp-incoming
# modprobe nf_nat_ftp
नीचे अधिक विवरण के साथ ...
समस्याग्रस्त प्रोटोकॉल के लिए प्रोटोकॉल सहायक मॉड्यूल
एफ़टीपी एक पुराना प्रोटोकॉल है और बहुत फ़ायरवॉल-फ्रेंडली नहीं है: एफ़टीपी कमांड चैनल (21 / टीसीपी) पर कमांड अगले ट्रांसफर कमांड के लिए उपयोग करने के लिए एक पंचांग पोर्ट पर बातचीत करता है। इस वजह से एक स्टेटफुल फ़ायरवॉल को उन कमांड्स और रिप्लाई को अस्थायी रूप से प्री-पोर्ट करने की अनुमति देनी होती है, जो पर्याप्त पोर्ट का उपयोग करने की अनुमति देते हैं।
लिनक्स पर यह प्रोटोकॉल-विशिष्ट हेल्पर मॉड्यूल द्वारा प्रदान किया जाता है जो कॉनट्रैक के लिए प्लग इन हैं , नेट और स्टेटफुल फ़ायरवॉलिंग के लिए नेटफ़िल्टर सबसिस्टम ट्रैकिंग कनेक्शन। एफ़टीपी के साथ, जब अगले हस्तांतरण के लिए एक पोर्ट वार्ता (ज्यादातर पोर्ट, ईपीआरटी, पीएएसवी या ईपीएसवी) को एफ़टीपी कमांड पोर्ट पर देखा गया है, तो सहायक एक विशेष कॉनट्रैक टेबल ( कंवर्टर उम्मीद तालिका) में एक अल्पकालिक प्रविष्टि जोड़ता है। अगले संबंधित और अपेक्षित डेटा कनेक्शन की प्रतीक्षा करें।
मेरा जवाब का उपयोग करता है आधुनिक "सुरक्षित" में वर्णित के रूप से निपटने के बारे में इस ब्लॉग iptables सामान्योक्तियां के लिए और में nftables विकी और man nftमें से निपटने के लिए nftables से जो अलग है iptables ।
सहायक और nftables नियमों का सुरक्षित उपयोग
लिनक्स कर्नेल 4.7+ (ताकि 4.19 सहित) डिफ़ॉल्ट रूप से एक सुरक्षित दृष्टिकोण का उपयोग कर रहा है: (यहां एफ़टीपी) हेल्पर मॉड्यूल लोड होने से अब ऐसा नहीं होगा कि टीसीपी स्रोत या गंतव्य पोर्ट 21 वाले सभी पैकेटों को स्नूप करें, जब तक कि विशिष्ट nftables (या iptables) ) कथन यह बताता है कि (प्रतिबंधित) मामले में उसे क्या करना चाहिए। यह अनावश्यक सीपीयू उपयोग से बचा जाता है और किसी भी समय एफ़टीपी पोर्ट (एस) को बदलने के लिए कुछ नियमों (या सेटों) को बदलने से अनुमति देता है।
पहला भाग उन प्रवाह की घोषणा करना है जो स्नूपिंग को ट्रिगर कर सकते हैं। यह iptables की तुलना में अलग तरह से nftables में संभाला जाता है । यहां इसे एक स्टेटफुल ऑब्जेक्ट का उपयोग करने के लिए घोषित किया गया है , और इसे सक्रिय करने के लिए फ़िल्टर कॉनट्रैक के बाद किया जाना चाहिए (जबकि iptables को पहले किए गए कार्यों की आवश्यकता होती है)। बताता है:ct helperman nft
Iptables के विपरीत, कंवर्टर लुकअप पूरा होने के बाद, हेल्पर असाइनमेंट को पूरा करने की आवश्यकता होती है, उदाहरण के लिए डिफ़ॉल्ट 0 हुक प्राथमिकता।
nft add ct helper ip my_nat ftp-incoming '{ type "ftp" protocol tcp; }'
nft add chain ip my_nat my_helpers '{ type filter hook prerouting priority 10; }'
nft add rule ip my_nat my_helpers iif eth0 ip daddr 192.168.1.2 tcp dport 21 ct helper set ftp-incoming
मैंने उसी तालिका को चुना, लेकिन इसे किसी अन्य तालिका में बनाया जा सकता था, जब तक कि राज्यवार वस्तु घोषणा और नियम का उल्लेख उसी तालिका में नहीं होता।
कोई भी कम प्रतिबंधात्मक नियम चुन सकता है। इस नियम से अंतिम नियम को बदलने से विरासत मोड के समान प्रभाव होगा:
nft add rule ip my_nat my_helpers tcp dport 21 ct helper set ftp-incoming
केवल संदर्भ के लिए, विरासत मोड, जिसका उपयोग अब नहीं किया जाना चाहिए, ऊपर दिए गए नियमों की आवश्यकता नहीं है, लेकिन बस इस टॉगल (और संबंधित कर्नेल मॉड्यूल के मैनुअल लोडिंग):
sysctl -w net.netfilter.nf_conntrack_helper=1
सुनिश्चित करना nf_nat_ftpभरी हुई है
कर्नेल मॉड्यूल nf_conntrack_ftpस्वचालित रूप से लोड की गई निर्भरता के साथ लोड होता है ct helper ... type "ftp"। इसके लिए ऐसा नहीं है nf_nat_ftp, फिर भी यह आवश्यक है कि जब डेटा प्रवाह बंदरगाहों पर NAT किया जाए तो कमांड पोर्ट में पैकेट मैनबलिंग को भी सक्षम किया जाए।
उदाहरण के लिए nf_nat_ftpजब भी nf_conntrack_ftpलोड किया जाता है तो मॉड्यूल को खींचा जाता है, /etc/modprobe.d/local-nat-ftp.confइस सामग्री के साथ फाइल को जोड़ा जा सकता है:
install nf_conntrack_ftp /sbin/modprobe --ignore-install nf_conntrack_ftp; /sbin/modprobe --ignore-install nf_nat_ftp
या इसके बजाय, बस उदाहरण के लिए जोड़ें /etc/modules-load.d/local-nat-ftp.conf:
nf_nat_ftp
वैसे भी अभी यह सुनिश्चित करने के लिए किया जाना चाहिए कि यह लोड हो रहा है:
modprobe nf_nat_ftp
फ़ायरवॉल के बारे में
यहाँ फ़ायरवॉलिंग के लिए एक अतिरिक्त नोट है। कॉनट्रैक द्वारा संबंधित किसी भी नए प्रवाह को टैग करने की अनुमति देने के बजाय कुछ प्रतिबंधों के साथ फ़ायरवॉलिंग नियम भी हो सकते हैं ।
उदाहरण के लिए, यद्यपि FTP हेल्पर मॉड्यूल निष्क्रिय और सक्रिय मोड दोनों को संभालता है, अगर किसी कारण से कोई केवल निष्क्रिय मोड (क्लाइंट से सर्वर से डेटा कनेक्शन के साथ) और "सक्रिय" एफ़टीपी (सर्वर स्रोत पोर्ट से डेटा कनेक्शन) की अनुमति देना चाहता है ग्राहक) उदाहरण के लिए नियम के फ़ायरवॉल भाग में इन नियमों का उपयोग कर सकता है, सामान्य के बजाय ct state established,related accept:
ct state established accept
ct state related ct helper "ftp" iif eth0 oif eth1 tcp sport 1024-65535 accept
ct state related ct helper "ftp" drop
ct state related accept
एफ़टीपी से संबंधित अन्य प्रकार के संबंधित प्रवाह को स्वीकार नहीं किया जाता है (या इसे अलग से विभाजित किया जा सकता है)
सहायक द्वारा निपटने का उदाहरण
यहां (एक सिम्युलेटेड वातावरण में) अपेक्षा तालिका पर मापी गई घटनाओं की दो संकलित सूचियां हैं और ओपी के नियमों के साथ कनवर्टर तालिका + एक इंटरनेट क्लाइंट 203.0.113.101 के साथ उपरोक्त अतिरिक्त नियम रूटर के सार्वजनिक आईपी पते 192.0 के साथ निष्क्रिय मोड में एफटीपी कर रहे हैं। लॉग इन होने के बाद 2.2 और एक लिस्ट कमांड का उपयोग करना:
# conntrack -E expect
[NEW] 300 proto=6 src=203.0.113.101 dst=192.0.2.2 sport=0 dport=37157 mask-src=0.0.0.0 mask-dst=0.0.0.0 sport=0 dport=65535 master-src=203.0.113.101 master-dst=192.0.2.2 sport=50774 dport=21 class=0 helper=ftp
[DESTROY] 300 proto=6 src=203.0.113.101 dst=192.0.2.2 sport=0 dport=37157 mask-src=0.0.0.0 mask-dst=0.0.0.0 sport=0 dport=65535 master-src=203.0.113.101 master-dst=192.0.2.2 sport=50774 dport=21 class=0 helper=ftp
एक साथ:
# conntrack -E
[NEW] tcp 6 120 SYN_SENT src=203.0.113.101 dst=192.0.2.2 sport=50774 dport=21 [UNREPLIED] src=192.168.1.2 dst=192.168.1.1 sport=21 dport=50774 helper=ftp
[UPDATE] tcp 6 60 SYN_RECV src=203.0.113.101 dst=192.0.2.2 sport=50774 dport=21 src=192.168.1.2 dst=192.168.1.1 sport=21 dport=50774 helper=ftp
[UPDATE] tcp 6 432000 ESTABLISHED src=203.0.113.101 dst=192.0.2.2 sport=50774 dport=21 src=192.168.1.2 dst=192.168.1.1 sport=21 dport=50774 [ASSURED] helper=ftp
[NEW] tcp 6 120 SYN_SENT src=203.0.113.101 dst=192.0.2.2 sport=55835 dport=37157 [UNREPLIED] src=192.168.1.2 dst=192.168.1.1 sport=37157 dport=55835
[UPDATE] tcp 6 60 SYN_RECV src=203.0.113.101 dst=192.0.2.2 sport=55835 dport=37157 src=192.168.1.2 dst=192.168.1.1 sport=37157 dport=55835
[UPDATE] tcp 6 432000 ESTABLISHED src=203.0.113.101 dst=192.0.2.2 sport=55835 dport=37157 src=192.168.1.2 dst=192.168.1.1 sport=37157 dport=55835 [ASSURED]
[UPDATE] tcp 6 120 FIN_WAIT src=203.0.113.101 dst=192.0.2.2 sport=55835 dport=37157 src=192.168.1.2 dst=192.168.1.1 sport=37157 dport=55835 [ASSURED]
[UPDATE] tcp 6 30 LAST_ACK src=203.0.113.101 dst=192.0.2.2 sport=55835 dport=37157 src=192.168.1.2 dst=192.168.1.1 sport=37157 dport=55835 [ASSURED]
[UPDATE] tcp 6 120 TIME_WAIT src=203.0.113.101 dst=192.0.2.2 sport=55835 dport=37157 src=192.168.1.2 dst=192.168.1.1 sport=37157 dport=55835 [ASSURED]
उम्मीद की शुरुआत proto=6 src=203.0.113.101 dst=192.0.2.2 sport=0 dport=37157बताती है कि 203.0.113.101:* से 192.0.2.2.2:37157 तक का अगला टीसीपी कनेक्शन एफटीपी कनेक्शन के साथ (राज्य संबंधी ) जुड़ा होगा । प्रत्यक्ष रूप से दिखाई नहीं देता है, लेकिन चूंकि NAT FTP हेल्पर मॉड्यूल भी लोड किया गया है, PASV / EPSV कमांड के जवाब में सर्वर द्वारा भेजे गए वास्तविक डेटा को इंटरसेप्ट किया गया और अनुवादित किया गया, इसलिए क्लाइंट 192.168.2.2 के बजाय 192.0.2.2 से कनेक्ट होता है, जो होगा बेशक ग्राहक पर विफल रहे।
दूसरे प्रवाह (दूसरी नई लाइन) के बावजूद my_prerout में कोई स्पष्ट नियम नहीं था, यह राउटर के पीछे सर्वर के लिए सफलतापूर्वक DNATed था।
टिप्पणियाँ
अगर एफ़टीपी नियंत्रण बंदरगाह एन्क्रिप्टेड (
AUTH TLS...) है, तो सहायक मॉड्यूल बातचीत किए गए पोर्ट को अब और नहीं खींच सकता है और यह काम नहीं कर सकता है। एफ़टीपी सर्वर कॉन्फ़िगरेशन और फ़ायरवॉल / NAT राउटर दोनों पर बंदरगाहों की एक आरक्षित सीमा को कॉन्फ़िगर करने के लिए एक का सहारा लेना पड़ता है, और सर्वर को कॉन्फ़िगर करना होता है ताकि यह सही (सार्वजनिक) आईपी पते को भेज सके जब इसके बजाय बातचीत हो। और सक्रिय एफ़टीपी मोड का उपयोग नहीं किया जा सकता है यदि सर्वर में इंटरनेट का कोई मार्ग नहीं है (जैसा कि यहां मामला प्रतीत होता है)।नाइटपैकिंग: 10 की पूर्ववर्ती प्राथमिकता यह सुनिश्चित करती है कि गुठली <4.18 के लिए भी, NAT पहले से ही नए प्रवाह के लिए हुआ (ओपी ने हुक प्रीरिंग प्राथमिकता 0 को सामान्य -100 के बजाय चुना क्योंकि यह शायद ही कभी नेफ्टी में मायने रखता है), इसलिए इसका उपयोग
daddr 192.168.1.2संभव है। यदि प्राथमिकता 0 थी (या 0 से कम), तो यह संभव है (सत्यापित नहीं है) नियम पहले पैकेट को अभी भी एक सार्वजनिक आईपी गंतव्य पते के साथ अन -ैटेड दिखाई देगा, लेकिन उसी प्रवाह के निम्नलिखित पैकेटों को पकड़ लेगा, क्योंकि वे संभाले हुए हैं। सीधे प्राथमिकता -200 पर शंकु द्वारा । बेहतर रहने के लिए सुरक्षित और उपयोग से 10 वास्तव में इस कर्नेल 4.18 के बाद से प्रासंगिक नहीं है (देखें प्रतिबद्ध में संदर्भ इस लंबित पैच) जहां नेट प्राथमिकता कई नेट श्रृंखलाओं के बीच तुलना करने के लिए ही प्रासंगिक है (और nftables साथ iptables विरासत में नेट मिश्रण की अनुमति देता है)।
कुछ परीक्षण और त्रुटि के बाद मैं निम्नलिखित nftables.conf के साथ आया हूं। यह इरादा के अनुसार काम करता है और NAT का समर्थन करता है और दोनों दिशाओं में "सार्वजनिक" नेटवर्क पर मेरे सर्वर पर सभी पोर्ट को निर्यात करता है। पोर्ट 2222 को अभी भी गेटवे के लिए "बैकडोर" के रूप में उपयोग किया जाता है, अगर मुझे कभी भी इसे फिर से एक्सेस करने की आवश्यकता होती है तो इसका इस्तेमाल किया जाएगा :-)
table ip my_nat {
ct helper ftp-incoming {
type "ftp" protocol tcp
l3proto ip
}
chain my_prerouting {
type nat hook prerouting priority 0; policy accept;
iifname "eth0" tcp dport { 2222 } dnat to :ssh
iifname "eth0" tcp dport { 1-2221, 2223-65535 } dnat to 192.168.0.2
}
chain my_postrouting {
type nat hook postrouting priority 100; policy accept;
ip daddr 192.168.0.2 masquerade
oifname "eth0" masquerade
}
chain my_helpers {
type filter hook prerouting priority 10; policy accept;
iif "eth0" ip daddr 192.168.0.2 tcp dport ftp ct helper set "ftp-incoming"
}
}