ರಕ್ಷಣೆಗೆ DDoS: ನಾವು ಒತ್ತಡ ಮತ್ತು ಲೋಡ್ ಪರೀಕ್ಷೆಗಳನ್ನು ಹೇಗೆ ನಡೆಸುತ್ತೇವೆ

Variti ಬಾಟ್‌ಗಳು ಮತ್ತು DDoS ದಾಳಿಗಳ ವಿರುದ್ಧ ರಕ್ಷಣೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತದೆ ಮತ್ತು ಒತ್ತಡ ಮತ್ತು ಲೋಡ್ ಪರೀಕ್ಷೆಯನ್ನು ಸಹ ನಡೆಸುತ್ತದೆ. HighLoad++ 2018 ಸಮ್ಮೇಳನದಲ್ಲಿ ನಾವು ವಿವಿಧ ರೀತಿಯ ದಾಳಿಗಳಿಂದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೇಗೆ ಸುರಕ್ಷಿತಗೊಳಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡಿದ್ದೇವೆ. ಸಂಕ್ಷಿಪ್ತವಾಗಿ: ಸಿಸ್ಟಮ್‌ನ ಭಾಗಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ, ಕ್ಲೌಡ್ ಸೇವೆಗಳು ಮತ್ತು ಸಿಡಿಎನ್‌ಗಳನ್ನು ಬಳಸಿ ಮತ್ತು ನಿಯಮಿತವಾಗಿ ನವೀಕರಿಸಿ. ಆದರೆ ವಿಶೇಷ ಕಂಪನಿಗಳಿಲ್ಲದೆ ನೀವು ಇನ್ನೂ ರಕ್ಷಣೆಯನ್ನು ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ :)

ಪಠ್ಯವನ್ನು ಓದುವ ಮೊದಲು, ನೀವು ಸಂಕ್ಷಿಪ್ತ ಸಾರಾಂಶಗಳನ್ನು ಓದಬಹುದು ಸಮ್ಮೇಳನದ ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ.
ಮತ್ತು ನೀವು ವೀಡಿಯೊವನ್ನು ಓದಲು ಇಷ್ಟಪಡದಿದ್ದರೆ ಅಥವಾ ವೀಕ್ಷಿಸಲು ಬಯಸಿದರೆ, ನಮ್ಮ ವರದಿಯ ರೆಕಾರ್ಡಿಂಗ್ ಸ್ಪಾಯ್ಲರ್ ಅಡಿಯಲ್ಲಿ ಕೆಳಗೆ ಇದೆ.

ವರದಿಯ ವಿಡಿಯೋ ರೆಕಾರ್ಡಿಂಗ್

ಅನೇಕ ಕಂಪನಿಗಳು ಈಗಾಗಲೇ ಲೋಡ್ ಪರೀಕ್ಷೆಯನ್ನು ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ತಿಳಿದಿವೆ, ಆದರೆ ಎಲ್ಲರೂ ಒತ್ತಡ ಪರೀಕ್ಷೆಯನ್ನು ಮಾಡುವುದಿಲ್ಲ. ನಮ್ಮ ಕೆಲವು ಗ್ರಾಹಕರು ತಮ್ಮ ಸೈಟ್ ಅನ್ನು ಅವೇಧನೀಯ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ ಏಕೆಂದರೆ ಅವರು ಹೈಲೋಡ್ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಇದು ದಾಳಿಯಿಂದ ಉತ್ತಮವಾಗಿ ರಕ್ಷಿಸುತ್ತದೆ. ಇದು ಸಂಪೂರ್ಣವಾಗಿ ನಿಜವಲ್ಲ ಎಂದು ನಾವು ತೋರಿಸುತ್ತೇವೆ.
ಸಹಜವಾಗಿ, ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುವ ಮೊದಲು, ನಾವು ಗ್ರಾಹಕರಿಂದ ಅನುಮತಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ, ಸಹಿ ಮತ್ತು ಸ್ಟ್ಯಾಂಪ್ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ನಮ್ಮ ಸಹಾಯದಿಂದ DDoS ದಾಳಿಯನ್ನು ಯಾರ ಮೇಲೂ ನಡೆಸಲಾಗುವುದಿಲ್ಲ. ಗ್ರಾಹಕರು ಆಯ್ಕೆಮಾಡಿದ ಸಮಯದಲ್ಲಿ ಪರೀಕ್ಷೆಯನ್ನು ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ, ಅವರ ಸಂಪನ್ಮೂಲಕ್ಕೆ ದಟ್ಟಣೆ ಕಡಿಮೆಯಾದಾಗ ಮತ್ತು ಪ್ರವೇಶ ಸಮಸ್ಯೆಗಳು ಗ್ರಾಹಕರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಯಾವಾಗಲೂ ಏನಾದರೂ ತಪ್ಪಾಗಬಹುದು, ನಾವು ಗ್ರಾಹಕರೊಂದಿಗೆ ನಿರಂತರ ಸಂಪರ್ಕವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಸಾಧಿಸಿದ ಫಲಿತಾಂಶಗಳನ್ನು ವರದಿ ಮಾಡಲು ಮಾತ್ರವಲ್ಲದೆ ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಏನನ್ನಾದರೂ ಬದಲಾಯಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಪರೀಕ್ಷೆಯ ಪೂರ್ಣಗೊಂಡ ನಂತರ, ನಾವು ಯಾವಾಗಲೂ ವರದಿಯನ್ನು ರಚಿಸುತ್ತೇವೆ, ಅದರಲ್ಲಿ ನಾವು ಪತ್ತೆಯಾದ ನ್ಯೂನತೆಗಳನ್ನು ಎತ್ತಿ ತೋರಿಸುತ್ತೇವೆ ಮತ್ತು ಸೈಟ್‌ನ ದೌರ್ಬಲ್ಯಗಳನ್ನು ತೆಗೆದುಹಾಕಲು ಶಿಫಾರಸುಗಳನ್ನು ನೀಡುತ್ತೇವೆ.

ನಾವು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ

ಪರೀಕ್ಷಿಸುವಾಗ, ನಾವು ಬೋಟ್ನೆಟ್ ಅನ್ನು ಅನುಕರಿಸುತ್ತೇವೆ. ನಮ್ಮ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿಲ್ಲದ ಕ್ಲೈಂಟ್‌ಗಳೊಂದಿಗೆ ನಾವು ಕೆಲಸ ಮಾಡುವುದರಿಂದ, ಮಿತಿಗಳು ಅಥವಾ ರಕ್ಷಣೆಯನ್ನು ಪ್ರಚೋದಿಸುವ ಕಾರಣದಿಂದಾಗಿ ಪರೀಕ್ಷೆಯು ಮೊದಲ ನಿಮಿಷದಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ನಾವು ಲೋಡ್ ಅನ್ನು ಒಂದು ಐಪಿಯಿಂದ ಅಲ್ಲ, ಆದರೆ ನಮ್ಮದೇ ಸಬ್‌ನೆಟ್‌ನಿಂದ ಪೂರೈಸುತ್ತೇವೆ. ಜೊತೆಗೆ, ಗಮನಾರ್ಹವಾದ ಲೋಡ್ ಅನ್ನು ರಚಿಸಲು, ನಾವು ನಮ್ಮದೇ ಆದ ಸಾಕಷ್ಟು ಶಕ್ತಿಯುತ ಪರೀಕ್ಷಾ ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ.

ಪೋಸ್ಟ್ಯುಲೇಟ್ಗಳು

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

ಸಂಪೂರ್ಣ ವೈಫಲ್ಯಕ್ಕಿಂತ ಭಾಗಶಃ ವೈಫಲ್ಯ ಉತ್ತಮವಾಗಿದೆ
ವ್ಯವಸ್ಥೆಗಳನ್ನು ವೈವಿಧ್ಯಮಯವಾಗಿಸಲು ನಾವು ಯಾವಾಗಲೂ ಸಲಹೆ ನೀಡುತ್ತೇವೆ. ಇದಲ್ಲದೆ, ಅವುಗಳನ್ನು ಭೌತಿಕ ಮಟ್ಟದಲ್ಲಿ ಬೇರ್ಪಡಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ, ಮತ್ತು ಕೇವಲ ಕಂಟೈನರೈಸೇಶನ್ ಮೂಲಕ ಅಲ್ಲ. ಭೌತಿಕ ಬೇರ್ಪಡಿಕೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ಸೈಟ್ನಲ್ಲಿ ಏನಾದರೂ ವಿಫಲವಾದರೂ, ಅದು ಸಂಪೂರ್ಣವಾಗಿ ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುವುದಿಲ್ಲ ಎಂಬ ಹೆಚ್ಚಿನ ಸಂಭವನೀಯತೆಯಿದೆ, ಮತ್ತು ಬಳಕೆದಾರರು ಕನಿಷ್ಟ ಭಾಗದ ಕ್ರಿಯಾತ್ಮಕತೆಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರುತ್ತಾರೆ.

ಉತ್ತಮ ವಾಸ್ತುಶಿಲ್ಪವು ಸುಸ್ಥಿರತೆಗೆ ಆಧಾರವಾಗಿದೆ
ಸಂಪನ್ಮೂಲದ ದೋಷ ಸಹಿಷ್ಣುತೆ ಮತ್ತು ದಾಳಿಗಳು ಮತ್ತು ಹೊರೆಗಳನ್ನು ತಡೆದುಕೊಳ್ಳುವ ಸಾಮರ್ಥ್ಯವು ವಿನ್ಯಾಸ ಹಂತದಲ್ಲಿ, ವಾಸ್ತವವಾಗಿ, ನೋಟ್ಬುಕ್ನಲ್ಲಿ ಮೊದಲ ಫ್ಲೋಚಾರ್ಟ್ಗಳನ್ನು ಸೆಳೆಯುವ ಹಂತದಲ್ಲಿ ಇಡಬೇಕು. ಏಕೆಂದರೆ ಮಾರಣಾಂತಿಕ ದೋಷಗಳು ಹರಿದಾಡಿದರೆ, ಭವಿಷ್ಯದಲ್ಲಿ ಅವುಗಳನ್ನು ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಿದೆ, ಆದರೆ ಇದು ತುಂಬಾ ಕಷ್ಟ.

ಕೋಡ್ ಉತ್ತಮವಾಗಿರಬೇಕು, ಆದರೆ ಸಂರಚನೆಯೂ ಆಗಿರಬೇಕು
ಉತ್ತಮ ಅಭಿವೃದ್ಧಿ ತಂಡವು ದೋಷ-ಸಹಿಷ್ಣು ಸೇವೆಯ ಭರವಸೆ ಎಂದು ಅನೇಕ ಜನರು ಭಾವಿಸುತ್ತಾರೆ. ಉತ್ತಮ ಅಭಿವೃದ್ಧಿ ತಂಡವು ನಿಜವಾಗಿಯೂ ಅವಶ್ಯಕವಾಗಿದೆ, ಆದರೆ ಉತ್ತಮ ಕಾರ್ಯಾಚರಣೆಗಳು, ಉತ್ತಮ DevOps ಕೂಡ ಇರಬೇಕು. ಅಂದರೆ, ನಮಗೆ ಲಿನಕ್ಸ್ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡುವ, nginx ನಲ್ಲಿ ಕಾನ್ಫಿಗ್‌ಗಳನ್ನು ಸರಿಯಾಗಿ ಬರೆಯುವ, ಮಿತಿಗಳನ್ನು ಹೊಂದಿಸುವ ತಜ್ಞರು ನಮಗೆ ಅಗತ್ಯವಿದೆ. ಇಲ್ಲದಿದ್ದರೆ, ಸಂಪನ್ಮೂಲವು ಪರೀಕ್ಷೆಯಲ್ಲಿ ಮಾತ್ರ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಮತ್ತು ಕೆಲವು ಹಂತದಲ್ಲಿ ಎಲ್ಲವೂ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಮುರಿಯುತ್ತದೆ.

ಲೋಡ್ ಮತ್ತು ಒತ್ತಡ ಪರೀಕ್ಷೆಯ ನಡುವಿನ ವ್ಯತ್ಯಾಸಗಳು
ಲೋಡ್ ಪರೀಕ್ಷೆಯು ಸಿಸ್ಟಮ್ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಮಿತಿಗಳನ್ನು ಗುರುತಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಒತ್ತಡ ಪರೀಕ್ಷೆಯು ವ್ಯವಸ್ಥೆಯ ದುರ್ಬಲ ಅಂಶಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವ ಗುರಿಯನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ಮುರಿಯಲು ಮತ್ತು ಕೆಲವು ಭಾಗಗಳ ವೈಫಲ್ಯದ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಅದು ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಲು ಬಳಸಲಾಗುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಒತ್ತಡ ಪರೀಕ್ಷೆ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಲೋಡ್‌ನ ಸ್ವರೂಪವು ಸಾಮಾನ್ಯವಾಗಿ ಗ್ರಾಹಕರಿಗೆ ತಿಳಿದಿಲ್ಲ.

L7 ದಾಳಿಯ ವಿಶಿಷ್ಟ ಲಕ್ಷಣಗಳು

ನಾವು ಸಾಮಾನ್ಯವಾಗಿ L7 ಮತ್ತು L3&4 ಹಂತಗಳಲ್ಲಿ ಲೋಡ್ ವಿಧಗಳನ್ನು ಲೋಡ್ಗಳಾಗಿ ವಿಭಜಿಸುತ್ತೇವೆ. L7 ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದಲ್ಲಿ ಒಂದು ಲೋಡ್ ಆಗಿದೆ, ಹೆಚ್ಚಾಗಿ ಇದು ಕೇವಲ HTTP ಎಂದರ್ಥ, ಆದರೆ ನಾವು TCP ಪ್ರೋಟೋಕಾಲ್ ಮಟ್ಟದಲ್ಲಿ ಯಾವುದೇ ಲೋಡ್ ಅನ್ನು ಅರ್ಥೈಸುತ್ತೇವೆ.
L7 ದಾಳಿಗಳು ಕೆಲವು ವಿಶಿಷ್ಟ ಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿವೆ. ಮೊದಲನೆಯದಾಗಿ, ಅವರು ನೇರವಾಗಿ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಬರುತ್ತಾರೆ, ಅಂದರೆ, ಅವರು ನೆಟ್‌ವರ್ಕ್ ವಿಧಾನಗಳ ಮೂಲಕ ಪ್ರತಿಫಲಿಸುವ ಸಾಧ್ಯತೆಯಿಲ್ಲ. ಅಂತಹ ದಾಳಿಗಳು ತರ್ಕವನ್ನು ಬಳಸುತ್ತವೆ ಮತ್ತು ಇದರಿಂದಾಗಿ, ಅವರು CPU, ಮೆಮೊರಿ, ಡಿಸ್ಕ್, ಡೇಟಾಬೇಸ್ ಮತ್ತು ಇತರ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಅತ್ಯಂತ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಮತ್ತು ಕಡಿಮೆ ದಟ್ಟಣೆಯೊಂದಿಗೆ ಬಳಸುತ್ತಾರೆ.

HTTP ಪ್ರವಾಹ

ಯಾವುದೇ ದಾಳಿಯ ಸಂದರ್ಭದಲ್ಲಿ, ಲೋಡ್ ಅನ್ನು ನಿಭಾಯಿಸುವುದಕ್ಕಿಂತ ಸುಲಭವಾಗಿ ರಚಿಸಬಹುದು, ಮತ್ತು L7 ನ ಸಂದರ್ಭದಲ್ಲಿ ಇದು ಸಹ ನಿಜವಾಗಿದೆ. ದಾಳಿಯ ದಟ್ಟಣೆಯನ್ನು ಕಾನೂನುಬದ್ಧ ದಟ್ಟಣೆಯಿಂದ ಪ್ರತ್ಯೇಕಿಸುವುದು ಯಾವಾಗಲೂ ಸುಲಭವಲ್ಲ, ಮತ್ತು ಹೆಚ್ಚಾಗಿ ಇದನ್ನು ಆವರ್ತನದಿಂದ ಮಾಡಬಹುದು, ಆದರೆ ಎಲ್ಲವನ್ನೂ ಸರಿಯಾಗಿ ಯೋಜಿಸಿದ್ದರೆ, ದಾಳಿ ಎಲ್ಲಿದೆ ಮತ್ತು ಕಾನೂನುಬದ್ಧ ವಿನಂತಿಗಳು ಎಲ್ಲಿವೆ ಎಂಬುದನ್ನು ಲಾಗ್‌ಗಳಿಂದ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಅಸಾಧ್ಯ.
ಮೊದಲ ಉದಾಹರಣೆಯಾಗಿ, HTTP ಪ್ರವಾಹದ ದಾಳಿಯನ್ನು ಪರಿಗಣಿಸಿ. ಅಂತಹ ದಾಳಿಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಅತ್ಯಂತ ಶಕ್ತಿಯುತವಾಗಿವೆ ಎಂದು ಗ್ರಾಫ್ ತೋರಿಸುತ್ತದೆ; ಕೆಳಗಿನ ಉದಾಹರಣೆಯಲ್ಲಿ, ವಿನಂತಿಗಳ ಗರಿಷ್ಠ ಸಂಖ್ಯೆ ನಿಮಿಷಕ್ಕೆ 600 ಸಾವಿರ ಮೀರಿದೆ.

