ಭದ್ರತೆ

ಸರ್ವರ್ ಫೈರ್‌ವಾಲ್ ಸೆಟ್ಟಪ್: DDoS ಮತ್ತು ಬಾಟ್ ಹೋರಾಟಕ್ಕೆ ಸುರಕ್ಷಿತ ಸರ್ವರ್ ಹೇಗೆ ನಿರ್ಮಿಸಬೇಕು

  • 10 ಓದಲು ನಿಮಿಷಗಳು
  • Hostragons ತಂಡ
ಸರ್ವರ್ ಫೈರ್‌ವಾಲ್ ಸೆಟ್ಟಪ್: DDoS ಮತ್ತು ಬಾಟ್ ಹೋರಾಟಕ್ಕೆ ಸುರಕ್ಷಿತ ಸರ್ವರ್ ಹೇಗೆ ನಿರ್ಮಿಸಬೇಕು

ಸರ್ವರ್ ಫೈರ್‌ವಾಲ್ ಸ್ಥಾಪನೆ ಎಂದರೆ, ಸರ್ವರ್‌ನಲ್ಲಿ ಬೇಕಾಗಿರುವ ಪೋರ್ಟ್‌ಗಳನ್ನು ಮಾತ್ರ ತೆರೆಯಿಸಿ ಉಳಿದ ಎಲ್ಲಾ ಅನಗತ್ಯ ಸಂಪರ್ಕಗಳನ್ನು ತಡೆಯುವುದು. ಇದು DDoS, ಬ್ರೂಟ್‌ಫೋರ್ಸ್ ಮತ್ತು ಹಾನಿಕಾರಕ ಬಾಟ್ ಟ್ರಾಫಿಕ್‌ಗಳಿಗೆ ಮೊದಲ ರಕ್ಷಣಾ ಸಾಲು ಆಗುತ್ತದೆ. ಕಾರ್ಯಪ್ರಾಯದಲ್ಲಿ ಗುರಿ: SSH ಪ್ರವೇಶವನ್ನು ನಿಯಂತ್ರಿಸುವುದು, ವೆಬ್ ಸೇವೆಗಳನ್ನು ನಿಯಂತ್ರಿತವಾಗಿ ತೆರೆಯುವುದು, ಅನುಮಾನಾಸ್ಪದ ವಿನಂತಿಗಳನ್ನು ಲಿಮಿಟ್ ಮಾಡುವುದು, ಲಾಗ್‌ಗಳನ್ನು ಗಮನಿಸುವುದು ಹಾಗೂ ಸಾಧ್ಯವಾದರೆ CDN/WAF ಮುಂತಾದ ಮೇಲ್ವಿಚಾರಣಾ ಸುರಕ್ಷಿತ ವ್ಯವಸ್ಥೆ ಮೂಲಕ ಟ್ರಾಫಿಕ್‌ನ್ನು ಸರ್ವರ್‌ಗೆ ಬರಲು ಮುನ್ನೆಡೆಗೆ ಫಿಲ್ಟರ್ ಮಾಡುವುದು.

ನೀವು ವೆಬ್ ಸರ್ವರ್‌ನ್ನು ಇಂಟರ್‌ನೆಟ್‌ಗೆ ತೆರೆದ ತಕ್ಷಣವೇ ನಿಮಿಷಗಳಲ್ಲಿ ಪೋರ್ಟ್ ಸ್ಕ್ಯಾನಿಂಗ್, SSH ಪ್ರಯತ್ನಗಳು, ದುರ್ಬಲತೆಯ ಬಾಟ್‌ಗಳು, ನಕಲಿ ಯುಸರ್-ಏಜೆಂಟ್‌ಗಳು ಎದುರಾಗಬಹುದು. ವಿಶೇಷವಾಗಿ WordPress, ಇ-ಕಾಮರ್ಸ್, ಪ್ಯಾನೆಲ್, API ಅಥವಾ ಗೇಮ್ ಸರ್ವರ್‌ನಲ್ಲಿ ಫೈರ್‌ವಾಲ್‌ ಅನ್ನು ತಾಂತ್ರಿಕ ಆಯ್ಕೆಯಾಗಿ ಅಲ್ಲ, ಆದರೆ ನಿರಂತರ ಸೇವೆಗೆ ಅನಿವಾರ್ಯವಾಗಿ ಬಳಸಬೇಕು. ಈ ಮಾರ್ಗದರ್ಶಿಯಲ್ಲಿ Linux ಸರ್ವರ್‌ಗಳಿಗಾಗಿ ಹಂತ ಹಂತವಾಗಿ ಫೈರ್‌ವಾಲ್ ನಿರ್ಮಾಣ ಮಾಡಲಿದ್ದೇವೆ; UFW, firewalld, nftables, Fail2ban, ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಫೈರ್‌ವಾಲ್ ಮತ್ತು DDoS ಕಡಿತ ವಿಧಾನಗಳನ್ನು ಒಟ್ಟಿಗೆ ನೋಡುತ್ತೇವೆ.

