क्लाउड सर्वर
Cloud Server फ़ायरवॉल और सुरक्षा प्रबंधन
Every KapsuleHost Server ships with a managed firewall that denies inbound traffic by default, plus brute-force protection, a web application firewall and automatic security patching, all controlled…
Cloud Server Firewall और Security Management
प्रत्येक KapsuleHost Server एक managed firewall के साथ आता है जो डिफ़ॉल्ट रूप से inbound traffic को deny करता है, साथ ही brute-force protection, एक web application firewall और automatic security patching भी आते हैं, जो सभी KPanel के एक पृष्ठ से नियंत्रित होते हैं।
डिफ़ॉल्ट सेटिंग्स इस तरह चुनी गई हैं कि एक नया सर्वर safe होता है इससे पहले कि आप कुछ भी करें। आप जो कुछ भी जोड़ते हैं वह आमतौर पर सिर्फ वे पोर्ट होते हैं जिन्हें आपके application को चाहिए। यह गाइड पूरे Server management पृष्ठ के बारे में बताती है, क्योंकि firewall इसका एक भाग है और अन्य भाग वह हैं जो आपको firewall की जरूरत ही नहीं पड़ने देते।
Management Page को खोलना
- KPanel में sign in करें।
- बाईं ओर sidebar में Cloud Servers पर क्लिक करें, फिर अपने सर्वर पर क्लिक करें।
- पृष्ठ के शीर्ष पर action buttons में Management पर क्लिक करें।
सीधा पता /cloud-servers/<server-id>/management है। यह पृष्ठ खुद को इस रूप में बताता है: "Firewall, OS patches, fail2ban, और ModSecurity। Changes SSH के माध्यम से कुछ सेकंड में apply होते हैं।"
यदि कोई banner "Live apply unavailable. Changes save होंगे next provisioning run को, लेकिन तुरंत effect नहीं होंगे" पढ़ता है, तो panel इस समय सर्वर तक नहीं पहुंच सकता। आपकी settings अभी भी सहेजी गई हैं, वे सिर्फ अभी तक apply नहीं हुई हैं। जांचें कि सर्वर चल रहा है और reachable है।
Default Firewall Policy
Firewall (UFW) भाग policy को एक line में बताता है: "Default-deny inbound. SSH (22) always open है। App-stack ports automatically open होते हैं। नीचे custom rules जोड़ें।"
व्यावहार में इसका मतलब है:
- Internet से कोई भी आपके सर्वर तक नहीं पहुंच सकता जब तक कि एक rule इसे allow न करे।
- Port 22 हमेशा open होता है, इसलिए firewall change कभी आपको machine से locked out नहीं कर सकता।
- Ports जो आपके app stack को चाहिए, जैसे कि web application के लिए 80 और 443, आपके लिए खोले जाते हैं।
- Outbound traffic सर्वर से restricted नहीं है।
कोई custom rules के बिना, भाग "No custom rules. Defaults: SSH + app-stack ports." दिखाता है। यह एक healthy state है, missing configuration नहीं।
Custom Rule जोड़ना
एक rule जोड़ें जब आप कुछ ऐसा चलाते हैं जो एक port पर है जिसे default policy cover नहीं करता: एक Node application 3000 पर, एक database जिसे आप 5432 पर directly reach करना चाहते हैं, एक game या media server एक UDP port पर।
- Firewall (UFW) section को खोलें।
- Port number को पहले field में type करें। मान्य values 1 से 65535 हैं।
- TCP या UDP चुनें।
- Allow या Deny चुनें।
- Add पर क्लिक करें।
Rule list में एक ALLOW या DENY badge के साथ दिखाई देता है और port और protocol के साथ, उदाहरण के लिए 3000/tcp। यह management connection के माध्यम से कुछ सेकंड में सर्वर को push किया जाता है।
एक rule को हटाने के लिए, इसकी row के अंत में X पर क्लिक करें। एक Allow rule को हटाने से वह port तुरंत फिर से बंद हो जाता है।
एक database port को पूरे internet के लिए expose करना सर्वर compromise होने के सबसे आम तरीकों में से एक है। 3306, 5432, 6379 या 27017 को allow करने से पहले, पूछें कि जो चीज़ connect कर रही है क्या वह server के अपने loopback interface या private network के माध्यम से database तक reach कर सकती है। यदि यह genuinely बाहर से reachable होना चाहिए, तो सुनिश्चित करें कि service ही strong authentication और encryption require करता है।
पहले rule जोड़ें, फिर service शुरू करें। एक service जो एक बंद port के पीछे आता है वह बिल्कुल उसी तरह टूटा हुआ दिखता है जैसे एक service जो fail हुई हो, और आप wrong layer को debug करने में लंबा समय बर्बाद कर सकते हैं।
App Stacks
App stack section platform को बताता है कि यह सर्वर किस तरह के application को चलाता है, इसलिए hardening preset को उसके लिए tune किया जा सकता है। Panel के माध्यम से एक application install करने से यह आपके लिए set हो जाता है।
recognized stacks WordPress, WooCommerce, Ghost, Nextcloud, GitLab, Mattermost, Generic web, और No app stack हैं। भाग खुद को इस रूप में बताता है: "Hardening preset आपके app के लिए tune है। Marketplace से एक app install करने से यह auto-set हो जाता है।"
Stack यह प्रभावित करता है कि कौन से ports automatically open होते हैं और अन्य protections कैसे tune होती हैं, सबसे ज्यादा दृश्य में fail2ban में।
fail2ban
fail2ban authentication attempts को देखता है और उन addresses को ban करता है जो keep failing करते हैं। यह डिफ़ॉल्ट रूप से on है और पृष्ठ इसे इस रूप में बताता है: "IPs को ban करता है जो SSH को brute-force करते हैं। WordPress sites के लिए, wp-login.php protection भी जोड़ता है।"
इसे on रखें। यह पृष्ठ पर सबसे cheap protection है, यह performance में कुछ खर्च नहीं करता, और यह password-guessing attempts की निरंतर पृष्ठभूमि शोर को कुछ नहीं बनाता। एक WordPress या WooCommerce stack पर यह login form को भी protect करता है, जो कि WordPress के खिलाफ अधिकांश attacks कहां पड़ता है।
ModSecurity, Web Application Firewall
ModSecurity HTTP requests को OWASP Core Rule Set के खिलाफ inspect करता है और उन्हें flag करता है जो attacks की तरह दिखते हैं। एक KapsuleHost सर्वर पर यह detection-only mode में शुरू होता है: "OWASP Core Rule Set DetectionOnly mode में डिफ़ॉल्ट रूप से। Suspicious traffic को log करता है blocking के बिना; अपने सर्वर में tune करने के बाद active mode में flip करें।"
Detection-only सही starting point है। Core Rule Set thorough है, और एक real application पर कुछ legitimate requests एक rule को match करेंगे। इसे detection-only में एक समय के लिए चलाएं, logs को पढ़ें, work out करें कि आपका खुद का traffic कौन से rules को trip करता है, और सिर्फ तब server के अंदर blocking के लिए switch करें।
पहले tuning के बिना blocking को turn on करना अपनी खुद की site को break कर सकता है। Rich text के साथ form submissions, file uploads, और unusual payloads के साथ API clients आमतौर पर casualties होते हैं। Switch करने से पहले अपने logs को check करें।
OS Auto-Patching
Security updates आपके लिए apply किए जाते हैं। भाग safety net को समझाता है: "Security updates automatically apply होते हैं। Snapshot-protected: प्रत्येक run से पहले एक server snapshot लिया जाता है, automatic rollback के साथ यदि सर्वर reboot के बाद unreachable हो जाता है।"
Toggle के नीचे दो settings बैठती हैं:
- Allow automatic reboot जब एक kernel update को इसकी जरूरत है (केवल नीचे quiet hours के दौरान)। Kernel updates केवल reboot के बाद effect लेते हैं। यदि आप इसे off छोड़ते हैं, तो kernel patches install होते हैं लेकिन active नहीं होते जब तक आप खुद reboot न करें।
- Quiet window (UTC), एक start और end hour। Reboots केवल इसके अंदर होते हैं। इसे आपके audience के लिए सबसे quiet hours पर सेट करें, और याद रखें कि field UTC में है, आपके local time में नहीं।
Auto-patching को on रखें। overwhelming majority compromised servers उन servers हैं जो software चला रहे हैं जिसके लिए एक patch weeks पहले publish किया गया था। एक pre-patch snapshot automatic rollback के साथ मतलब है कि आमतौर पर objection, कि एक update कुछ break कर सकता है, पहले से ही handled है।
Patch History और अभी Patch चलाना
Patch history section प्रत्येक run को RUNNING, SUCCESS, ROLLED_BACK, FAILED या SKIPPED की status के साथ, updated packages की संख्या के साथ, कि server reboot हुआ या नहीं, और समय list करता है जब यह शुरू हुआ।
schedule के लिए wait करने की बजाय तुरंत patch करने के लिए, Run patch now पर क्लिक करें। confirmation पढ़ता है: "एक snapshot पहले create होता है। Server online रहता है छोड़कर एक brief reboot के लिए यदि एक kernel update को इसकी जरूरत है।"
एक ROLLED_BACK entry मतलब है safety net ने अपना काम किया: सर्वर reboot के बाद cleanly नहीं आया, इसलिए pre-patch snapshot restore किया गया। Cloud Server Snapshots को देखें कि वे snapshots कैसे काम करते हैं।
एक Sensible Baseline
अधिकांश servers के लिए, यह पूरा security configuration है:
| Setting | Recommended |
|---|---|
| Firewall | On, default rules, plus केवल ports जो आपके app को चाहिए |
| fail2ban | On |
| ModSecurity | On, detection-only जब तक आप logs को न पढ़ लें |
| OS auto-patching | On, reboots allowed के साथ एक quiet window में |
| SSH authentication | Keys, passwords नहीं |
अंतिम row यह page पर नहीं है लेकिन बाकी सभी से ज्यादा matters करता है। Connecting to Your Cloud Server With SSH को देखें।
Troubleshooting
"Could not load management config." Panel इस सर्वर के लिए settings को read नहीं कर सका। Reload करें, और check करें कि सर्वर exist करता है और provisioned है।
"Port must be 1-65535." Port field एक whole number लेता है उस range में। Ranges और service names यहां accepted नहीं हैं।
My rule saved but nothing changed. "Live apply unavailable" banner को देखें। यदि यह showing है, तो change stored है लेकिन अभी सर्वर को push नहीं किया गया है।
I can reach my service from one network but not another. यह आमतौर पर आपका खुद का outbound firewall है, सर्वर का नहीं। यहां rules change करने से पहले एक different connection से test करें।
A patch run shows FAILED. Row पर error message को read करें। एक full disk सबसे common cause है। कुछ space free करें और Run patch now पर click करें।
Legitimate traffic started getting blocked. यदि आपने ModSecurity को blocking mode में switch किया, तो इसे detection-only में वापस रखें, logs को read करें, और दोबारा कोशिश करने से पहले rule को identify करें।
यदि एक firewall rule apply होने से refuse करता है, या आप एक service से locked out हैं जिसे आपने allow किया है, तो support@kapsulehost.com को server name, port, और आप क्या expect करते हैं इसे reach करने के साथ email करें।