HTTP ಪ್ರವಾಹವು ಲೋಡ್ ಅನ್ನು ರಚಿಸಲು ಸುಲಭವಾದ ಮಾರ್ಗವಾಗಿದೆ. ವಿಶಿಷ್ಟವಾಗಿ, ಇದು ApacheBench ನಂತಹ ಕೆಲವು ರೀತಿಯ ಲೋಡ್ ಪರೀಕ್ಷಾ ಸಾಧನವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ವಿನಂತಿಯನ್ನು ಮತ್ತು ಗುರಿಯನ್ನು ಹೊಂದಿಸುತ್ತದೆ. ಅಂತಹ ಸರಳವಾದ ವಿಧಾನದೊಂದಿಗೆ, ಸರ್ವರ್ ಕ್ಯಾಶಿಂಗ್ಗೆ ಚಾಲನೆಯಾಗುವ ಹೆಚ್ಚಿನ ಸಂಭವನೀಯತೆಯಿದೆ, ಆದರೆ ಅದನ್ನು ಬೈಪಾಸ್ ಮಾಡುವುದು ಸುಲಭ. ಉದಾಹರಣೆಗೆ, ವಿನಂತಿಗೆ ಯಾದೃಚ್ಛಿಕ ತಂತಿಗಳನ್ನು ಸೇರಿಸುವುದು, ಇದು ತಾಜಾ ಪುಟವನ್ನು ನಿರಂತರವಾಗಿ ಪೂರೈಸಲು ಸರ್ವರ್ ಅನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ.
ಅಲ್ಲದೆ, ಲೋಡ್ ಅನ್ನು ರಚಿಸುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಬಳಕೆದಾರ-ಏಜೆಂಟ್ ಬಗ್ಗೆ ಮರೆಯಬೇಡಿ. ಜನಪ್ರಿಯ ಪರೀಕ್ಷಾ ಸಾಧನಗಳ ಅನೇಕ ಬಳಕೆದಾರ-ಏಜೆಂಟ್‌ಗಳನ್ನು ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ಫಿಲ್ಟರ್ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ ಲೋಡ್ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ತಲುಪುವುದಿಲ್ಲ. ವಿನಂತಿಯಲ್ಲಿ ಬ್ರೌಸರ್‌ನಿಂದ ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಮಾನ್ಯವಾದ ಹೆಡರ್ ಅನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ನೀವು ಫಲಿತಾಂಶವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಸುಧಾರಿಸಬಹುದು.
HTTP ಪ್ರವಾಹದ ದಾಳಿಗಳು ಎಷ್ಟು ಸರಳವೋ, ಅವುಗಳು ತಮ್ಮ ನ್ಯೂನತೆಗಳನ್ನು ಹೊಂದಿವೆ. ಮೊದಲನೆಯದಾಗಿ, ಲೋಡ್ ಅನ್ನು ರಚಿಸಲು ದೊಡ್ಡ ಪ್ರಮಾಣದ ವಿದ್ಯುತ್ ಅಗತ್ಯವಿದೆ. ಎರಡನೆಯದಾಗಿ, ಅಂತಹ ದಾಳಿಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ತುಂಬಾ ಸುಲಭ, ವಿಶೇಷವಾಗಿ ಅವರು ಒಂದು ವಿಳಾಸದಿಂದ ಬಂದಿದ್ದರೆ. ಪರಿಣಾಮವಾಗಿ, ವಿನಂತಿಗಳನ್ನು ತಕ್ಷಣವೇ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ಅಥವಾ ಪೂರೈಕೆದಾರರ ಮಟ್ಟದಲ್ಲಿ ಫಿಲ್ಟರ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ.

ಏನು ಹುಡುಕಬೇಕು

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

ಎಲ್ಲಿ ನೋಡಬೇಕು

ಪರೀಕ್ಷಿಸುವ ಮೊದಲು ನಾವು ಸಂಪನ್ಮೂಲವನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಿದಾಗ, ನಾವು ಮೊದಲು ಸೈಟ್‌ನಲ್ಲಿಯೇ ನೋಡುತ್ತೇವೆ. ನಾವು ಎಲ್ಲಾ ರೀತಿಯ ಇನ್ಪುಟ್ ಕ್ಷೇತ್ರಗಳು, ಭಾರೀ ಫೈಲ್ಗಳನ್ನು ಹುಡುಕುತ್ತಿದ್ದೇವೆ - ಸಾಮಾನ್ಯವಾಗಿ, ಸಂಪನ್ಮೂಲಕ್ಕಾಗಿ ಸಮಸ್ಯೆಗಳನ್ನು ರಚಿಸುವ ಮತ್ತು ಅದರ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಿಧಾನಗೊಳಿಸುವ ಎಲ್ಲವೂ. ಗೂಗಲ್ ಕ್ರೋಮ್ ಮತ್ತು ಫೈರ್‌ಫಾಕ್ಸ್‌ನಲ್ಲಿ ಬಾನಲ್ ಡೆವಲಪ್‌ಮೆಂಟ್ ಟೂಲ್‌ಗಳು ಇಲ್ಲಿ ಸಹಾಯ ಮಾಡುತ್ತವೆ, ಪುಟದ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ತೋರಿಸುತ್ತದೆ.
ನಾವು ಉಪಡೊಮೇನ್‌ಗಳನ್ನು ಸಹ ಸ್ಕ್ಯಾನ್ ಮಾಡುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, ಒಂದು ನಿರ್ದಿಷ್ಟ ಆನ್‌ಲೈನ್ ಸ್ಟೋರ್ ಇದೆ, abc.com, ಮತ್ತು ಇದು ಉಪಡೊಮೇನ್ admin.abc.com ಅನ್ನು ಹೊಂದಿದೆ. ಹೆಚ್ಚಾಗಿ, ಇದು ದೃಢೀಕರಣದೊಂದಿಗೆ ನಿರ್ವಾಹಕ ಫಲಕವಾಗಿದೆ, ಆದರೆ ನೀವು ಅದರ ಮೇಲೆ ಲೋಡ್ ಮಾಡಿದರೆ, ಅದು ಮುಖ್ಯ ಸಂಪನ್ಮೂಲಕ್ಕೆ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು.
ಸೈಟ್ api.abc.com ಎಂಬ ಉಪಡೊಮೇನ್ ಅನ್ನು ಹೊಂದಿರಬಹುದು. ಹೆಚ್ಚಾಗಿ, ಇದು ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಸಂಪನ್ಮೂಲವಾಗಿದೆ. ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಆಪ್ ಸ್ಟೋರ್ ಅಥವಾ ಗೂಗಲ್ ಪ್ಲೇನಲ್ಲಿ ಕಾಣಬಹುದು, ವಿಶೇಷ ಪ್ರವೇಶ ಬಿಂದುವನ್ನು ಸ್ಥಾಪಿಸಿ, API ಅನ್ನು ವಿಭಜಿಸಿ ಮತ್ತು ಪರೀಕ್ಷಾ ಖಾತೆಗಳನ್ನು ನೋಂದಾಯಿಸಿ. ಸಮಸ್ಯೆಯೆಂದರೆ ಜನರು ಸಾಮಾನ್ಯವಾಗಿ ಅಧಿಕಾರದಿಂದ ರಕ್ಷಿಸಲ್ಪಟ್ಟ ಯಾವುದಾದರೂ ಸೇವಾ ದಾಳಿಯ ನಿರಾಕರಣೆಯಿಂದ ನಿರೋಧಕವಾಗಿದೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ಪ್ರಾಯೋಜಿತವಾಗಿ, ಅಧಿಕಾರವು ಅತ್ಯುತ್ತಮ ಕ್ಯಾಪ್ಚಾ ಆಗಿದೆ, ಆದರೆ ಅದು ಅಲ್ಲ. 10-20 ಪರೀಕ್ಷಾ ಖಾತೆಗಳನ್ನು ಮಾಡುವುದು ಸುಲಭ, ಆದರೆ ಅವುಗಳನ್ನು ರಚಿಸುವ ಮೂಲಕ, ನಾವು ಸಂಕೀರ್ಣ ಮತ್ತು ವೇಷರಹಿತ ಕಾರ್ಯಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಪಡೆಯುತ್ತೇವೆ.
ನೈಸರ್ಗಿಕವಾಗಿ, ನಾವು robots.txt ಮತ್ತು WebArchive, ViewDNS ನಲ್ಲಿ ಇತಿಹಾಸವನ್ನು ನೋಡುತ್ತೇವೆ ಮತ್ತು ಸಂಪನ್ಮೂಲದ ಹಳೆಯ ಆವೃತ್ತಿಗಳನ್ನು ಹುಡುಕುತ್ತೇವೆ. ಕೆಲವೊಮ್ಮೆ ಡೆವಲಪರ್‌ಗಳು mail2.yandex.net ಅನ್ನು ಹೊರತಂದಿದ್ದಾರೆ, ಆದರೆ ಹಳೆಯ ಆವೃತ್ತಿ mail.yandex.net ಉಳಿದಿದೆ. ಈ mail.yandex.net ಇನ್ನು ಮುಂದೆ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ಅಭಿವೃದ್ಧಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಅದಕ್ಕೆ ನಿಯೋಜಿಸಲಾಗಿಲ್ಲ, ಆದರೆ ಇದು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ. ಅಂತೆಯೇ, ಹಳೆಯ ಆವೃತ್ತಿಯನ್ನು ಬಳಸಿಕೊಂಡು, ನೀವು ಬ್ಯಾಕೆಂಡ್ನ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮತ್ತು ಲೇಔಟ್ ಹಿಂದೆ ಇರುವ ಎಲ್ಲವನ್ನೂ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಳಸಬಹುದು. ಸಹಜವಾಗಿ, ಇದು ಯಾವಾಗಲೂ ಸಂಭವಿಸುವುದಿಲ್ಲ, ಆದರೆ ನಾವು ಇನ್ನೂ ಆಗಾಗ್ಗೆ ಇದನ್ನು ಎದುರಿಸುತ್ತೇವೆ.
ನೈಸರ್ಗಿಕವಾಗಿ, ನಾವು ಎಲ್ಲಾ ವಿನಂತಿಯ ನಿಯತಾಂಕಗಳನ್ನು ಮತ್ತು ಕುಕೀ ರಚನೆಯನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ. ನೀವು ಹೇಳುವುದಾದರೆ, ಒಂದು ಕುಕೀ ಒಳಗೆ JSON ಅರೇಗೆ ಕೆಲವು ಮೌಲ್ಯವನ್ನು ಡಂಪ್ ಮಾಡಬಹುದು, ಬಹಳಷ್ಟು ಗೂಡುಕಟ್ಟುವಿಕೆಯನ್ನು ರಚಿಸಬಹುದು ಮತ್ತು ಸಂಪನ್ಮೂಲವನ್ನು ಅಸಮಂಜಸವಾಗಿ ದೀರ್ಘಕಾಲ ಕೆಲಸ ಮಾಡಬಹುದು.

ಹುಡುಕಾಟ ಲೋಡ್

ಸೈಟ್ ಅನ್ನು ಸಂಶೋಧಿಸುವಾಗ ಮನಸ್ಸಿಗೆ ಬರುವ ಮೊದಲ ವಿಷಯವೆಂದರೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಲೋಡ್ ಮಾಡುವುದು, ಏಕೆಂದರೆ ಬಹುತೇಕ ಎಲ್ಲರೂ ಹುಡುಕಾಟವನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಬಹುತೇಕ ಎಲ್ಲರಿಗೂ, ದುರದೃಷ್ಟವಶಾತ್, ಅದನ್ನು ಸರಿಯಾಗಿ ರಕ್ಷಿಸಲಾಗಿಲ್ಲ. ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ, ಡೆವಲಪರ್‌ಗಳು ಹುಡುಕಾಟಕ್ಕೆ ಸಾಕಷ್ಟು ಗಮನ ಕೊಡುವುದಿಲ್ಲ. ಆದರೆ ಇಲ್ಲಿ ಒಂದು ಶಿಫಾರಸು ಇದೆ - ನೀವು ಒಂದೇ ರೀತಿಯ ವಿನಂತಿಗಳನ್ನು ಮಾಡಬಾರದು, ಏಕೆಂದರೆ ನೀವು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವಿಕೆಯನ್ನು ಎದುರಿಸಬಹುದು, HTTP ಪ್ರವಾಹದಂತೆಯೇ.
ಡೇಟಾಬೇಸ್‌ಗೆ ಯಾದೃಚ್ಛಿಕ ಪ್ರಶ್ನೆಗಳನ್ನು ಮಾಡುವುದು ಯಾವಾಗಲೂ ಪರಿಣಾಮಕಾರಿಯಾಗಿರುವುದಿಲ್ಲ. ಹುಡುಕಾಟಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಕೀವರ್ಡ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ರಚಿಸುವುದು ಉತ್ತಮವಾಗಿದೆ. ನಾವು ಆನ್ಲೈನ್ ​​ಸ್ಟೋರ್ನ ಉದಾಹರಣೆಗೆ ಹಿಂತಿರುಗಿದರೆ: ಸೈಟ್ ಕಾರ್ ಟೈರ್ಗಳನ್ನು ಮಾರಾಟ ಮಾಡುತ್ತದೆ ಮತ್ತು ಟೈರ್ಗಳ ತ್ರಿಜ್ಯ, ಕಾರಿನ ಪ್ರಕಾರ ಮತ್ತು ಇತರ ನಿಯತಾಂಕಗಳನ್ನು ಹೊಂದಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಎಂದು ಹೇಳೋಣ. ಅಂತೆಯೇ, ಸಂಬಂಧಿತ ಪದಗಳ ಸಂಯೋಜನೆಯು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಹೆಚ್ಚು ಸಂಕೀರ್ಣ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಒತ್ತಾಯಿಸುತ್ತದೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ವಿನ್ಯಾಸವನ್ನು ಬಳಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ: ಮೊದಲನೆಯದಕ್ಕಿಂತ ಹುಡುಕಾಟ ಫಲಿತಾಂಶಗಳ ಅಂತಿಮ ಪುಟವನ್ನು ಹಿಂದಿರುಗಿಸಲು ಹುಡುಕಾಟವು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿದೆ. ಅಂದರೆ, ವಿನ್ಯಾಸದ ಸಹಾಯದಿಂದ ನೀವು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಲೋಡ್ ಅನ್ನು ವೈವಿಧ್ಯಗೊಳಿಸಬಹುದು.
ಕೆಳಗಿನ ಉದಾಹರಣೆಯು ಹುಡುಕಾಟ ಲೋಡ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ. ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಹತ್ತು ವಿನಂತಿಗಳ ವೇಗದಲ್ಲಿ ಪರೀಕ್ಷೆಯ ಮೊದಲ ಸೆಕೆಂಡಿನಿಂದಲೇ ಸೈಟ್ ಕೆಳಗಿಳಿಯಿತು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯಿಸಲಿಲ್ಲ ಎಂದು ನೋಡಬಹುದು.

ಹುಡುಕಾಟವಿಲ್ಲದಿದ್ದರೆ?

ಯಾವುದೇ ಹುಡುಕಾಟವಿಲ್ಲದಿದ್ದರೆ, ಸೈಟ್ ಇತರ ದುರ್ಬಲ ಇನ್‌ಪುಟ್ ಕ್ಷೇತ್ರಗಳನ್ನು ಹೊಂದಿಲ್ಲ ಎಂದು ಇದರ ಅರ್ಥವಲ್ಲ. ಈ ಕ್ಷೇತ್ರವು ದೃಢೀಕರಣವಾಗಿರಬಹುದು. ಇತ್ತೀಚಿನ ದಿನಗಳಲ್ಲಿ, ಮಳೆಬಿಲ್ಲು ಟೇಬಲ್ ದಾಳಿಯಿಂದ ಲಾಗಿನ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ರಕ್ಷಿಸಲು ಡೆವಲಪರ್‌ಗಳು ಸಂಕೀರ್ಣ ಹ್ಯಾಶ್‌ಗಳನ್ನು ಮಾಡಲು ಬಯಸುತ್ತಾರೆ. ಇದು ಒಳ್ಳೆಯದು, ಆದರೆ ಅಂತಹ ಹ್ಯಾಶ್‌ಗಳು ಬಹಳಷ್ಟು CPU ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತವೆ. ತಪ್ಪು ಅಧಿಕಾರಗಳ ದೊಡ್ಡ ಹರಿವು ಪ್ರೊಸೆಸರ್ ವೈಫಲ್ಯಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ ಮತ್ತು ಇದರ ಪರಿಣಾಮವಾಗಿ, ಸೈಟ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.
ಕಾಮೆಂಟ್‌ಗಳು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ಎಲ್ಲಾ ರೀತಿಯ ಫಾರ್ಮ್‌ಗಳ ಸೈಟ್‌ನಲ್ಲಿನ ಉಪಸ್ಥಿತಿಯು ಅಲ್ಲಿಗೆ ದೊಡ್ಡ ಪಠ್ಯಗಳನ್ನು ಕಳುಹಿಸಲು ಅಥವಾ ಬೃಹತ್ ಪ್ರವಾಹವನ್ನು ರಚಿಸಲು ಒಂದು ಕಾರಣವಾಗಿದೆ. ಕೆಲವೊಮ್ಮೆ ಸೈಟ್‌ಗಳು gzip ಫಾರ್ಮ್ಯಾಟ್ ಸೇರಿದಂತೆ ಲಗತ್ತಿಸಲಾದ ಫೈಲ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು 1TB ಫೈಲ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ, ಅದನ್ನು ಜಿಜಿಪ್ ಬಳಸಿ ಹಲವಾರು ಬೈಟ್‌ಗಳು ಅಥವಾ ಕಿಲೋಬೈಟ್‌ಗಳಿಗೆ ಕುಗ್ಗಿಸಿ ಮತ್ತು ಅದನ್ನು ಸೈಟ್‌ಗೆ ಕಳುಹಿಸುತ್ತೇವೆ. ನಂತರ ಅದನ್ನು ಅನ್ಜಿಪ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಬಹಳ ಆಸಕ್ತಿದಾಯಕ ಪರಿಣಾಮವನ್ನು ಪಡೆಯಲಾಗುತ್ತದೆ.

ಉಳಿದ API

ರೆಸ್ಟ್ API ನಂತಹ ಜನಪ್ರಿಯ ಸೇವೆಗಳಿಗೆ ಸ್ವಲ್ಪ ಗಮನ ಕೊಡಲು ನಾನು ಬಯಸುತ್ತೇನೆ. ರೆಸ್ಟ್ API ಅನ್ನು ಸುರಕ್ಷಿತಗೊಳಿಸುವುದು ಸಾಮಾನ್ಯ ವೆಬ್‌ಸೈಟ್‌ಗಿಂತ ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿದೆ. ಪಾಸ್ವರ್ಡ್ ಬ್ರೂಟ್ ಫೋರ್ಸ್ ಮತ್ತು ಇತರ ಕಾನೂನುಬಾಹಿರ ಚಟುವಟಿಕೆಯ ವಿರುದ್ಧ ರಕ್ಷಣೆಯ ಕ್ಷುಲ್ಲಕ ವಿಧಾನಗಳು ಸಹ ಉಳಿದ API ಗಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ.
ರೆಸ್ಟ್ API ಅನ್ನು ಮುರಿಯಲು ತುಂಬಾ ಸುಲಭ ಏಕೆಂದರೆ ಅದು ನೇರವಾಗಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಅಂತಹ ಸೇವೆಯ ವೈಫಲ್ಯವು ವ್ಯವಹಾರಕ್ಕೆ ಸಾಕಷ್ಟು ಗಂಭೀರ ಪರಿಣಾಮಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ವಾಸ್ತವವೆಂದರೆ ರೆಸ್ಟ್ API ಅನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಮುಖ್ಯ ವೆಬ್‌ಸೈಟ್‌ಗೆ ಮಾತ್ರವಲ್ಲದೆ ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಕೆಲವು ಆಂತರಿಕ ವ್ಯಾಪಾರ ಸಂಪನ್ಮೂಲಗಳಿಗೂ ಬಳಸಲಾಗುತ್ತದೆ. ಮತ್ತು ಇದೆಲ್ಲವೂ ಬಿದ್ದರೆ, ಸರಳ ವೆಬ್‌ಸೈಟ್ ವೈಫಲ್ಯಕ್ಕಿಂತ ಪರಿಣಾಮವು ಹೆಚ್ಚು ಬಲವಾಗಿರುತ್ತದೆ.

ಭಾರೀ ವಿಷಯವನ್ನು ಲೋಡ್ ಮಾಡಲಾಗುತ್ತಿದೆ

ಸಂಕೀರ್ಣ ಕಾರ್ಯವನ್ನು ಹೊಂದಿರದ ಕೆಲವು ಸಾಮಾನ್ಯ ಏಕ-ಪುಟ ಅಪ್ಲಿಕೇಶನ್, ಲ್ಯಾಂಡಿಂಗ್ ಪುಟ ಅಥವಾ ವ್ಯಾಪಾರ ಕಾರ್ಡ್ ವೆಬ್‌ಸೈಟ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಲು ನಮಗೆ ಅವಕಾಶ ನೀಡಿದರೆ, ನಾವು ಭಾರೀ ವಿಷಯವನ್ನು ಹುಡುಕುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, ಸರ್ವರ್ ಕಳುಹಿಸುವ ದೊಡ್ಡ ಚಿತ್ರಗಳು, ಬೈನರಿ ಫೈಲ್ಗಳು, ಪಿಡಿಎಫ್ ದಸ್ತಾವೇಜನ್ನು - ನಾವು ಎಲ್ಲವನ್ನೂ ಡೌನ್ಲೋಡ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ಅಂತಹ ಪರೀಕ್ಷೆಗಳು ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಚೆನ್ನಾಗಿ ಲೋಡ್ ಮಾಡುತ್ತವೆ ಮತ್ತು ಚಾನಲ್ಗಳನ್ನು ಅಡ್ಡಿಪಡಿಸುತ್ತವೆ ಮತ್ತು ಆದ್ದರಿಂದ ಪರಿಣಾಮಕಾರಿಯಾಗಿರುತ್ತವೆ. ಅಂದರೆ, ನೀವು ಸರ್ವರ್ ಅನ್ನು ಹಾಕದಿದ್ದರೂ ಸಹ, ಕಡಿಮೆ ವೇಗದಲ್ಲಿ ದೊಡ್ಡ ಫೈಲ್ ಅನ್ನು ಡೌನ್ಲೋಡ್ ಮಾಡುವುದರಿಂದ, ನೀವು ಗುರಿ ಸರ್ವರ್ನ ಚಾನಲ್ ಅನ್ನು ಸರಳವಾಗಿ ಮುಚ್ಚಿಬಿಡುತ್ತೀರಿ ಮತ್ತು ನಂತರ ಸೇವೆಯ ನಿರಾಕರಣೆ ಸಂಭವಿಸುತ್ತದೆ.
ಅಂತಹ ಪರೀಕ್ಷೆಯ ಉದಾಹರಣೆಯು 30 RPS ವೇಗದಲ್ಲಿ ಸೈಟ್ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿತು ಅಥವಾ 500 ನೇ ಸರ್ವರ್ ದೋಷಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ.

ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿಸುವ ಬಗ್ಗೆ ಮರೆಯಬೇಡಿ. ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ಖರೀದಿಸಿ, ಅಲ್ಲಿ ಅಪಾಚೆಯನ್ನು ಸ್ಥಾಪಿಸಿದ್ದಾರೆ, ಎಲ್ಲವನ್ನೂ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದಾರೆ, ಪಿಎಚ್ಪಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದ್ದಾರೆ ಮತ್ತು ಕೆಳಗೆ ನೀವು ಫಲಿತಾಂಶವನ್ನು ನೋಡಬಹುದು ಎಂದು ನೀವು ಆಗಾಗ್ಗೆ ಕಾಣಬಹುದು.

ಇಲ್ಲಿ ಲೋಡ್ ಮೂಲಕ್ಕೆ ಹೋಯಿತು ಮತ್ತು ಕೇವಲ 10 RPS ನಷ್ಟಿತ್ತು. ನಾವು 5 ನಿಮಿಷ ಕಾಯುತ್ತಿದ್ದೆವು ಮತ್ತು ಸರ್ವರ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದೆ. ಅವನು ಏಕೆ ಬಿದ್ದನು ಎಂಬುದು ಸಂಪೂರ್ಣವಾಗಿ ತಿಳಿದಿಲ್ಲ ಎಂಬುದು ನಿಜ, ಆದರೆ ಅವನಿಗೆ ತುಂಬಾ ನೆನಪಿನ ಶಕ್ತಿ ಇತ್ತು ಮತ್ತು ಆದ್ದರಿಂದ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದೆ ಎಂಬ ಊಹೆ ಇದೆ.

ತರಂಗ ಆಧಾರಿತ

ಕಳೆದ ವರ್ಷ ಅಥವಾ ಎರಡು ವರ್ಷಗಳಲ್ಲಿ, ತರಂಗ ದಾಳಿಗಳು ಸಾಕಷ್ಟು ಜನಪ್ರಿಯವಾಗಿವೆ. ಅನೇಕ ಸಂಸ್ಥೆಗಳು DDoS ರಕ್ಷಣೆಗಾಗಿ ಕೆಲವು ಹಾರ್ಡ್‌ವೇರ್ ತುಣುಕುಗಳನ್ನು ಖರೀದಿಸುವುದು ಇದಕ್ಕೆ ಕಾರಣ, ದಾಳಿಯನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಲು ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ನಿರ್ದಿಷ್ಟ ಸಮಯ ಬೇಕಾಗುತ್ತದೆ. ಅಂದರೆ, ಅವರು ಮೊದಲ 30-40 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ದಾಳಿಯನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅವರು ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತಾರೆ ಮತ್ತು ಕಲಿಯುತ್ತಾರೆ. ಅಂತೆಯೇ, ಈ 30-40 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ನೀವು ಸೈಟ್‌ನಲ್ಲಿ ತುಂಬಾ ಪ್ರಾರಂಭಿಸಬಹುದು, ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ತೆರವುಗೊಳಿಸುವವರೆಗೆ ಸಂಪನ್ಮೂಲವು ದೀರ್ಘಕಾಲದವರೆಗೆ ಇರುತ್ತದೆ.
ಕೆಳಗಿನ ದಾಳಿಯ ಸಂದರ್ಭದಲ್ಲಿ, 10 ನಿಮಿಷಗಳ ಮಧ್ಯಂತರವಿತ್ತು, ಅದರ ನಂತರ ದಾಳಿಯ ಹೊಸ, ಮಾರ್ಪಡಿಸಿದ ಭಾಗವು ಆಗಮಿಸಿತು.

ಅಂದರೆ, ರಕ್ಷಣಾ ಕಲಿತು, ಫಿಲ್ಟರಿಂಗ್ ಪ್ರಾರಂಭಿಸಿದರು, ಆದರೆ ದಾಳಿಯ ಹೊಸ, ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾದ ಭಾಗವು ಬಂದಿತು ಮತ್ತು ರಕ್ಷಣಾವು ಮತ್ತೆ ಕಲಿಯಲು ಪ್ರಾರಂಭಿಸಿತು. ವಾಸ್ತವವಾಗಿ, ಫಿಲ್ಟರಿಂಗ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ರಕ್ಷಣೆ ನಿಷ್ಪರಿಣಾಮಕಾರಿಯಾಗುತ್ತದೆ ಮತ್ತು ಸೈಟ್ ಲಭ್ಯವಿಲ್ಲ.
ತರಂಗ ದಾಳಿಗಳು ಉತ್ತುಂಗದಲ್ಲಿ ಅತಿ ಹೆಚ್ಚಿನ ಮೌಲ್ಯಗಳಿಂದ ನಿರೂಪಿಸಲ್ಪಡುತ್ತವೆ, ಇದು L7 ನ ಸಂದರ್ಭದಲ್ಲಿ ಸೆಕೆಂಡಿಗೆ ಒಂದು ಲಕ್ಷ ಅಥವಾ ಒಂದು ಮಿಲಿಯನ್ ವಿನಂತಿಗಳನ್ನು ತಲುಪಬಹುದು. ನಾವು L3 & 4 ಕುರಿತು ಮಾತನಾಡಿದರೆ, ನೂರಾರು ಗಿಗಾಬಿಟ್ ಟ್ರಾಫಿಕ್ ಆಗಿರಬಹುದು ಅಥವಾ, ಅದರ ಪ್ರಕಾರ, ನೂರಾರು ಎಂಪಿಪಿಎಸ್, ನೀವು ಪ್ಯಾಕೆಟ್ಗಳಲ್ಲಿ ಎಣಿಸಿದರೆ.
ಅಂತಹ ದಾಳಿಯ ಸಮಸ್ಯೆ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಆಗಿದೆ. ದಾಳಿಗಳು ಬಾಟ್‌ನೆಟ್‌ನಿಂದ ಬರುತ್ತವೆ ಮತ್ತು ಅತಿ ದೊಡ್ಡ ಒಂದು-ಬಾರಿ ಸ್ಪೈಕ್ ಅನ್ನು ರಚಿಸಲು ಹೆಚ್ಚಿನ ಮಟ್ಟದ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅಗತ್ಯವಿರುತ್ತದೆ. ಮತ್ತು ಈ ಸಮನ್ವಯವು ಯಾವಾಗಲೂ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ: ಕೆಲವೊಮ್ಮೆ ಔಟ್ಪುಟ್ ಕೆಲವು ರೀತಿಯ ಪ್ಯಾರಾಬೋಲಿಕ್ ಪೀಕ್ ಆಗಿರುತ್ತದೆ, ಇದು ಕರುಣಾಜನಕವಾಗಿ ಕಾಣುತ್ತದೆ.

ಕೇವಲ HTTP ಅಲ್ಲ

L7 ನಲ್ಲಿ HTTP ಜೊತೆಗೆ, ನಾವು ಇತರ ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು ಬಳಸಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೇವೆ. ನಿಯಮದಂತೆ, ಸಾಮಾನ್ಯ ವೆಬ್‌ಸೈಟ್, ವಿಶೇಷವಾಗಿ ನಿಯಮಿತ ಹೋಸ್ಟಿಂಗ್, ಮೇಲ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು ಹೊಂದಿದೆ ಮತ್ತು MySQL ಅಂಟಿಕೊಂಡಿರುತ್ತದೆ. ಮೇಲ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಡೇಟಾಬೇಸ್‌ಗಳಿಗಿಂತ ಕಡಿಮೆ ಲೋಡ್‌ಗೆ ಒಳಪಟ್ಟಿರುತ್ತವೆ, ಆದರೆ ಅವುಗಳನ್ನು ಸಾಕಷ್ಟು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಲೋಡ್ ಮಾಡಬಹುದು ಮತ್ತು ಸರ್ವರ್‌ನಲ್ಲಿ ಓವರ್‌ಲೋಡ್ ಮಾಡಿದ CPU ನೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.
2016 ರ SSH ದುರ್ಬಲತೆಯನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಸಾಕಷ್ಟು ಯಶಸ್ವಿಯಾಗಿದ್ದೇವೆ. ಈಗ ಈ ದುರ್ಬಲತೆಯನ್ನು ಬಹುತೇಕ ಎಲ್ಲರಿಗೂ ಸರಿಪಡಿಸಲಾಗಿದೆ, ಆದರೆ ಇದರರ್ಥ SSH ಗೆ ಲೋಡ್ ಅನ್ನು ಸಲ್ಲಿಸಲಾಗುವುದಿಲ್ಲ ಎಂದು ಅರ್ಥವಲ್ಲ. ಮಾಡಬಹುದು. ಕೇವಲ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಅಧಿಕಾರಗಳಿವೆ, SSH ಸರ್ವರ್‌ನಲ್ಲಿನ ಸಂಪೂರ್ಣ CPU ಅನ್ನು ತಿನ್ನುತ್ತದೆ, ಮತ್ತು ನಂತರ ವೆಬ್‌ಸೈಟ್ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಒಂದು ಅಥವಾ ಎರಡು ವಿನಂತಿಗಳಿಂದ ಕುಸಿಯುತ್ತದೆ. ಅಂತೆಯೇ, ಲಾಗ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ ಈ ಒಂದು ಅಥವಾ ಎರಡು ವಿನಂತಿಗಳನ್ನು ಕಾನೂನುಬದ್ಧ ಲೋಡ್‌ನಿಂದ ಪ್ರತ್ಯೇಕಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ನಾವು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ತೆರೆಯುವ ಅನೇಕ ಸಂಪರ್ಕಗಳು ಸಹ ಪ್ರಸ್ತುತವಾಗಿರುತ್ತವೆ. ಹಿಂದೆ, ಅಪಾಚೆ ಇದಕ್ಕೆ ತಪ್ಪಿತಸ್ಥರಾಗಿದ್ದರು, ಈಗ nginx ವಾಸ್ತವವಾಗಿ ತಪ್ಪಿತಸ್ಥರಾಗಿರುತ್ತದೆ, ಏಕೆಂದರೆ ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗುತ್ತದೆ. nginx ತೆರೆದಿರಬಹುದಾದ ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆ ಸೀಮಿತವಾಗಿದೆ, ಆದ್ದರಿಂದ ನಾವು ಈ ಸಂಖ್ಯೆಯ ಸಂಪರ್ಕಗಳನ್ನು ತೆರೆಯುತ್ತೇವೆ, nginx ಇನ್ನು ಮುಂದೆ ಹೊಸ ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಇದರ ಪರಿಣಾಮವಾಗಿ ಸೈಟ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ.
ನಮ್ಮ ಪರೀಕ್ಷಾ ಕ್ಲಸ್ಟರ್ SSL ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಅನ್ನು ಆಕ್ರಮಣ ಮಾಡಲು ಸಾಕಷ್ಟು CPU ಅನ್ನು ಹೊಂದಿದೆ. ತಾತ್ವಿಕವಾಗಿ, ಅಭ್ಯಾಸ ಪ್ರದರ್ಶನಗಳಂತೆ, ಬೋಟ್ನೆಟ್ಗಳು ಕೆಲವೊಮ್ಮೆ ಇದನ್ನು ಮಾಡಲು ಬಯಸುತ್ತವೆ. ಒಂದೆಡೆ, ನೀವು SSL ಇಲ್ಲದೆ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ, ಏಕೆಂದರೆ Google ಫಲಿತಾಂಶಗಳು, ಶ್ರೇಯಾಂಕ, ಭದ್ರತೆ. ಮತ್ತೊಂದೆಡೆ, SSL ದುರದೃಷ್ಟವಶಾತ್ CPU ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿದೆ.

L3&4

ನಾವು L3&4 ಹಂತಗಳಲ್ಲಿ ದಾಳಿಯ ಕುರಿತು ಮಾತನಾಡುವಾಗ, ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಲಿಂಕ್ ಮಟ್ಟದಲ್ಲಿ ದಾಳಿಯ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ. SYN-ಪ್ರವಾಹ ದಾಳಿಯ ಹೊರತು ಅಂತಹ ಹೊರೆಯು ಯಾವಾಗಲೂ ಕಾನೂನುಬದ್ಧವಾದ ಒಂದರಿಂದ ಪ್ರತ್ಯೇಕಿಸಲ್ಪಡುತ್ತದೆ. ಭದ್ರತಾ ಪರಿಕರಗಳಿಗಾಗಿ SYN-ಪ್ರವಾಹ ದಾಳಿಯ ಸಮಸ್ಯೆಯು ಅವುಗಳ ದೊಡ್ಡ ಪರಿಮಾಣವಾಗಿದೆ. ಗರಿಷ್ಠ L3&4 ಮೌಲ್ಯವು 1,5-2 Tbit/s ಆಗಿತ್ತು. ಒರಾಕಲ್ ಮತ್ತು ಗೂಗಲ್ ಸೇರಿದಂತೆ ದೊಡ್ಡ ಕಂಪನಿಗಳಿಗೆ ಸಹ ಈ ರೀತಿಯ ದಟ್ಟಣೆಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ತುಂಬಾ ಕಷ್ಟ.
SYN ಮತ್ತು SYN-ACK ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುವಾಗ ಬಳಸಲಾಗುವ ಪ್ಯಾಕೆಟ್‌ಗಳಾಗಿವೆ. ಆದ್ದರಿಂದ, SYN-ಪ್ರವಾಹವನ್ನು ಕಾನೂನುಬದ್ಧ ಲೋಡ್‌ನಿಂದ ಪ್ರತ್ಯೇಕಿಸುವುದು ಕಷ್ಟ: ಇದು ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲು ಬಂದ SYN ಅಥವಾ ಪ್ರವಾಹದ ಭಾಗವೇ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ.

ಯುಡಿಪಿ-ಪ್ರವಾಹ

ವಿಶಿಷ್ಟವಾಗಿ, ಆಕ್ರಮಣಕಾರರು ನಮ್ಮಲ್ಲಿರುವ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿಲ್ಲ, ಆದ್ದರಿಂದ ದಾಳಿಗಳನ್ನು ಸಂಘಟಿಸಲು ವರ್ಧನೆಯು ಬಳಸಬಹುದು. ಅಂದರೆ, ಆಕ್ರಮಣಕಾರರು ಇಂಟರ್ನೆಟ್ ಅನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ದುರ್ಬಲ ಅಥವಾ ತಪ್ಪಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಸರ್ವರ್‌ಗಳನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತಾರೆ, ಉದಾಹರಣೆಗೆ, ಒಂದು SYN ಪ್ಯಾಕೆಟ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ, ಮೂರು SYN-ACK ಗಳೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ. ಟಾರ್ಗೆಟ್ ಸರ್ವರ್‌ನ ವಿಳಾಸದಿಂದ ಮೂಲ ವಿಳಾಸವನ್ನು ವಂಚಿಸುವ ಮೂಲಕ, ಒಂದೇ ಪ್ಯಾಕೆಟ್‌ನೊಂದಿಗೆ ಮೂರು ಬಾರಿ ಶಕ್ತಿಯನ್ನು ಹೆಚ್ಚಿಸಲು ಮತ್ತು ಬಲಿಪಶುಕ್ಕೆ ದಟ್ಟಣೆಯನ್ನು ಮರುನಿರ್ದೇಶಿಸಲು ಸಾಧ್ಯವಿದೆ.

ಆಂಪ್ಲಿಫಿಕೇಶನ್‌ಗಳ ಸಮಸ್ಯೆಯೆಂದರೆ ಅವುಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಕಷ್ಟ. ಇತ್ತೀಚಿನ ಉದಾಹರಣೆಗಳಲ್ಲಿ ದುರ್ಬಲ ಮೆಮ್‌ಕ್ಯಾಶ್ಡ್‌ನ ಸಂವೇದನೆಯ ಪ್ರಕರಣ ಸೇರಿದೆ. ಜೊತೆಗೆ, ಈಗ ಬಹಳಷ್ಟು IoT ಸಾಧನಗಳು, IP ಕ್ಯಾಮೆರಾಗಳು ಇವೆ, ಇವುಗಳನ್ನು ಹೆಚ್ಚಾಗಿ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಅವುಗಳನ್ನು ತಪ್ಪಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ, ಅದಕ್ಕಾಗಿಯೇ ದಾಳಿಕೋರರು ಅಂತಹ ಸಾಧನಗಳ ಮೂಲಕ ಹೆಚ್ಚಾಗಿ ದಾಳಿ ಮಾಡುತ್ತಾರೆ.

ಕಷ್ಟ SYN-ಪ್ರವಾಹ

SYN-ಪ್ರವಾಹವು ಡೆವಲಪರ್‌ನ ದೃಷ್ಟಿಕೋನದಿಂದ ಬಹುಶಃ ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ರೀತಿಯ ದಾಳಿಯಾಗಿದೆ. ಸಮಸ್ಯೆಯೆಂದರೆ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ಸಾಮಾನ್ಯವಾಗಿ ರಕ್ಷಣೆಗಾಗಿ IP ನಿರ್ಬಂಧಿಸುವಿಕೆಯನ್ನು ಬಳಸುತ್ತಾರೆ. ಇದಲ್ಲದೆ, IP ನಿರ್ಬಂಧಿಸುವಿಕೆಯು ಸ್ಕ್ರಿಪ್ಟ್ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ಮಾತ್ರವಲ್ಲದೆ, ದುರದೃಷ್ಟವಶಾತ್, ಬಹಳಷ್ಟು ಹಣಕ್ಕಾಗಿ ಖರೀದಿಸಿದ ಕೆಲವು ಭದ್ರತಾ ವ್ಯವಸ್ಥೆಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.
ಈ ವಿಧಾನವು ದುರಂತವಾಗಿ ಬದಲಾಗಬಹುದು, ಏಕೆಂದರೆ ಆಕ್ರಮಣಕಾರರು IP ವಿಳಾಸಗಳನ್ನು ಬದಲಿಸಿದರೆ, ಕಂಪನಿಯು ತನ್ನದೇ ಆದ ಸಬ್ನೆಟ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ. ಫೈರ್ವಾಲ್ ತನ್ನದೇ ಆದ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸಿದಾಗ, ಔಟ್ಪುಟ್ ಬಾಹ್ಯ ಸಂವಹನಗಳನ್ನು ವಿಫಲಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಸಂಪನ್ಮೂಲವು ವಿಫಲಗೊಳ್ಳುತ್ತದೆ.
ಇದಲ್ಲದೆ, ನಿಮ್ಮ ಸ್ವಂತ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸುವುದು ಕಷ್ಟವೇನಲ್ಲ. ಕ್ಲೈಂಟ್‌ನ ಕಛೇರಿಯು ವೈ-ಫೈ ನೆಟ್‌ವರ್ಕ್ ಹೊಂದಿದ್ದರೆ, ಅಥವಾ ಸಂಪನ್ಮೂಲಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ವಿವಿಧ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಮಾಪನ ಮಾಡಿದರೆ, ನಾವು ಈ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್ ಅಥವಾ ಕ್ಲೈಂಟ್‌ನ ಆಫೀಸ್ ವೈ-ಫೈನ ಐಪಿ ವಿಳಾಸವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಮೂಲವಾಗಿ ಬಳಸುತ್ತೇವೆ. ಕೊನೆಯಲ್ಲಿ, ಸಂಪನ್ಮೂಲವು ಲಭ್ಯವಿರುವಂತೆ ತೋರುತ್ತಿದೆ, ಆದರೆ ಗುರಿ IP ವಿಳಾಸಗಳನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ. ಹೀಗಾಗಿ, ಕಂಪನಿಯ ಹೊಸ ಉತ್ಪನ್ನವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುವ ಹೈಲೋಡ್ ಸಮ್ಮೇಳನದ ವೈ-ಫೈ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸಬಹುದು ಮತ್ತು ಇದು ಕೆಲವು ವ್ಯಾಪಾರ ಮತ್ತು ಆರ್ಥಿಕ ವೆಚ್ಚಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ.
ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ, ನಾವು ಯಾವುದೇ ಬಾಹ್ಯ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ಮೆಮ್‌ಕ್ಯಾಶ್ಡ್ ಮೂಲಕ ವರ್ಧನೆಯನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅನುಮತಿಸಲಾದ IP ವಿಳಾಸಗಳಿಗೆ ಮಾತ್ರ ಸಂಚಾರವನ್ನು ಕಳುಹಿಸಲು ಒಪ್ಪಂದಗಳಿವೆ. ಅಂತೆಯೇ, ಎರಡು ಅಥವಾ ಮೂರು SYN-ACK ಗಳೊಂದಿಗೆ ಒಂದು SYN ಅನ್ನು ಕಳುಹಿಸಲು ಸಿಸ್ಟಮ್ ಪ್ರತಿಕ್ರಿಯಿಸಿದಾಗ ನಾವು SYN ಮತ್ತು SYN-ACK ಮೂಲಕ ವರ್ಧನೆಯನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ದಾಳಿಯನ್ನು ಎರಡು ಅಥವಾ ಮೂರು ಬಾರಿ ಗುಣಿಸಲಾಗುತ್ತದೆ.

ಪರಿಕರಗಳು

