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'
కనెక్ట్ అయ్యే ప్రతికూల సందర్భం ఒక ఆవిష్కరణ, యాదృచ్ఛికం కాదు, నియమం సరిచేయబడే వరకు దాని స్థానం మ్యాట్రిక్స్లో విఫలమైన కణం. పరీక్ష ఆదేశాలను పట్టిక పక్కన ఉంచండి, తదుపరి సమీక్షకుడు వాదనను మళ్లీ నిర్మించడం కంటే వాటిని మళ్లీ అమలు చేస్తారు.
పూర్తయిన పట్టిక తాను రాయబడిన గేట్వే కంటే ఎక్కువ కాలం జీవిస్తుంది. నియమాలు ఫర్మ్వేర్ మరియు విక్రేతతో మారుతాయి, కానీ కాంట్రాక్టర్ ఒక ప్రాజెక్ట్ సేవకు చేరుకుంటారని చెప్పే వరుస ఆ పని మారే వరకు నిజంగానే ఉంటుంది.