ಮುಖ್ಯ ಒಂದು ನಿಜವನ್ನು ಆರಂಭದಲ್ಲೇ ತಿಳಿದುಕೊಳ್ಳಿ: ಸ್ಥಳೀಯ ಸರ್ವರ್ ಫೈರ್‌ವಾಲ್ ದೊಡ್ಡ ಮಟ್ಟದ DDoS ಹೋರಾಟಗಳನ್ನು ತಡೆಯಲು ಸಾಕಾಗದು. 20 Gbps, 80 Gbps ಅಥವಾ ಹೆಚ್ಚು ಪ್ರಮಾಣದ ದಾಳಿ ಡೇಟಾ ಸೆಂಟರ್ ಅಥವಾ ನೆಟ್‌ವರ್ಕ್‌ backbone ಗೆ ಬಂದಾಗ, ಪ್ಯಾಕೆಟ್‌ಗಳು ನಿಮ್ಮ OS ಫೈರ್‌ವಾಲ್‌ ನಿಯಮಗಳಿಗೆ ಬರುವ ಮೊದಲು bandwidth ತುಂಬಿಸಬಹುದು. ಆದ್ದರಿಂದ ಸರಿಯಾದ ದಾರಿಯೆಂದರೆ ಹಂತ ಹಂತದ ಸುರಕ್ಷತೆ: ಸಪ್ಲೈಯರ್‌ ಲೆವೆಲ್‌ DDoS ಕವಚ, CDN/WAF, OS ಫೈರ್‌ವಾಲ್‌, ಅಪ್ಲಿಕೇಶನ್ ಲಿಮಿಟಿಂಗ್ ಮತ್ತು ನಿಯಮಿತ ಲಾಗ್ ವಿಶ್ಲೇಷಣೆ ಒಟ್ಟಿಗೆ ಕಾರ್ಯಮಾಡಬೇಕು. ಸರಿಯಾದ ಸರ್ವರ್ ಆಯ್ಕೆಗಾಗಿ Hostragons VPS ಮತ್ತು VDS ಸರ್ವರ್ ಪರಿಹಾರಗಳು, ಮತ್ತು ವೆಬ್‌ಸೈಟ್‌ ಭದ್ರತೆಗಾಗಿ Hostragons ವೆಬ್ ಹೋಸ್ಟಿಂಗ್ ಪ್ಯಾಕ್‌ಗಳು ಲಿಂಕ್‌ಗಳನ್ನು ನೋಡಬಹುದು.

ಸರ್ವರ್ ಫೈರ್‌ವಾಲ್‌ ಏನು ಮಾಡುತ್ತದೆ?

ಸರ್ವರ್ ಫೈರ್‌ವಾಲ್‌ ಎಂದರೆ, ನೆಟ್‌ವರ್ಕ್‌ ಟ್ರಾಫಿಕ್‌ IP ಮೂಲ/ಗುರಿ, ಪೋರ್ಟ್, ಪ್ರೋಟೋಕಾಲ್‌, ಸಂಪರ್ಕ ಸ್ಥಿತಿ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಪ್ಯಾಕೆಟ್ ಗುಣಲಕ್ಷಣಗಳ ಆಧಾರದಲ್ಲಿ ಫಿಲ್ಟರ್ ಮಾಡುತ್ತದೆ. ಸರಳ ಉದಾಹರಣೆ: ನಿಮ್ಮ ವೆಬ್‌ಸೈಟ್‌ಗಾಗಿ 80 ಮತ್ತು 443 ಪೋರ್ಟ್‌ಗಳನ್ನು ತೆರೆಯಿರಿ, ಆದರೆ ಡೇಟಾಬೇಸ್‌ ಪೋರ್ಟ್‌ 3306 ಅನ್ನು ಇಂಟರ್‌ನೆಟ್‌ಗೆ ತೆರೆಯಬೇಡಿ. SSH (22) ಪೋರ್ಟ್‌ ಅನ್ನು ಎಲ್ಲರಿಗೂ ಬಿಡುವ ಬದಲು ನಿಮ್ಮ ಕಚೇರಿ IP ಅಥವಾ VPN IPಗೆ ಮಾತ್ರ ಬಿಡುವುದು ಹೆಚ್ಚು ಸುರಕ್ಷಿತ.

ಫೈರ್‌ವಾಲ್‌ ಗುರಿ ಎಲ್ಲ ದಾಳಿಗಳನ್ನು ಮಾಯಮಾಡುವುದು ಅಲ್ಲ. ಗುರಿ ದಾಳಿ ಸಾರ್ಥಕವನ್ನು (Attack Surface) ಕಡಿಮೆ ಮಾಡುವುದು. ಸಾರ್ಥಕ ಕಡಿಮೆ ಮಾಡಿದರೆ, ದಾಳಿಕಾರರು ಪ್ರಯತ್ನಿಸುವ ಆಯ್ಕೆಗಳು ಕಡಿಮೆ ಆಗುತ್ತವೆ. ಹೊಸ Linux ಸರ್ವರ್‌ನಲ್ಲಿ SSH, ವೆಬ್ ಪ್ಯಾನೆಲ್‌, ಮೇಲ್‌ ಸರ್ವೀಸ್‌, ಡೇಟಾಬೇಸ್‌, ಮಾನಿಟರಿಂಗ್‌ ಏಜೆಂಟ್‌, ಟೆಸ್ಟ್‌ ಸರ್ವೀಸ್‌ಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ ತೆರೆದಿರಬಹುದು; ಪ್ರತಿಯೊಂದು ಪ್ರತ್ಯೇಕ ಅಪಾಯ. ಉತ್ತಮ ಫೈರ್‌ವಾಲ್‌ "ಡಿಫಾಲ್ಟ್‌ ರಿಜೆಕ್ಟ್‌, ಬೇಕಾದವು ಮಾತ್ರ ಅಲೌ" ನೀತಿಯಂತೆ ಕಾರ್ಯಮಾಡುವುದು.

DDoS ಹಾಗೂ ಬಾಟ್ ಟ್ರಾಫಿಕ್‌ ತಿಳಿದುಕೊಳ್ಳುವುದು

DDoS ದಾಳಿಗಳು ಯಾಕೆ ವಿಭಿನ್ನ?

DDoS (Distributed Denial of Service) ದಾಳಿ ಎಂದರೆ, ಹಲವಾರು ಮೂಲಗಳಿಂದ ಹೆಚ್ಛು ಟ್ರಾಫಿಕ್‌ ಮೂಲಕ ಗುರಿ ಸೇವೆಯನ್ನು ವಿಫಲಗೊಳಿಸುವ ಪ್ರಯತ್ನ. ಕೆಲವೊಮ್ಮೆ bandwidth ತುಂಬಿಸುತ್ತದೆ, ಕೆಲವೊಮ್ಮೆ ಸರ್ವರ್‌ CPU/RAM ಸಂಪನ್ಮೂಲಗಳನ್ನು ಉಣಸುತ್ತದೆ, ಕೆಲವೊಮ್ಮೆ ಅಪ್ಲಿಕೇಶನ್ ಹಂತದಲ್ಲಿ ಭಾರಿ ಪ್ರೋಸೆಸಿಂಗ್‌ ಮಾಡಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಸಣ್ಣ ಅಪ್ಲಿಕೇಶನ್‌ ಸರ್ವರ್‌ಗೆ ಸೆಕೆಂಡ್‌ಗೆ 50,000 HTTP request ಬಂದರೆ, PHP-FPM, Node.js ಅಥವಾ ಡೇಟಾಬೇಸ್‌ pool‌ಗಳು overload ಆಗಬಹುದು.

ಬಾಟ್‌ಗಳು ಯಾವಾಗಲೂ ಕೆಟ್ಟವವೇ?

ಇಲ್ಲ. Googlebot, Bingbot ಮತ್ತು ಕೆಲವು ಮಾನಿಟರಿಂಗ್ ಬಾಟ್‌ಗಳು ಉಪಯುಕ್ತ. ಆದರೆ ಹಾನಿಕಾರಕ ಬಾಟ್‌ಗಳು ಪ್ಯಾನೆಲ್‌ ಸ್ಕ್ಯಾನಿಂಗ್‌, ಡೈರೆಕ್ಟರಿ ಹುಡುಕುವುದು, ಫಾರ್ಮ್ spam, ಕಂಟೆಂಟ್ copy, XML-RPC ದುರ್ಬಳಕೆ, ನಕಲಿ registration ಮತ್ತು login ಪ್ರಯತ್ನಗಳನ್ನು ಮಾಡುತ್ತವೆ. ಬಾಟ್ ನಿರ್ವಹಣೆಯಲ್ಲಿ ಗುರಿ ಎಲ್ಲಾ ಬಾಟ್‌ಗಳನ್ನು ತಡೆಯುವುದು ಅಲ್ಲ, ಆದರೆ ವರ್ತನೆ ಆಧಾರದಲ್ಲಿ ವಿಭಜಿಸುವುದು. ಹೆಚ್ಚಿನ error rate, ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ಹೆಚ್ಚಿನ request, ನಿಜವಾದ browser ಆಗಿ ವರ್ತಿಸದ headerಗಳು ಮತ್ತು ಅನುಮಾನಾಸ್ಪದ URL pattern‌ಗಳು ಮುಖ್ಯ ಸೂಚನೆಗಳು.

ಆರಂಭಿಸುವ ಮುನ್ನ ಚೆಕ್‌ಲಿಸ್ಟ್

ಲೈವ್‌ ಸರ್ವರ್‌ನಲ್ಲಿ ಫೈರ್‌ವಾಲ್‌ ನಿಯಮ ಬರೆಯುವಾಗ ದೊಡ್ಡ ಅಪಾಯ ಎಂದರೆ, ನೀವು ನಿಮ್ಮನ್ನು ಸರ್ವರ್‌ನಿಂದ lock ಮಾಡಿಕೊಳ್ಳುವುದು. ಆದ್ದರಿಂದ, ಬದಲಾವಣೆ ಮಾಡುವ ಮುನ್ನ ಸಣ್ಣ ತಯಾರಿ ಬೇಕು. ಕೆಳಗಿನ ಚೆಕ್‌ಲಿಸ್ಟ್‌ ಬಹುಬೇಡಿದ ಪ್ರೊಡಕ್ಷನ್‌ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಸುರಕ್ಷಿತ ಆರಂಭಕ್ಕೆ ಉಪಯುಕ್ತ.

  • SSH session‌ನ್ನು ಮುಚ್ಚಬೇಡಿ; ಎರಡನೇ ಟರ್ಮಿನಲ್‌ ಮೂಲಕ ಪರೀಕ್ಷೆ ಮಾಡಿ.
  • ಸರ್ವರ್‌ ಪೂರೈಕೆದಾರರು console/VNC/recovery access ನೀಡುತ್ತಾರೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
  • ಪ್ರಸ್ತುತ ತೆರೆದಿರುವ ಪೋರ್ಟ್‌ಗಳನ್ನು ನೋಡಿಕೊಳ್ಳಿ: ss -tulpn ಅಥವಾ netstat -tulpn output ಪರಿಶೀಲಿಸಿ.
  • Web, mail, DNS, database, panel, monitoring service‌ಗಳು ಯಾವ ಪೋರ್ಟ್ ಬಳಸುತ್ತವೆ ಎಂಬುದನ್ನು ಟಿಪ್ಪಣಿ ಮಾಡಿ.
  • IPv6 ಬಳಸುತ್ತಿದ್ದರೆ IPv6 ಫೈರ್‌ವಾಲ್‌ ನಿಯಮಗಳನ್ನು ಯೋಜಿಸಿ.
  • ಮೊದಲು allow ನಿಯಮ, ನಂತರ deny/ಬ್ಲಾಕ್‌ ನಿಯಮಗಳನ್ನು ಜಾರಿಗೆ ತಂದುಕೊಳ್ಳಿ.
  • ನಿಯಮಗಳು ಸ್ಥಿರವಾಗಿರಲಿ; ಸರ್ವರ್‌ restart ನಂತರವೂ ಉಳಿಯಬೇಕು.

ಉದಾಹರಣೆಗೆ, ಕೇವಲ ವೆಬ್‌ಸೈಟ್‌ host ಮಾಡುವ ಸರ್ವರ್‌ನಲ್ಲಿ ಬಹುಪಾಲು ಸಮಯ 80, 443 ಮತ್ತು ಕಡ್ಡಾಯ SSH ಪೋರ್ಟ್‌ ಮಾತ್ರ ತೆರೆದಿರಬೇಕು. Mail server ಇಲ್ಲದಿದ್ದರೆ 25, 465, 587, 993 ಮುಂತಾದ ಪೋರ್ಟ್‌ಗಳನ್ನು ತೆರೆಯಬೇಕಿಲ್ಲ. Database‌ನ್ನು ಕೇವಲ ಸರ್ವರ್‌ನಿಂದ ಬಳಸುತ್ತಿದ್ದರೆ 3306 ಅಥವಾ 5432 ಅನ್ನು ಇಂಟರ್‌ನೆಟ್‌ಗೆ ತಡೆಯಿರಿ.

ಯಾವ ಫೈರ್‌ವಾಲ್‌ ಟೂಲ್ ಆಯ್ಕೆಮಾಡಬೇಕು?

Linux ಜಗತ್ತಿನಲ್ಲಿ ಹಲವಾರು ಟೂಲ್‌ಗಳು ಇವೆ; ಬಹುಪಾಲು ಒಂದೇ kernel filtering system‌ನ್ನು ವಿವಿಧ ಸೌಕರ್ಯದಿಂದ ನಿರ್ವಹಿಸುತ್ತವೆ. ಹೊಸವರು UFW ಬಳಸಬಹುದು, ಎಂಟರ್‌ಪ್ರೈಸ್ ಅಥವಾ Red Hat ಆಧಾರಿತ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ firewalld ಸಾಮಾನ್ಯ. ಮುಂದಿನ ಹಂತದ ಬಳಕೆದಾರರಿಗೆ nftables ಆಧುನಿಕ ಮತ್ತು ಲವಚಿಕ. ಕೆಳಗಿನ ಟೇಬಲ್‌ ಆಯ್ಕೆ ಸುಲಭಗೊಳಿಸುತ್ತದೆ.

ಯಾವ ಫೈರ್‌ವಾಲ್‌ ಟೂಲ್ ಆಯ್ಕೆಮಾಡಬೇಕು?
ಟೂಲ್ಉತ್ತಮ ಬಳಕೆಲಾಭಎಚ್ಚರಿಕೆ
UFWUbuntu/Debian ಆಧಾರಿತ ಸರಳ ವೆಬ್‌ಸರ್ವರ್‌ಗಳುಸುಲಭ syntax, ತ್ವರಿತ ಸೆಟ್ಟಪ್ಹೆಚ್ಚು ಸಂಕೀರ್ಣ ನಿಯಮಗಳಲ್ಲಿ ಹದಗೆಡಬಹುದು
firewalldAlmaLinux, Rocky, CentOS Stream, RHELZone logic, ಸ್ಥಿರ ನಿಯಮ, service profileruntime/permanent ವ್ಯತ್ಯಾಸ ತಿಳಿಯಬೇಕು
nftablesಅಧಿಕ ಸುರಕ್ಷತೆ ಬೇಕಾದ Linux ಸರ್ವರ್‌ಆಧುನಿಕ, performant, flexibelಗಲತ ನಿಯಮ access outage ಆಗಬಹುದು
Cloud Security GroupsVPS, cloud server, data center perimeterಟ್ರಾಫಿಕ್‌ ಅನ್ನು ಸರ್ವರ್‌ಗೆ ಬರುವ ಮುನ್ನ ಫಿಲ್ಟರ್ ಮಾಡುತ್ತದೆOS firewall‌ನ್ನು ಬದಲಿಗೆ ಅಲ್ಲ, ಜೊತೆಗೆ ಬಳಸಬೇಕು
WAF/CDNWeb Application/HTTP ದಾಳಿBot, HTTP flood, vulnerability scanning ಕಡಿತಸರಿಯಾದ DNS, real IP configuration ಬೇಕು

ಹಂತ ಹಂತವಾಗಿ ಸರ್ವರ್ ಫೈರ್‌ವಾಲ್‌ ಸ್ಥಾಪನೆ

1. ತೆರೆದ ಪೋರ್ಟ್‌ಗಳು ಮತ್ತು ಸೇವೆಗಳನ್ನು ಗುರುತಿಸಿ

ಮೊದಲ ಹಂತ: ಯಾವ ಸೇವೆ/ಪೋರ್ಟ್‌ ತೆರೆದಿದೆ ಎಂಬುದನ್ನು ನೋಡಿಕೊಳ್ಳಿ. Linux ಸರ್ವರ್‌ನಲ್ಲಿ ss -tulpn ಮೂಲಕ ಆ servi‌ces/ports‌ ನೋಡಬಹುದು. ಉದಾಹರಣೆಗೆ, nginx 0.0.0.0:80 ಮತ್ತು 0.0.0.0:443 ಮೇಲೆ listen ಆಗಿದ್ದರೆ ಎಲ್ಲ network‌ಗಳಿಂದ web traffic‌ ಸ್ವೀಕರಿಸುತ್ತಿದೆ. MariaDB 0.0.0.0:3306 ಮೇಲೆ listen ಆಗಿದ್ದರೆ ಅಪಾಯ; ಬಹುಪಾಲು web site‌ಗಳಲ್ಲಿ database 127.0.0.1 (localhost) ಮೇಲೆ listen ಮಾಡಬೇಕು.

ಪ್ರಾಯೋಗಿಕ ನಿಯಮ: ಇಂಟರ್‌ನೆಟ್‌ ಪ್ರವೇಶ ಬೇಕಿಲ್ಲದ ಯಾವ ಸೇವೆಯೂ 0.0.0.0 ಮೇಲೆ listen ಮಾಡಬಾರದು. ಮೊದಲು service config ಸರಿಪಡಿಸಿ, ನಂತರ firewall‌ ಮೂಲಕ ತಡೆಯಿರಿ. firewall disable ಆಗಿದ್ದರೂ service internet‌ಗೆ ತೆರೆದಿರಬಾರದು.

2. ಡಿಫಾಲ್ಟ್‌ ನೀತಿ: "ಕ್ಲೋಸ್"

ಸುರಕ್ಷಿತ ನಿಯಮದಲ್ಲೆಂದರೆ inbound traffic‌ ಅನ್ನು default reject ಮಾಡಬೇಕು, outbound‌ traffic‌ನ್ನು ಅವಶ್ಯಕತೆ ಪ್ರಕಾರ ಬಿಡಬೇಕು. ಇದು ಅನಗತ್ಯ ಸೇವೆಗಳು internet‌ಗೆ ತೆರೆದಿಲ್ಲದಂತೆ ನೋಡಿಕೊಳ್ಳುತ್ತದೆ. UFW ಬಳಸಿ ssh, 80, 443 open ಮಾಡಿ, inbound default deny ಮಾಡಿ, firewall enable ಮಾಡಿ.

Flow: SSHಗೆ admin IP‌ ಅಲೌ ಮಾಡಿ, HTTP/HTTPS open ಮಾಡಿ, ಅನಗತ್ಯ port‌ಗಳನ್ನು ಕ್ಲೋಸ್ ಮಾಡಿ, ನಂತರ firewall enable ಮಾಡಿ. SSH access‌ನ್ನು open ಮಾಡದೆ firewall enable ಮಾಡುವುದು ಬಹುಮಟ್ಟದಲ್ಲಿ lockout ಆಗುತ್ತದೆ.

3. SSH access‌ನ್ನು ನಿಯಂತ್ರಿಸಿ

SSH ಬಹುಪಾಲು ದಾಳಿಕಾರರು ಗುರಿ ಮಾಡುವ ಸೇವೆ. ಡಿಫಾಲ್ಟ್‌ 22 ಪೋರ್ಟ್‌ open ಇದ್ದರೆ ಸಾವಿರಾರು password guessing‌ಗಳು ಬರುತ್ತವೆ. ಅತ್ಯಂತ ಸುರಕ್ಷಿತ ಮಾರ್ಗ: SSH access‌ನ್ನು ನಿರ್ದಿಷ್ಟ IP‌ಗಳಿಗೆ ಮಾತ್ರ ಬಿಡುವುದು. Static IP ಇದ್ದರೆ office/VPN IP‌ ಅಲೌ ಮಾಡಿ. Static IP ಇಲ್ಲದಿದ್ದರೆ, ಕನಿಷ್ಠ key-based authentication ಬಳಸಿ, password access disable ಮಾಡಿ.

  • SSH ಮೂಲಕ root access‌ disable ಮಾಡಿ.
  • Password ಬದಲು SSH key ಬಳಸಿ.
  • AllowUsers/AllowGroups ಮೂಲಕ access‌ ನಿಯಂತ್ರಿಸಿ.
  • Fail2ban ಬಳಸಿ repeated login failure‌ಗಳನ್ನು block ಮಾಡಿ.
  • Panel‌ port‌ಗೂ IP restriction ಹಾಕಿ.

SSH port‌ನ್ನು ಬದಲಾಯಿಸುವುದು bot‌ಗಳು ಕಡಿಮೆ ಆಗುತ್ತದೆ, ಆದರೆ ಪ್ರಾಮಾಣಿಕ ಸುರಕ್ಷತೆ IP limitation, strong authentication, log monitoring‌ ಮೂಲಕ.

4. ವೆಬ್ ಪೋರ್ಟ್‌ಗಳನ್ನು ನಿಯಂತ್ರಿತವಾಗಿ ತೆರೆಯಿರಿ

ವೆಬ್‌ಸೈಟ್‌ host ಮಾಡುವ ಸರ್ವರ್‌ಗಳಿಗೆ 80, 443 ಪೋರ್ಟ್‌ಗಳು ಬೇಕು. ಆದರೆ ಇಂದು 443 (HTTPS) ಮುಖ್ಯ ಟ್ರಾಫಿಕ್‌; 80 ಅನ್ನು HTTPS redirect‌ಗಾಗಿ ಮಾತ್ರ ಬಳಸಿ. SSL ಇಲ್ಲದ site‌ಗಳು user trust ಮತ್ತು SEO performance‌ಗೆ ನಷ್ಟ. Hostragons SSL ಪ್ರಮಣಪತ್ರಗಳು ಜೊತೆ HTTPS setup‌ಗೆ ಮಾರ್ಗದರ್ಶನ ಕೊಡಬಹುದು.

Web ports open ಮಾಡುವಾಗ real IP behaviour ಗಮನಿಸಿ. CDN/proxy ಬಳಕೆ ಇದ್ದರೆ, 80/443 ಪೋರ್ಟ್‌ಗಳನ್ನು CDN IP range‌ಗಳು ಮಾತ್ರ access ಮಾಡಲಿ. ಹೀಗಾಗಿ attacker‌ಗಳು ಸರ್ವರ್ IP ಗೊತ್ತಾದರೂ direct access‌ ಮಾಡಲಾಗದು.

5. Database ಮತ್ತು ಆಂತರಿಕ ಸೇವೆಗಳನ್ನು internet‌ಗೆ ತಡೆಯಿರಿ

MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB ಮುಂತಾದ ಸೇವೆಗಳನ್ನು internet‌ಗೆ open ಮಾಡುವುದು ಅಪಾಯ. Redis authentication‌ ಇಲ್ಲದಿರುವುದು, Elasticsearch unauthorized access‌, MongoDB open admin port‌ಗಳು data leak‌ಗಳಿಗೆ ಕಾರಣ. ಈ ಸೇವೆಗಳು localhost/private network‌ ನಲ್ಲಿ listen ಮಾಡಬೇಕು.

WordPress site‌ಗೆ database‌ನ್ನು 127.0.0.1 ಮೇಲೆ listen ಮಾಡ suffice‌. Application/db‌ನ್ನು split ಮಾಡಿದರೆ, app server‌ IP‌ಗೆ ಮಾತ್ರ access‌ open ಮಾಡಿ. General internet access‌ ಅನ್ನು 3306/5432 ಪೋರ್ಟ್‌ಗಳಿಗೆ ಬಿಡುವುದು bot scanning‌ಗೆ ಆಹ್ವಾನ.

6. Fail2ban ಬಳಸಿ brute-force‌ ದಾಳಿಗಳನ್ನು ತಡೆಯಿರಿ

Fail2ban log‌ಗಳನ್ನು ಗಮನಿಸಿ repeated failure‌ಗಳನ್ನು detect ಮಾಡಿ, IP‌ನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ block ಮಾಡುತ್ತದೆ. SSH, nginx/apache, mail service‌, WordPress login‌ಗಳಿಗೆ jail setup ಮಾಡಬಹುದು. ಉದಾಹರಣೆಗೆ, 10 min‌ಗಳಲ್ಲಿ 5 SSH failure‌ IP‌ನ್ನು 1 hr‌ block ಮಾಡಬಹುದು.

Fail2ban config‌ದಲ್ಲಿ overly aggressive rule‌ಗಳನ್ನು ಬಳಸಿ ತಪ್ಪು user‌ಗಳು block ಆಗಬಹುದು. Bantime moderate‌ ಇಟ್ಟು, log‌ಗಳನ್ನು ಗಮನಿಸಿ, stepwise‌ harden‌ ಮಾಡುವುದು ಉತ್ತಮ.

7. Rate limiting ಮತ್ತು connection limit‌ಗಳು ಹಾಕಿ

DDoS/bot traffic‌ಗೆ OS level‌ rate limiting ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಒಂದೇ IP‌ದಿಂದ excessive connection/sec ಬಂದರೆ limit ಮಾಡಬಹುದು. Web server‌ nginx‌ limit_req, limit_conn, Apache mod_evasive ಬಳಸಬಹುದು. Application‌ login, search, cart, payment, API‌ಗೆ rate limit‌ ಹಾಕಬೇಕು.

ಉದಾಹರಣೆ: Login‌ page‌ಗೆ IP마다 10 attempts/minute. Search API‌ಗೆ IP마다 2-5/sec. API‌ಗೆ user/token/IP behaviour analysis‌ ಮಾಡಿ. ಹೀಗಾಗಿ attacker‌ IP‌ಗಳನ್ನು ವ್ಯತ್ಯಾಸ ಮಾಡಿದರೂ limit‌ವೆಲ್ಲ bypass ಮಾಡಲು ಆಗದು.

UFW ಬಳಸಿ ಉದಾಹರಣೆಯ ಸುರಕ್ಷಿತ ಸೆಟ್ಟಪ್

Ubuntu/Debian web server‌ಗಳಲ್ಲಿ: ಮೊದಲಿಗೆ open services‌ ಪರಿಶೀಲಿಸಿ, admin IP‌ SSH access‌ open ಮಾಡಿ, 80/443 open ಮಾಡಿ, default inbound reject ಮಾಡಿ, UFW status‌ ಪರಿಶೀಲಿಸಿ. Static IP SSH access‌ ಸಾಧ್ಯವಿಲ್ಲದಿದ್ದರೆ, ತಾತ್ಕಾಲಿಕವಾಗಿ ಎಲ್ಲ IP‌ open ಮಾಡಿ, ನಂತರ VPN/static IP‌ಗೆ shift ಮಾಡಿ.

ಉದಾಹರಣೆಯ policy: 203.0.113.10 admin IP‌. SSH ಈ IP‌ ಮಾತ್ರ. Web traffic‌ 80/443 open. Database, Redis, Panel, Test ports‌ close. ಈ policy‌ ಬಹುಮಟ್ಟದ SME‌ಗಳಿಗೆ ಉತ್ತಮ. Domain/DNS correct pointing‌ಗೆ Hostragons ಡೊಮೇನ್ ಪರಿಶೀಲನೆ ಮತ್ತು ನೋಂದಣಿ ಲಿಂಕ್‌ ಬಳಸಿ.

firewalld zone ಪದ್ಧತಿ

AlmaLinux, Rocky, RHEL server‌ಗಳಲ್ಲಿ firewalld zone concept‌. Public zone open interfaces, trusted zone private network, drop zone unwanted traffic. Runtime/permanent rule ವ್ಯತ್ಯಾಸ. Runtime rule instant, restart‌ಗೆ ಉಳಿಯದು; permanent rule stable, reload ಬೇಕು.

firewalld‌ನಲ್ಲಿ service-based definition‌ಗಳು ಕೆಲಸ ಸುಲಭ. http/https‌ನ್ನು public zone‌ open ಮಾಡಿ, ssh‌ಗೆ source IP limitation ಹಾಕಿ. Management, backup, user traffic‌ split zone‌ಗಳಲ್ಲಿ ಹಾಕಿದರೆ security/readability ಸುಧಾರಣೆ.

CDN, WAF ಮತ್ತು ಸಪ್ಲೈಯರ್‌ ಲೆವೆಲ್ DDoS ರಕ್ಷಣೆ

ಸ್ಥಳೀಯ firewall packet‌ಗಳು ಸರ್ವರ್‌ಗೆ ಬಂದ ಮೇಲೆ filter ಮಾಡುತ್ತವೆ. ದೊಡ್ಡ DDoS‌ನಲ್ಲಿ ಗುರಿ: traffic‌ನ್ನು ಸರ್ವರ್‌ಗೆ ಬರುವ ಮುನ್ನ filter ಮಾಡುವುದು. CDN/WAF/provider DDoS protection‌ ಅತ್ಯಗತ್ಯ. CDN‌ನಲ್ಲಿ static content‌ edge‌ಗಳಲ್ಲಿ serve ಆಗುತ್ತದೆ, WAF‌ application layer‌ harmful requests‌ filter ಮಾಡುತ್ತದೆ, provider‌ network level‌ attack‌ಗಳನ್ನು soak/clean ಮಾಡುತ್ತದೆ.

ಆದರ್ಶ model: DNS record‌ಗಳು CDN ಮೂಲಕ, real server IP‌ hide, firewall‌ CDN IP range‌ಗಷ್ಟೇ 80/443 access‌. Management ports‌ VPN/static IP‌. ಈ model‌ direct IP attack‌ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, bot traffic‌ application‌ಕ್ಕೆ ಬರುವ ಮುನ್ನ filter ಆಗುತ್ತದೆ. Web security/performance‌ಗೆ ವೆಬ್ ಸೈಟ್ ವೇಗಗೊಳ್ಳುವುದು ಮತ್ತು ಸುರಕ್ಷತೆ ಮಾರ್ಗದರ್ಶಿಗಳು ಲಿಂಕ್‌ ಬಳಸಬಹುದು.

ಬಾಟ್‌ಗಳ ವಿರುದ್ಧ ಅಪ್ಲಿಕೇಶನ್ ಹಂತದ ರಕ್ಷಣಾ ಕ್ರಮ

ಬಾಟ್‌ಗಳ ವಿರುದ್ಧ ಅಪ್ಲಿಕೇಶನ್ ಹಂತದ ರಕ್ಷಣಾ ಕ್ರಮ

Bot‌ block‌ ಮಾಡುವುದು IP ban‌ ಮಾತ್ರ ಅಲ್ಲ. Modern bot‌ಗಳು proxy, mobile network, data center IP, variable user-agent‌ ಬಳಸಬಹುದು. ಹೀಗಾಗಿ behaviour analysis‌ ಅಗತ್ಯ. Short time‌ನಲ್ಲಿ excessive login‌, repeated 404, wp-login.php/xmlrpc.php spike‌, normal user‌ differing click pattern‌, suspicious header‌ಗಳು ವಿಶ್ಲೇಷಣೆ ಅಗತ್ಯ.

  • Login/signup form‌ಗಳಲ್ಲಿ rate limit‌ ಹಾಕಿ.
  • XML-RPC access‌ನ್ನು disable/limit ಮಾಡಿ.
  • Admin panel‌ URL‌ obfuscate/IP restrict/MFA protect ಮಾಡಿ.
  • Suspicious user-agent/referer‌ಗಳು WAF‌ನಲ್ಲಿ filter ಮಾಡಿ.
  • Form CAPTCHA/invisible bot detection balanced‌ ಬಳಸಿ.
  • API keys/signature/quota/timestamp‌ check‌ ಹಾಕಿ.

Bot management‌ನಲ್ಲಿ real user UX‌ ಹದಗೆಡಬಾರದು. Overly CAPTCHA, aggressive block‌, wrong geo block‌ real customer‌ಗೆ ಅಪಾಯ. ಹೀಗಾಗಿ measurement/test/gradual harden‌ ಉತ್ತಮ.

ಲಾಗ್‌ ಮאָנಿಟರಿಂಗ್ ಮತ್ತು ಅಲಾರ್ಮ್ ನಿಯಮಗಳು

Install‌ ಮಾಡಿದರೆ ಸಾಕು ಎಂಬುದು ತಪ್ಪು. Firewall‌ live system‌, ನಿಯಮಿತವಾಗಿ ಮಾನಿಟರ್‌ ಮಾಡಬೇಕು. auth.log/secure‌ನಲ್ಲಿ SSH tries, nginx access‌ abnormal request‌, error log‌ಗಳಲ್ಲಿ 404/500 spike‌, system metrics‌ CPU/connection count‌ track‌ ಮಾಡಬೇಕು. Basic alert‌ ಕೂಡ ದಾಳಿ ಆರಂಭವಾಗುತ್ತಿದ್ದಂತೆ ನಿಮಿಷಗಳನ್ನು ಉಳಿಸುತ್ತದೆ.

Sample thresholds: 5 min‌ನಲ್ಲಿ same IP 100+ 404, 1 min‌ನಲ್ಲಿ login page 20+ tries, CPU 10 min‌ 90%+, connection count‌ 3x normal. Threshold‌ಗಳು site‌마다 ವಿಭಿನ್ನ; ನಿಮ್ಮ normal profile‌ ಗೊತ್ತುಮಾಡಿಕೊಳ್ಳುವುದು ಮುಖ್ಯ.

ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು ಮತ್ತು ತಪ್ಪಿಸುವ ವಿಧಾನ

  • SSH permission‌ ಇಲ್ಲದೆ firewall enable: Remote server‌ access‌ ಕಳೆದುಕೊಳ್ಳಬಹುದು. hamesha second session‌ test ಮಾಡಿ.
  • IPv6 ಮರೆತುಬಿಡುವುದು: IPv4‌ close‌ ಇದ್ದರೂ IPv6‌ ಮೂಲಕ service‌ open ಆಗಬಹುದು.
  • Database‌ internet‌ open: 3306, 5432, 6379, 9200‌ bot‌ಗಳು scan ಮಾಡುತ್ತವೆ.
  • CDN ಬಳಸಿ real IP‌ open: attacker‌ CDN‌ bypass ಮಾಡಿ server‌ಗೆ attack ಮಾಡಬಹುದು.
  • Rule documentation‌ ಇಲ್ಲದೆ change: emergency‌ rule purpose‌ ಗೊತ್ತಾಗದು.
  • Backup access plan‌ ಇಲ್ಲದೆ: Wrong rule‌ console access‌ ಇಲ್ಲದಿದ್ದರೆ outage‌ ದೀರ್ಘ.

ಪ್ರಾಯೋಗಿಕ ಫೈರ್‌ವಾಲ್‌ ನೀತಿ ಮಾದರಿ

Small business web site‌ policy: inbound traffic default closed; 443 all visitors‌ open; 80 HTTPS redirect‌ open; SSH VPN/static admin IP‌ open; database localhost/private; CDN ಇದ್ದರೆ 80/443 CDN IP range‌ open; Fail2ban SSH/web login‌ monitor; daily logs‌ central monitoring tool‌ಗೆ push.

Medium ecommerce site‌ policy: payment callback IP allowlist, admin panel VPN‌ಕೆ shift, API user quota, WAF SQL injection/XSS rule active, country/ASN temporary filter plan. Policy‌ writing‌ ಮುಖ್ಯ; attack‌ time‌ decision‌ bad, pre-defined‌ procedure‌ outage‌ duration‌ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಪರೀಕ್ಷೆ: ನಿಯಮಗಳು ನಿಜವಾಗಿಯೂ ಕೆಲಸ ಮಾಡುತ್ತವೆ?

Firewall‌ setup‌ ನಂತರ test ಮಾಡಬೇಕು. Alternate network‌ open port scan ಮಾಡಿ, SSH only permitted IP‌ access check, web site HTTPS access check, database port external closed check. CDN ಇದ್ದರೆ real server IP‌ಗೆ HTTP request‌ block check.

Testing‌ನಲ್ಲಿ overly aggressive scan‌ avoid. Objective‌ safe verification. ಪ್ರತಿ change‌ ನಂತರ rule export/note ಮಾಡಿ. Issue‌ ಬಂದರೆ previous good config‌ revert‌ ಸುಲಭ.

Maintenance ಮತ್ತು update‌ ಯೋಜನೆ

Server security one-time‌ install ಅಲ್ಲ, regular maintenance ಅಗತ್ಯ. New service‌ add‌ ಮಾಡಿದಾಗ port need‌ review, old service‌ remove‌ ಮಾಡಿದಾಗ permission‌ revoke, timely security update, periodic log audit. Minimum monthly port audit, quarterly firewall rule review‌ good practice.

Backup plan‌ security‌ ಭಾಗ. DDoS access‌ cut ಮಾಡಬಹುದು, ransom/malware‌ data loss ಕೊಡಬಹುದು. Secure hosting, SSL, domain management, backup‌ ಒಟ್ಟಿಗೆ combine‌ ಮಾಡಬೇಕು. ಭದ್ರ ಹೋಸ್ಟಿಂಗ್ ಆಯ್ಕೆ ಮಾಡುವಾಗ ಗಮನದಲ್ಲಿರಬಹುದಾದವುಗಳು ಮತ್ತು SSL ಪ್ರಮಾಣಪತ್ರ ಸ್ಥಾಪನೆ ಹೇಗೆ ಮಾಡುವುದು ಲಿಂಕ್‌ಗಳು ಮುಂದಿನ ಅಧ್ಯಾಯಕ್ಕೆ ಸರಿಯಾದ ಸಂಪರ್ಕ.

ನಿರ್ಣಯ

ಸರ್ವರ್ ಫೈರ್‌ವಾಲ್‌ ಸ್ಥಾಪನೆ DDoS ಮತ್ತು ಬಾಟ್‌ಗಳಿಂದ ಸಂಪೂರ್ಣ invisible ಮಾಡಲ್ಲ; ಆದರೆ ದಾಳಿ ಸಾರ್ಥಕವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, unauthorized access‌ ಅಪಾಯವನ್ನು ತಗ್ಗಿಸುತ್ತದೆ, incident‌ಗಳಿಗೆ more controlled response‌ ಕೊಡುತ್ತದೆ. Best result: provider DDoS protection, CDN/WAF, strict port policy, SSH restriction, Fail2ban, rate limiting, regular log monitoring‌ ಒಟ್ಟಿಗೆ ಬಳಸಿದಾಗ.

New project‌ publish‌ ಮಾಡಲು firewall policy‌ early‌ plan ಮಾಡಿ, later‌ correction‌ಗಿಂತ easy‌. Hostragons‌ನಲ್ಲಿ server/hosting/domain/SSL‌ evaluate‌ ಮಾಡಿದಾಗ security‌ needs‌ combine‌ ಮಾಡಿ robust web environment‌ ನಿರ್ಮಿಸಬಹುದು. Small checklist‌: open ports‌ close, SSH restrict, HTTPS mandate, logs‌ monitor.

ಪದೇಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

ಸರ್ವರ್ ಫೈರ್‌ವಾಲ್‌ DDoS‌ completely‌ ತಡೆಯುತ್ತಾ?

ಇಲ್ಲ. Local firewall‌ small/protocol level‌ attacks‌ reduce ಮಾಡಬಹುದು, but big DDoS‌ಗಾಗಿ provider level DDoS, CDN, WAF‌ ಬೇಕು.

Web server‌ ಯಾವ ಪೋರ್ಟ್‌ open‌ ಇರಬೇಕು?

Typical web server‌ 80/443 open‌ ಇರಬೇಕು. SSH admin IP‌ permission‌ ಮಾತ್ರ. Database/internal ports‌ internet‌ಗೆ close.

UFW/firewalld‌ ಯಾವುದು ಬಳಸಬೇಕು?

Ubuntu/Debian‌ಗೆ UFW easy start. AlmaLinux/Rocky/RHEL‌ firewalld common. Advanced/custom‌ nftables‌ use ಮಾಡಬಹುದು.

Bot traffic‌ IP block‌ sufficient?

ಹೆಚ್ಚು ವೇಳೆ ಇಲ್ಲ. Modern bot‌ಗಳು variable IP/proxy‌ ಬಳಸುತ್ತವೆ. IP block‌ ಜೊತೆಗೆ rate limiting, WAF rules, behaviour analysis, CAPTCHA, quota use ಮಾಡಬೇಕು.

Firewall‌ setup‌ major risk‌ ಯಾವುದು?

Wrong rule‌ SSH access‌ cut ಮಾಡುವುದು. First SSH allow, second session test, provider console access‌ ready‌ ಇರಬೇಕು.

ಈ ಲೇಖನವನ್ನು ಹಂಚಿಕೊಳ್ಳಿ:

Hostragons ತಂಡ

ಹೋಸ್ಟಿಂಗ್, ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಡೊಮೇನ್ ಹೆಸರುಗಳ ಕುರಿತು ನಮ್ಮ ತಜ್ಞರ ತಂಡದಿಂದ ನವೀಕೃತ ಮಾರ್ಗದರ್ಶಿಗಳು. ನಿಮ್ಮ ಯೋಜನೆಗೆ ಸರಿಯಾದ ಪರಿಹಾರವನ್ನು ಒಟ್ಟಾಗಿ ಕಂಡುಕೊಳ್ಳೋಣ.

ನಮ್ಮನ್ನು ಸಂಪರ್ಕಿಸಿ