NEW ಮಾತ್ರ ಇರುವ ಫೈರ್ವಾಲ್ ನಿಯಮಗಳು ಎಲ್ಲಾ WAN ಮಾರ್ಗವನ್ನು ಮುಚ್ಚುವುದಿಲ್ಲ

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

ಸ್ಥಿತಿ ಒಂದು ಹೊಂದಾಣಿಕೆಯ ಷರತ್ತು, ತೀರ್ಪಲ್ಲ

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

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

ನಿಯಮವನ್ನು ಅದರ ಪರಿಸರದಲ್ಲಿ ಓದಿ

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

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

ಕೌಂಟರ್ಗಳು ಯಾವ ನಿಯಮ ನಿಜವಾಗಿ ಹೊಂದಿಕೆಯಾಯಿತು ಎಂದು ಹೇಳುತ್ತವೆ, ಮತ್ತು ಅವು ಸಾಮಾನ್ಯವಾಗಿ ನಿರ್ಧಾರದ ನಂತರ ತೆಗೆದ ಪ್ಯಾಕೆಟ್ ಕ್ಯಾಪ್ಚರ್ಗಿಂತ ಹೆಚ್ಚು ಮಾಹಿತಿಪೂರ್ಣ. ಶೂನ್ಯ ಕೌಂಟರ್ ಇರುವ ನಿಯಮವನ್ನು ತಲುಪಿಲ್ಲ, ಅದರ ಸ್ಥಾನ ಏನೇ ಸೂಚಿಸಿದರೂ.

ನಿಷೇಧವನ್ನು ಸ್ಥಿತಿಯಿಂದ ಸ್ವತಂತ್ರವಾಗಿ ವ್ಯಕ್ತಪಡಿಸಿ

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

drop ಬದಲು reject ಆಯ್ಕೆ ಮಾಡುವುದು ಹೊಂದಿಕೆಯಾದ ಸಂಚಾರ ಹೇಗೆ ವಿಫಲವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ನಿಯಮ ಆಯ್ಕೆ ಮಾಡುವ ಪ್ಯಾಕೆಟ್ಗಳ ಗುಂಪನ್ನು ವಿಸ್ತರಿಸುವುದಿಲ್ಲ. ತಿರಸ್ಕರಿಸಿದ ಸಂಪರ್ಕ ಮತ್ತು ಮೌನ ಕಾಲಮಿತಿ ಒಂದೇ ಆಯ್ಕೆಯನ್ನು ಸೂಚಿಸುವ ಬೇರೆ ಬೇರೆ ಲಕ್ಷಣಗಳು.

WAN ಮೇಲೆ ದೂರದಿಂದ ಪ್ರಾರಂಭವಾದ ಪ್ರವೇಶಕ್ಕೆ ಉತ್ತರಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅನುಮತಿಸುವ ನೀತಿ ಸಮರ್ಥನೀಯ. ಅದನ್ನು ಸುರಂಗದ ಮೂಲಕ ಮಾತ್ರ ಸಂಪೂರ್ಣ ಪ್ರತ್ಯೇಕತೆ ಎಂದು ಪ್ರಸ್ತುತಪಡಿಸುವ ಬದಲು ಹಾಗೆಯೇ ವಿವರಿಸಬೇಕು.

ಗುಂಪಿನಲ್ಲಿ ನಿಜವಾಗಿ ಯಾರಿದ್ದಾರೆ ಎಂದು ಪರಿಶೀಲಿಸಿ

ಉದಾಹರಣೆ ಒಂದು ಇಂಟರ್ಫೇಸ್ನಿಂದ ಒಂದು ಪೂರ್ವಪ್ರತ್ಯಯದ ಮುಂದೂಡಲಾದ IPv4 ಸಂಚಾರವನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ. ಅದು IPv6, ಎರಡನೇ ಅಪ್ಲಿಂಕ್, ಅಥವಾ ರೌಟರ್ ಸ್ವತಃ ಸೃಷ್ಟಿಸುವ ಸಂಚಾರದ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ. DNS ಪರಿಹಾರಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ರೌಟರ್ ತನ್ನದೇ ಮೇಲ್ಮುಖ ಪ್ರಶ್ನೆಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಅವು forward ಸರಪಳಿಯ ಮೂಲಕವೇ ಹೋಗುವುದಿಲ್ಲ.

ರಕ್ಷಿತ ಕ್ಲೈಂಟ್ಗಳು ಇನ್ನೂ ಆಯ್ಕೆ ಮಾಡಿದ ಪೂರ್ವಪ್ರತ್ಯಯದ ಒಳಗೆ ವಿಳಾಸಗಳನ್ನು ಹೊಂದಿವೆ ಎಂದು ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ಅದರಿಂದ ಹೊರಗೆ ಹೋದ ಸಾಧನ ನೀತಿಯ ಪ್ರಕಾರವಲ್ಲ, ಆಕಸ್ಮಿಕವಾಗಿ ನೇರವಾಗಿದೆ. ವಿನಾಯಿತಿಗಳ ವಿನ್ಯಾಸವನ್ನು ಪರಿಶೀಲಿಸದೆ ನಿರ್ಬಂಧವನ್ನು ಇಡೀ LAN ಗೆ ವಿಸ್ತರಿಸುವುದು ನಿಮ್ಮದೇ ಆಡಳಿತ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

ನಂತರ ಹಳೆಯ ಹರಿವನ್ನು ಹೊಸದರ ಪಕ್ಕದಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ. ಹೊಸ ಸಂಪರ್ಕ ಪ್ರಯತ್ನ ಮತ್ತು ಈಗಾಗಲೇ ಸಕ್ರಿಯವಾದ ದ್ವಿಮುಖ ವರ್ಗಾವಣೆ ಈ ನಿಯಮದ ಅಡಿಯಲ್ಲಿ ಬೇರೆ ರೀತಿ ವರ್ತಿಸುತ್ತವೆ, ಮತ್ತು ಎರಡನ್ನೂ ಪರೀಕ್ಷಿಸಿದಾಗ ಮಾತ್ರ ನಿಜವಾಗಿ ಯಾವ ನೀತಿ ಇದೆ ಎಂದು ತಿಳಿಯುತ್ತದೆ.