VPN ನಿಂದ VLAN ಗೆ ಪ್ರವೇಶ: ನಿಯಮಗಳ ಮೊದಲು ಮ್ಯಾಟ್ರಿಕ್ಸ್ ನಿರ್ಮಿಸಿ
ಒಂದು ಬದಿಯಲ್ಲಿ ಪಾತ್ರಗಳು, ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ ಸೇವೆಗಳು. ಐದು ಪರಿಶೀಲನೆಗಳು ಅಸ್ಪಷ್ಟ VPN-ಗಳಿಂದ-VLAN ಪ್ರವೇಶ ವಿನ್ಯಾಸವನ್ನು ಫೈರ್ವಾಲ್ ಮಾಲೀಕರು ಜಾರಿಗೊಳಿಸಬಹುದಾದ ಕೋಷ್ಟಕವಾಗಿ ಬದಲಿಸುತ್ತವೆ.
ಫೈರ್ವಾಲ್ ಸಿಂಟ್ಯಾಕ್ಸ್ನಿಂದ ಅಲ್ಲ, ಮ್ಯಾಟ್ರಿಕ್ಸ್ನಿಂದ ಪ್ರಾರಂಭಿಸಿ. ಒಂದು ಬದಿಯಲ್ಲಿ ಪಾತ್ರಗಳು ಮತ್ತು ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ ಸೇವೆಗಳಿರುವ ಕೋಷ್ಟಕವನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಮಾಲೀಕರು ಪರಿಶೀಲಿಸಬಹುದು, ಭದ್ರತಾ ಮಾಲೀಕರು ಚರ್ಚಿಸಬಹುದು ಮತ್ತು ಗೇಟ್ವೇ ಹೊಂದಿರುವ ಯಾರಾದರೂ ಜಾರಿಗೊಳಿಸಬಹುದು. ಯಾರೂ ಒಪ್ಪದ ನಿಯಮಗಳನ್ನು ಡೀಬಗ್ ಮಾಡುವುದಕ್ಕಿಂತ ಆ ಪರಿಶೀಲನೆ ಅಗ್ಗವಾಗಿದೆ.
ಅದನ್ನು ಬರೆಯುವ ಒಂದು ಗಂಟೆ ನಂತರ ಒಂದು ವಾರದ ನಿಯಮ-ಪುರಾತತ್ತ್ವ ಶಾಸ್ತ್ರವನ್ನು ಉಳಿಸುತ್ತದೆ. ವಿನ್ಯಾಸವು ಯಾರು ಯಾವ ಸೇವೆಗೆ ತಲುಪುತ್ತಾರೆ ಎಂಬುದನ್ನು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಮರುಸಂಖ್ಯೀಕರಣದ ನಂತರ ಉಳಿಯುವ ಭಾಗ ಅದೇ.
ಹಂತ 1: ನೆಟ್ವರ್ಕ್ಗಳ ಮೊದಲು ಪಾತ್ರಗಳಿಗೆ ಹೆಸರಿಸಿ
ಸ್ವಿಚ್ನಿಂದ ಅಲ್ಲ, ಜನರಿಂದ ಪ್ರಾರಂಭಿಸಿ. ದೂರದಿಂದ ಸಂಪರ್ಕಿಸುವ ಪ್ರತಿಯೊಂದು ಗುಂಪನ್ನು ಮತ್ತು ಆ ಗುಂಪು ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುವ ಒಂದೇ ವಾಕ್ಯವನ್ನು ಬರೆಯಿರಿ, ಉದಾಹರಣೆಗೆ ದಾಸ್ತಾನು ಮಟ್ಟವನ್ನು ಓದುವ ಗೋದಾಮು ಸಿಬ್ಬಂದಿ ಅಥವಾ ಒಂದು ಏಕೀಕರಣವನ್ನು ನಿರ್ವಹಿಸುವ ಗುತ್ತಿಗೆದಾರ. ಎರಡು ಗುಂಪುಗಳಿಗೆ ಒಂದೇ ರೀತಿಯ ಪ್ರವೇಶ ಸಿಗುತ್ತಿದ್ದರೆ, ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ ಅವು ಒಂದೇ ಪಾತ್ರ.
ಪಾತ್ರವು ಸಂಸ್ಥಾ-ಚಾರ್ಟ್ನಿಂದ ಮಾತ್ರ ಇದ್ದರೆ ಇಲ್ಲಿಯೇ ನಿಲ್ಲಿಸಿ. ತನ್ನದೇ ಆದ ಸೇವಾ ಅಗತ್ಯವಿಲ್ಲದ ಪಾತ್ರವು ಒಂದೇ ರೀತಿಯ ಜೀವಕೋಶಗಳ ಸಾಲಾಗುತ್ತದೆ, ಮತ್ತು ಒಂದೇ ರೀತಿಯ ಸಾಲುಗಳು ನಂತರ ಅನುಕೂಲಕ್ಕಾಗಿ ಇಡೀ ಉಪಜಾಲವನ್ನು ನೀಡಲು ಯಾರನ್ನಾದರೂ ಪ್ರೇರೇಪಿಸುತ್ತವೆ. ಜನರು ಏನು ಮಾಡುತ್ತಾರೆ ಎಂಬುದರ ಆಧಾರದಲ್ಲಿ ವಿಭಜಿಸಿ, ಅವರ ಖರ್ಚಿಗೆ ಯಾರು ಸಹಿ ಹಾಕುತ್ತಾರೆ ಎಂಬುದರಿಂದ ಅಲ್ಲ. ಸಣ್ಣ ಕಚೇರಿಗೆ ಆರು ಪಾತ್ರಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಹೆಚ್ಚು ಮತ್ತು ಮೂರು ಹೆಚ್ಚಾಗಿ ಸರಿ.
ಹಂತ 2: ಪ್ರತಿ ಜೀವಕೋಶವನ್ನು ಸೇವಾ ಹೇಳಿಕೆಯಾಗಿ ಪರಿವರ್ತಿಸಿ
«ಅಪ್ಲಿಕೇಶನ್ಗಳು» ಎಂದು ಬರೆದಿರುವ ಜೀವಕೋಶವನ್ನು ಪರೀಕ್ಷಿಸಲಾಗದು. «ಸಿಬ್ಬಂದಿ ಪೂಲ್ನಿಂದ 443 ರಂದು ERP ಹೋಸ್ಟ್ಗೆ HTTPS» ಎಂದು ಬರೆದಿರುವ ಜೀವಕೋಶವನ್ನು ಪರೀಕ್ಷಿಸಬಹುದು. ಪ್ರತಿ ನೆಟ್ವರ್ಕ್ ಹೆಸರನ್ನು ಗಮ್ಯಸ್ಥಾನ, ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಪೋರ್ಟ್ನಿಂದ ಬದಲಿಸಿ, ನಂತರ ಸೇವೆ ಇಲ್ಲದೆ ನಡೆಯಲಾಗದ ಅವಲಂಬನೆಯನ್ನು ಸೇರಿಸಿ, ಉದಾಹರಣೆಗೆ ಆಂತರಿಕ ಪರಿಹಾರಕ ಅಥವಾ ಗುರುತಿನ ಪೂರೈಕೆದಾರ.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
ದಿಕ್ಕಿನ ಕಾಲಮ್ ಅತ್ಯಂತ ದುಬಾರಿ ತಪ್ಪುಗಳನ್ನು ಹಿಡಿಯುತ್ತದೆ. ಸಿಬ್ಬಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ತೆರೆಯಲು ಅನುಮತಿ ಎಂದರೆ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ಗಳು ಸಿಬ್ಬಂದಿಯ ಲ್ಯಾಪ್ಟಾಪ್ಗಳಿಗೆ ಹಿಂತಿರುಗಿ ಸಂಪರ್ಕಗಳನ್ನು ತೆರೆಯಲು ಅನುಮತಿ ಎಂದಲ್ಲ, ಮತ್ತು ಮೊದಲ ದಿಕ್ಕನ್ನು ಅನುಮತಿಸುವ ಸ್ಥಿತಿಯುಳ್ಳ ನಿಯಮವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಎರಡನೆಯದನ್ನೂ ಅನುಮತಿಸಿದಂತೆ ಓದಲಾಗುತ್ತದೆ.
ಹಂತ 3: ಗುರುತು ಎಲ್ಲಿ ನೀತಿಯಾಗುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ
ಯಾರಾದರೂ ದೃಢೀಕೃತ ಅವಧಿಯನ್ನು ಗೇಟ್ವೇ ಜಾರಿಗೊಳಿಸಬಹುದಾದ ಪಾತ್ರವಾಗಿ ಪರಿವರ್ತಿಸಬೇಕು. ಬೆಂಬಲಿತ ಆಯ್ಕೆಗಳಲ್ಲಿ ದೃಢೀಕರಣ ಬ್ಯಾಕೆಂಡ್ ಒದಗಿಸುವ ಗುಂಪು ನೀತಿ, ವಿಶ್ವಾಸಾರ್ಹ ಅವಧಿ ಗುಣಲಕ್ಷಣಗಳು, ಅಥವಾ ಪ್ರತಿ ಪಾತ್ರಕ್ಕೆ ಪ್ರತ್ಯೇಕ ವಿಳಾಸ ಪೂಲ್ಗಳು ಸೇರಿವೆ. ಮೂರೂ ಕೆಲಸ ಮಾಡುತ್ತವೆ; ಕ್ಲೈಂಟ್ ಕಳುಹಿಸುವ ಲೇಬಲ್ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ನಿಮ್ಮ ಗೇಟ್ವೇ ದಾಖಲಿಸುವ ವಿಧಾನವನ್ನು ಆರಿಸಿ, ಫೋರಮ್ ಪೋಸ್ಟ್ ವಿವರಿಸುವುದನ್ನು ಅಲ್ಲ.
VLANಗೆ ಸೇರಿದಂತೆ ಮಾತ್ರ ಕಾಣುವ ವಿಳಾಸವನ್ನು ನೀಡುವುದು ಬೇರೆ ಉಡುಪಿನಲ್ಲಿನ ಅದೇ ಉತ್ತರವಿಲ್ಲದಿರುವಿಕೆ. OpenVPN ಫೈರ್ವಾಲ್ ನಿಯಮಗಳ ಕುರಿತು Netgate ಮಾರ್ಗದರ್ಶಿ ಈ ವಿಭಜನೆಯನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ: ಸುರಂಗ ಏಳಲು ಬಿಡುವುದು ಅದರ ಮೂಲಕ ಸಂಚಾರ ಹೋಗಲು ಬಿಡುವುದಕ್ಕಿಂತ ಬೇರೆ ನಿರ್ಣಯ.
ನೀವು ಯಾವ ವಿಧಾನವನ್ನು ಆರಿಸಿದಿರಿ ಮತ್ತು ಅದು ಎಲ್ಲಿ ಸಂರಚಿಸಲಾಗಿದೆ ಎಂದು ಬರೆಯಿರಿ. ಪಾತ್ರ ಬದಲಾದಾಗ, ಆ ಟಿಪ್ಪಣಿಯೇ ಒಂದು ಸಂಪಾದನೆ ಮತ್ತು ಮೂರು ಇಂಟರ್ಫೇಸ್ಗಳಲ್ಲಿ ಹುಡುಕಾಟದ ನಡುವಿನ ವ್ಯತ್ಯಾಸ. ಅದು ಲೆಕ್ಕಪರಿಶೋಧಕರಿಗೆ ಮೊದಲು ಎಲ್ಲಿ ನೋಡಬೇಕೆಂದೂ ಹೇಳುತ್ತದೆ.
ಹಂತ 4: ಗಮ್ಯಸ್ಥಾನ ನೋಡುವ ಮೂಲ ವಿಳಾಸವನ್ನು ಗಮನಿಸಿ
ಗಡಿಯಲ್ಲಿ ಫಾರ್ವರ್ಡಿಂಗ್ ನೀತಿಯು ನಿಜವಾದ ಮೂಲಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು. ಗೇಟ್ವೇ VPN ಕ್ಲೈಂಟ್ಗಳನ್ನು ತನ್ನದೇ ವಿಳಾಸಕ್ಕೆ ಅನುವಾದಿಸಿದರೆ, ಕೆಳಗಿನ ಪ್ರತಿ ಫೈರ್ವಾಲ್ ಒಂದೇ ಮೂಲವನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು ಪಾತ್ರದ ಪ್ರಕಾರ ನಿರ್ಣಯಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ. ಅದು ಕ್ಲೈಂಟ್ನ ವಿಳಾಸವನ್ನು ಉಳಿಸಿಕೊಂಡರೆ, ಆ ಪೂಲ್ಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಇರಬೇಕು.
ಅಂತಿಮ ನಿಯಮಗಳನ್ನು ಬರೆಯುವ ಮೊದಲು ಎರಡೂ ದಿಕ್ಕುಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ, ನಂತರ ಗಮನಿಸಿದ ಮೂಲವನ್ನು ಪ್ರತಿ ಜೀವಕೋಶದ ಪಕ್ಕದಲ್ಲಿ ದಾಖಲಿಸಿ. ಅದೇ ಪರಿಶೀಲನೆಯನ್ನು ಎರಡು ಬೇರೆ ಪಾತ್ರಗಳಿಂದ ನಡೆಸಿ ಫಲಿತಾಂಶವನ್ನು ಹೋಲಿಸಿ. ಎರಡೂ ಗೇಟ್ವೇ ವಿಳಾಸವನ್ನು ತೋರಿಸಿದರೆ, ಪಾತ್ರಗಳ ವ್ಯತ್ಯಾಸ ಈಗಾಗಲೇ ಕಳೆದುಹೋಗಿದೆ. ಗೇಟ್ವೇ ಮೂಲ ಅನುವಾದ ಮಾಡುತ್ತಿರುವಾಗ ಉಳಿಸಿದ ವಿಳಾಸಗಳನ್ನು ಊಹಿಸುವ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಮೊದಲ ಕೆಳಗಿನ ACLನಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ.
ಹಂತ 5: ಬಿಡುಗಡೆ ಮಾಡುವ ಮೊದಲು ಪ್ರತಿ ಜೀವಕೋಶವನ್ನು ಪರೀಕ್ಷಿಸಿ
ಪ್ರತಿ ಅನುಮತಿಸಿದ ಜೀವಕೋಶವನ್ನು ಒಂದು ಪ್ರಾತಿನಿಧಿಕ ಕಾರ್ಯಾಚರಣೆಯಾಗಿ ಮತ್ತು ಪ್ರತಿ ನಿರಾಕರಿಸಿದ ಜೀವಕೋಶವನ್ನು ಋಣಾತ್ಮಕ ಪ್ರಕರಣವಾಗಿ ಪರಿವರ್ತಿಸಿ. ಎರಡನ್ನೂ ನಿಜವಾದ ಪಾತ್ರದಲ್ಲಿರುವ ಕ್ಲೈಂಟ್ನಿಂದ ನಡೆಸಿ, ಗೇಟ್ವೇ ಕನ್ಸೋಲ್ನಿಂದ ಅಲ್ಲ, ಏಕೆಂದರೆ ಕನ್ಸೋಲ್ ನೀವು ಪರೀಕ್ಷಿಸುತ್ತಿರುವ ಮಾರ್ಗವನ್ನು ಬೈಪಾಸ್ ಮಾಡುತ್ತದೆ.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'ಸಂಪರ್ಕಗೊಳ್ಳುವ ಋಣಾತ್ಮಕ ಪ್ರಕರಣವು ಒಂದು ಕಂಡುಹಿಡಿಯುವಿಕೆ, ಕಾಕತಾಳೀಯವಲ್ಲ, ಮತ್ತು ನಿಯಮ ಸರಿಪಡಿಸುವವರೆಗೆ ಅದರ ಸ್ಥಾನ ಮ್ಯಾಟ್ರಿಕ್ಸ್ನಲ್ಲಿ ವಿಫಲ ಜೀವಕೋಶವಾಗಿದೆ. ಪರೀಕ್ಷಾ ಆಜ್ಞೆಗಳನ್ನು ಕೋಷ್ಟಕದ ಪಕ್ಕದಲ್ಲಿ ಇರಿಸಿ, ಮುಂದಿನ ಪರಿಶೀಲಕರು ತರ್ಕವನ್ನು ಮತ್ತೆ ಕಟ್ಟುವ ಬದಲು ಅವನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಲಿ.
ಪೂರ್ಣಗೊಂಡ ಕೋಷ್ಟಕವು ತಾನು ಬರೆಯಲಾದ ಗೇಟ್ವೇಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬದುಕುತ್ತದೆ. ನಿಯಮಗಳು ಫರ್ಮ್ವೇರ್ ಮತ್ತು ಮಾರಾಟಗಾರರೊಂದಿಗೆ ಬದಲಾಗುತ್ತವೆ, ಆದರೆ ಗುತ್ತಿಗೆದಾರನು ಒಂದು ಯೋಜನೆ ಸೇವೆಗೆ ತಲುಪುತ್ತಾನೆ ಎಂದು ಹೇಳುವ ಸಾಲು ಆ ಕೆಲಸ ಬದಲಾಗುವವರೆಗೆ ನಿಜವಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ.