fail2ban ನಲ್ಲಿ ಯಾವುದೂ ತಾನಾಗಿಯೇ ಪ್ಯಾಕೆಟ್ ಬಿಡುವುದಿಲ್ಲ: ಅದು ಒಂದು ಕ್ರಿಯೆಯನ್ನು ಕರೆಯುತ್ತದೆ, ಮತ್ತು ಆ ಕ್ರಿಯೆಯೇ ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ. jail ban ವರದಿ ಮಾಡುವಾಗ ಡೀಮನ್ ಲಾಗಿನ್ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಲೇ ಇದ್ದರೆ, ಆ ban ಸಾಮಾನ್ಯವಾಗಿ ನಿಜವಾಗಿರುತ್ತದೆ ಮತ್ತು ಲಾಗ್ ಸೂಚಿಸುವುದಕ್ಕಿಂತ ಕಿರಿದಾಗಿರುತ್ತದೆ. ಇನ್ನೊಂದು ಸಾರಿಗೆಯ ಮೂಲಕ ಮತ್ತೆ ಸಂಪರ್ಕಿಸುವ ಕ್ಲೈಂಟ್ ಸ್ಥಾಪಿಸಿದ ನಿಯಮವನ್ನು ಎಂದಿಗೂ ಎದುರಿಸುವುದಿಲ್ಲ. ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಕ್ರಿಯೆ ಏನನ್ನು ಸ್ಥಾಪಿಸಿತು ಮತ್ತು ಡೀಮನ್ ಯಾವುದನ್ನು ಆಲಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಹೋಲಿಸಿ, ಏಕೆಂದರೆ ಸಾಕ್ಷ್ಯ ಕ್ರಿಯೆ ಬರೆದ ಫೈರ್ವಾಲ್ ಸರಪಳಿಯಲ್ಲಿದೆ, jail ಪಟ್ಟಿಯಲ್ಲಿ ಅಲ್ಲ.

ಸರಪಳಿಯನ್ನು ಓದಿ, jail ಸಾರಾಂಶವನ್ನಲ್ಲ

fail2ban ತನ್ನ ಸರಪಳಿಯನ್ನು ಸೇವೆಯ ಸರಪಳಿಯ ಮುಂದೆ ಸೇರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೌಂಟರ್ ಪಟ್ಟಿ ಇರುವುದನ್ನು ನಿಖರವಾಗಿ ತೋರಿಸುತ್ತದೆ. jail ನ ಹೆಸರಿನ ಸರಪಳಿಯಲ್ಲಿ ಒಂದೇ ನಿಯಮವಿದ್ದು ಅದರ ಪ್ರೋಟೋಕಾಲ್ ಕಾಲಮ್ udp ಎಂದು ಓದಿದರೆ, ಬರುತ್ತಲೇ ಇರುವ TCP ಲಾಗಿನ್ಗಳಿಗೆ ಅದು ಪೂರ್ಣ ವಿವರಣೆ. ನಿರ್ಬಂಧಿತ ಮೂಲದಿಂದ ಬರುವ UDP ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಮಾತ್ರ ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ. ಸೇವೆಗೆ TCP ಆಲಿಸುವವನಿದ್ದಾನೆ, ಮತ್ತು ಆ ಸರಪಳಿಯಲ್ಲಿ ಯಾವುದೂ ಅವನನ್ನು ಮುಟ್ಟುವುದಿಲ್ಲ.

ನೆರೆಯ jail ನ ಪರಿಣಾಮವನ್ನೂ ಗಮನಿಸಿ. ಒಂದು ಹೋಸ್ಟ್ ಸಂಪೂರ್ಣವಾಗಿ ಸಂರಚಿಸಲ್ಪಟ್ಟಂತೆ ಕಾಣಬಹುದು, ಕೇವಲ ಬೇರೆ jail ಕಾಣೆಯಾದ ಅರ್ಧವನ್ನು ಒದಗಿಸುವುದರಿಂದ, ಮತ್ತು ಅದೇ ಬಿಲ್ಡ್ ಆ jail ಸ್ಥಾಪಿತವಲ್ಲದ ಕಡೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ.

ಕ್ರಿಯೆ ಒಂದೇ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಅಲ್ಲಿಯೇ ಅದು ಮುರಿಯುತ್ತದೆ

ಪ್ರತಿ banaction ಫೈರ್ವಾಲ್ ಆದೇಶದ ಟೆಂಪ್ಲೇಟ್, ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ಅದರ ಒಂದು ಪ್ಲೇಸ್ಹೋಲ್ಡರ್ನಲ್ಲಿದೆ. ಈ ಕಿರಿದಳತೆ ಉದ್ದೇಶಪೂರ್ವಕ, ಏಕೆಂದರೆ ವೆಬ್ jail ಮತ್ತು DNS jail ಒಂದೇ ಪೋರ್ಟ್ಗಳನ್ನು ತಡೆಯುವ ಕೆಲಸ ಅವಕ್ಕಿಲ್ಲ. ಸೇವೆ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಾರಿಗೆಗಳಲ್ಲಿ ಆಲಿಸಿದಾಗ ಇದು ಬಲೆಯಾಗುತ್ತದೆ, VPN ಡೀಮನ್ಗಳು ಇದನ್ನು ನಿಯಮಿತವಾಗಿ ಮಾಡುತ್ತವೆ. ಫಿಲ್ಟರ್ ಎರಡೂ ಸಾರಿಗೆಗಳ ವಿಫಲ ಲಾಗಿನ್ಗಳನ್ನು ನೋಡಬಹುದು, ಆದರೆ ಕ್ರಿಯೆ ಒಂದನ್ನು ಮಾತ್ರ ಆವರಿಸುತ್ತದೆ.

SoftEther ಮತ್ತು OpenVPN ನಿಯೋಜನೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ UDP ಮತ್ತು TCP ಎರಡನ್ನೂ ಒಟ್ಟಿಗೆ ಆಲಿಸುತ್ತವೆ, ಮತ್ತು ಲಾಗ್ ಸಾಲು ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾಣುವುದರಿಂದ ಫಿಲ್ಟರ್ ಎರಡನ್ನೂ ನೋಡುತ್ತದೆ. ಈ ಅಸಮಮಿತಿ jail ನ ಸ್ವಂತ ವರದಿಯಲ್ಲಿ ಎಂದಿಗೂ ಕಾಣುವುದಿಲ್ಲ. fail2ban ವೈಫಲ್ಯಗಳನ್ನು ಸರಿಯಾಗಿ ಎಣಿಸಿ ನಂತರ ಆ ವೈಫಲ್ಯಗಳು ಬಂದ ಸಂಚಾರದ ಅರ್ಧಕ್ಕೆ ಅನ್ವಯವಾಗುವ ನಿಯಮವನ್ನು ಸ್ಥಾಪಿಸಿತು.

ban ಎರಡೂ ಸಾರಿಗೆಗಳನ್ನು ಆವರಿಸುವಂತೆ ಮಾಡಿ

ಅದನ್ನು 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 ಇನ್ನೂ ಯಶಸ್ವಿ ban ವರದಿ ಮಾಡುತ್ತದೆ. iptables-allports ಅಥವಾ nftables-allports ನಂತಹ ಎಲ್ಲಾ ಪೋರ್ಟ್ ಕ್ರಿಯೆ ಒಂದು ನಮೂದನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಆದರೆ ಆ ಮೂಲದ ಪ್ರತಿ ಪೋರ್ಟ್ ಅನ್ನು ತಡೆಯುತ್ತದೆ, ಅದು ಬೇರೆ ನಿರ್ಣಯ ಮತ್ತು ತನ್ನದೇ ಸಮರ್ಥನೆ ಬೇಕು. protocol ಅನ್ನು tcp ಅಥವಾ udp ನಲ್ಲೇ ಬಿಟ್ಟು ಎರಡೂ ನಮೂದುಗಳನ್ನು ಸ್ವೀಕರಿಸಿ.

ಸೆಟ್ಟಿಂಗ್ ನಂಬುವ ಬದಲು ನಿಯಮ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂದು ಸಾಬೀತು ಮಾಡಿ, ಏಕೆಂದರೆ ಸರಪಳಿ ಅದನ್ನು ಹಿಡಿಯುವವರೆಗೆ ಸೆಟ್ಟಿಂಗ್ ಕೇವಲ ಉದ್ದೇಶವನ್ನು ವಿವರಿಸುತ್ತದೆ:

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