L7 ಕೆಲಸದ ಹೊರೆಗಾಗಿ ನಾವು ಬಳಸುವ ಮುಖ್ಯ ಸಾಧನವೆಂದರೆ ಯಾಂಡೆಕ್ಸ್-ಟ್ಯಾಂಕ್. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ಫ್ಯಾಂಟಮ್ ಅನ್ನು ಗನ್ ಆಗಿ ಬಳಸಲಾಗುತ್ತದೆ, ಜೊತೆಗೆ ಕಾರ್ಟ್ರಿಜ್ಗಳನ್ನು ಉತ್ಪಾದಿಸಲು ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಹಲವಾರು ಸ್ಕ್ರಿಪ್ಟ್ಗಳಿವೆ.
ನೆಟ್ವರ್ಕ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ವಿಶ್ಲೇಷಿಸಲು Tcpdump ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ಸರ್ವರ್ ಅನ್ನು ವಿಶ್ಲೇಷಿಸಲು Nmap ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. L3&4 ಮಟ್ಟದಲ್ಲಿ ಲೋಡ್ ಅನ್ನು ರಚಿಸಲು, OpenSSL ಮತ್ತು DPDK ಲೈಬ್ರರಿಯೊಂದಿಗೆ ನಮ್ಮದೇ ಆದ ಮ್ಯಾಜಿಕ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. DPDK ಇಂಟೆಲ್‌ನಿಂದ ಲೈಬ್ರರಿಯಾಗಿದ್ದು ಅದು ಲಿನಕ್ಸ್ ಸ್ಟಾಕ್ ಅನ್ನು ಬೈಪಾಸ್ ಮಾಡುವ ಮೂಲಕ ನೆಟ್ವರ್ಕ್ ಇಂಟರ್ಫೇಸ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಇದರಿಂದಾಗಿ ದಕ್ಷತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ನಾವು DPDK ಅನ್ನು L3 ಮತ್ತು 4 ಮಟ್ಟದಲ್ಲಿ ಮಾತ್ರವಲ್ಲದೆ L7 ಮಟ್ಟದಲ್ಲಿಯೂ ಬಳಸುತ್ತೇವೆ, ಏಕೆಂದರೆ ಇದು ಒಂದು ಯಂತ್ರದಿಂದ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಹಲವಾರು ಮಿಲಿಯನ್ ವಿನಂತಿಗಳ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ಅತಿ ಹೆಚ್ಚು ಲೋಡ್ ಹರಿವನ್ನು ರಚಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ನಿರ್ದಿಷ್ಟ ಪರೀಕ್ಷೆಗಳಿಗಾಗಿ ನಾವು ಬರೆಯುವ ಕೆಲವು ಸಂಚಾರ ಜನರೇಟರ್‌ಗಳು ಮತ್ತು ವಿಶೇಷ ಪರಿಕರಗಳನ್ನು ಸಹ ನಾವು ಬಳಸುತ್ತೇವೆ. ನಾವು SSH ಅಡಿಯಲ್ಲಿ ದುರ್ಬಲತೆಯನ್ನು ನೆನಪಿಸಿಕೊಂಡರೆ, ಮೇಲಿನ ಸೆಟ್ ಅನ್ನು ಬಳಸಿಕೊಳ್ಳಲಾಗುವುದಿಲ್ಲ. ನಾವು ಮೇಲ್ ಪ್ರೋಟೋಕಾಲ್ ಮೇಲೆ ದಾಳಿ ಮಾಡಿದರೆ, ನಾವು ಮೇಲ್ ಉಪಯುಕ್ತತೆಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ ಅಥವಾ ಸರಳವಾಗಿ ಅವುಗಳ ಮೇಲೆ ಸ್ಕ್ರಿಪ್ಟ್ಗಳನ್ನು ಬರೆಯುತ್ತೇವೆ.

ಸಂಶೋಧನೆಗಳು

ತೀರ್ಮಾನವಾಗಿ ನಾನು ಹೇಳಲು ಬಯಸುತ್ತೇನೆ:

• ಕ್ಲಾಸಿಕ್ ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಜೊತೆಗೆ, ಒತ್ತಡ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸುವುದು ಅವಶ್ಯಕ. ಪಾಲುದಾರರ ಉಪಗುತ್ತಿಗೆದಾರರು ಲೋಡ್ ಪರೀಕ್ಷೆಯನ್ನು ಮಾತ್ರ ನಿರ್ವಹಿಸಿದ ನೈಜ ಉದಾಹರಣೆ ನಮ್ಮಲ್ಲಿದೆ. ಸಂಪನ್ಮೂಲವು ಸಾಮಾನ್ಯ ಹೊರೆಯನ್ನು ತಡೆದುಕೊಳ್ಳಬಲ್ಲದು ಎಂದು ತೋರಿಸಿದೆ. ಆದರೆ ನಂತರ ಅಸಹಜ ಲೋಡ್ ಕಾಣಿಸಿಕೊಂಡಿತು, ಸೈಟ್ ಸಂದರ್ಶಕರು ಸಂಪನ್ಮೂಲವನ್ನು ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿ ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದರು ಮತ್ತು ಇದರ ಪರಿಣಾಮವಾಗಿ ಉಪಗುತ್ತಿಗೆದಾರರು ತ್ಯಜಿಸಿದರು. ಹೀಗಾಗಿ, ನೀವು ಈಗಾಗಲೇ DDoS ದಾಳಿಯಿಂದ ರಕ್ಷಿಸಲ್ಪಟ್ಟಿದ್ದರೂ ಸಹ ದುರ್ಬಲತೆಗಳನ್ನು ಹುಡುಕುವುದು ಯೋಗ್ಯವಾಗಿದೆ.
• ಸಿಸ್ಟಮ್ನ ಕೆಲವು ಭಾಗಗಳನ್ನು ಇತರರಿಂದ ಪ್ರತ್ಯೇಕಿಸುವುದು ಅವಶ್ಯಕ. ನೀವು ಹುಡುಕಾಟವನ್ನು ಹೊಂದಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಪ್ರತ್ಯೇಕ ಯಂತ್ರಗಳಿಗೆ ಸರಿಸಬೇಕು, ಅಂದರೆ ಡಾಕರ್‌ಗೆ ಸಹ ಅಲ್ಲ. ಏಕೆಂದರೆ ಹುಡುಕಾಟ ಅಥವಾ ದೃಢೀಕರಣ ವಿಫಲವಾದರೆ, ಕನಿಷ್ಠ ಏನಾದರೂ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ. ಆನ್‌ಲೈನ್ ಸ್ಟೋರ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ, ಬಳಕೆದಾರರು ಕ್ಯಾಟಲಾಗ್‌ನಲ್ಲಿ ಉತ್ಪನ್ನಗಳನ್ನು ಹುಡುಕುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾರೆ, ಅಗ್ರಿಗೇಟರ್‌ನಿಂದ ಹೋಗುತ್ತಾರೆ, ಅವರು ಈಗಾಗಲೇ ಅಧಿಕೃತವಾಗಿದ್ದರೆ ಖರೀದಿಸುತ್ತಾರೆ ಅಥವಾ OAuth2 ಮೂಲಕ ಅಧಿಕೃತಗೊಳಿಸುತ್ತಾರೆ.
• ಎಲ್ಲಾ ರೀತಿಯ ಕ್ಲೌಡ್ ಸೇವೆಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಬೇಡಿ.
• ನೆಟ್‌ವರ್ಕ್ ವಿಳಂಬವನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡಲು ಮಾತ್ರವಲ್ಲದೆ, ಚಾನಲ್ ನಿಶ್ಯಕ್ತಿ ಮತ್ತು ಸ್ಟ್ಯಾಟಿಕ್ ಟ್ರಾಫಿಕ್‌ಗೆ ಸರಳವಾಗಿ ಪ್ರವಾಹದ ಮೇಲಿನ ದಾಳಿಯ ವಿರುದ್ಧ ರಕ್ಷಣೆಯ ಸಾಧನವಾಗಿಯೂ ಸಿಡಿಎನ್ ಅನ್ನು ಬಳಸಿ.
• ವಿಶೇಷ ರಕ್ಷಣಾ ಸೇವೆಗಳನ್ನು ಬಳಸುವುದು ಅವಶ್ಯಕ. ನೀವು ಚಾನೆಲ್ ಮಟ್ಟದಲ್ಲಿ L3&4 ದಾಳಿಯಿಂದ ನಿಮ್ಮನ್ನು ರಕ್ಷಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ನೀವು ಸಾಕಷ್ಟು ಚಾನಲ್ ಹೊಂದಿಲ್ಲದಿರಬಹುದು. ನೀವು L7 ದಾಳಿಯ ವಿರುದ್ಧ ಹೋರಾಡಲು ಅಸಂಭವವಾಗಿದೆ, ಏಕೆಂದರೆ ಅವುಗಳು ತುಂಬಾ ದೊಡ್ಡದಾಗಿರಬಹುದು. ಜೊತೆಗೆ, ಸಣ್ಣ ದಾಳಿಗಳ ಹುಡುಕಾಟವು ಇನ್ನೂ ವಿಶೇಷ ಸೇವೆಗಳು, ವಿಶೇಷ ಅಲ್ಗಾರಿದಮ್‌ಗಳ ಹಕ್ಕು.
• ನಿಯಮಿತವಾಗಿ ನವೀಕರಿಸಿ. ಇದು ಕರ್ನಲ್‌ಗೆ ಮಾತ್ರವಲ್ಲ, SSH ಡೀಮನ್‌ಗೆ ಸಹ ಅನ್ವಯಿಸುತ್ತದೆ, ವಿಶೇಷವಾಗಿ ನೀವು ಅವುಗಳನ್ನು ಹೊರಗೆ ತೆರೆದಿದ್ದರೆ. ತಾತ್ವಿಕವಾಗಿ, ಎಲ್ಲವನ್ನೂ ನವೀಕರಿಸಬೇಕಾಗಿದೆ, ಏಕೆಂದರೆ ನೀವು ಕೆಲವು ದುರ್ಬಲತೆಗಳನ್ನು ನಿಮ್ಮದೇ ಆದ ಮೇಲೆ ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಅಸಂಭವವಾಗಿದೆ.

ಮೂಲ: www.habr.com