ಪ್ರತಿ ಸರಪಳಿಯೂ ಒಂದು ನಿಯಮವನ್ನು ಪಟ್ಟಿ ಮಾಡಬೇಕು, ಮೊದಲನೆಯದರಲ್ಲಿ -p tcp ಮತ್ತು ಎರಡನೆಯದರಲ್ಲಿ -p udp, ಎರಡೂ ನಿರ್ಬಂಧಿತ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುತ್ತವೆ. ನಂತರ ಅದೇ ವಿಳಾಸ ಎರಡೂ ಸಾರಿಗೆಗಳಲ್ಲಿ ತಿರಸ್ಕೃತವಾಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಸರಪಳಿಯಲ್ಲಿ ಕಾಣದ ban ಒಂದು ನಿರೀಕ್ಷೆ, ಮತ್ತು ಅದೇ ಲಕ್ಷಣದ ಮುಂದಿನ ವರದಿ ಮತ್ತೆ ಅದೇ ಗಂಟೆಯನ್ನು ವ್ಯಯಿಸುತ್ತದೆ.

ban ಇನ್ನೂ ಏನನ್ನು ತಪ್ಪಿಸುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ಪ್ರಕರಣ

ಕ್ರಿಯೆ ಮಾಡುವುದು ಒಂದೇ ಮೂಲವನ್ನು ತಿರಸ್ಕರಿಸುವುದು, ಮತ್ತು ಅದರಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡಿದ ಪೋರ್ಟ್ಗಳಲ್ಲಿ ಮಾತ್ರ. ವಿಳಾಸಗಳನ್ನು ಬದಲಿಸುವ ಆಕ್ರಮಣಕಾರನ ವಿರುದ್ಧ ಅದು ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ನೂರಾರು ಬಳಕೆದಾರರು ಹಂಚಿಕೊಳ್ಳುವ ವಾಹಕ ಮಟ್ಟದ NAT ನಿರ್ಗಮನದಿಂದ ವೈರಿ ಯಂತ್ರವನ್ನು ಬೇರ್ಪಡಿಸಲಾರದು, ಅಲ್ಲಿ ಒಂದು ban ಏನನ್ನೂ ಮಾಡದ ಜನರನ್ನು ಹೊರಗಿಡುತ್ತದೆ. ಫಿಲ್ಟರ್ ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಹೊಂದಿರುವ ವಿಳಾಸವನ್ನು ಓದುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಮುಂದಕ್ಕೆ ರವಾನಿಸಿದ ಹೆಡರ್ ಅಥವಾ ಪ್ರಾಕ್ಸಿ ವಿಳಾಸವನ್ನಲ್ಲ. ತಪ್ಪು ತಾನಾಗಿಯೇ ಮುಗಿಯುವಂತೆ ಕಿಟಕಿಯನ್ನು ಸಾಕಷ್ಟು ಚಿಕ್ಕದಾಗಿ ಇರಿಸಿ.

ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಪ್ರೋಟೋಕಾಲ್ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಬಿಟ್ಟುಬಿಡಲು ವಾದಿಸುವುದಿಲ್ಲ; ಅದು ಎರಡು ಕಲ್ಪನೆಗಳನ್ನು ಒಟ್ಟಿಗೆ ಹಿಡಿದಿಡಲು ವಾದಿಸುತ್ತದೆ. ban jail ಸಾರಾಂಶ ಸೂಚಿಸುವುದಕ್ಕಿಂತ ಕಿರಿದು, ಮತ್ತು ಪೂರ್ಣ ban ಸಹ ಬೆದರಿಕೆಗಿಂತ ಕಿರಿದು. ಫೈರ್ವಾಲ್ ಸರಪಳಿಯನ್ನು ಡೀಮನ್ನ ಆಲಿಸುವವರ ಪಟ್ಟಿಯ ಪಕ್ಕದಲ್ಲಿ ಇರಿಸಿ ಪ್ರೋಟೋಕಾಲ್ ಪ್ರೋಟೋಕಾಲ್ ಹೋಲಿಸಿ, ಏಕೆಂದರೆ ban ಸೇವೆಯನ್ನು ತಲುಪಬಹುದೇ ಇಲ್ಲವೇ ಎಂಬುದನ್ನು ಆ ಎರಡು ಪಟ್ಟಿಗಳೇ ನಿರ್ಧರಿಸುತ್ತವೆ.

ಮರುಲೋಡ್ ಆದೇಶ ಮತ್ತು ಸರಪಳಿ ಪಟ್ಟಿಯನ್ನು jail ಪಕ್ಕದ ರನ್ಬುಕ್ನಲ್ಲಿ ಇರಿಸಿ. ಮುಂದಿನ ವ್ಯಕ್ತಿಗೆ ಎರಡೂ ಬೇಕಾಗುತ್ತವೆ, ಮತ್ತು jail ಸಾರಾಂಶ ಅವನಿಗೆ ಒಂದನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು