Windows VPN સખત કરવું: ટનલ પહેલાં પ્રમાણીકરણ સુધારો

તમારો Windows VPN સર્વર વપરાશકર્તાનામ અને પાસવર્ડ માંગે છે, અને એ એક જ સંવાદ ત્રણ અસંબંધિત ફરજો છુપાવે છે. એક સાબિત કરે છે કે વ્યક્તિ કોણ છે, એક અટકાવે છે કે તાર પર નજર રાખનાર કોઈ એ સાબિતી ફરી વાપરે, અને એક નક્કી કરે છે કે પછી કયા સરનામાં સુધી પહોંચી શકે. મોટા ભાગની નાની ગોઠવણો પહેલાં ટનલ સખત કરે છે અને પ્રથમ બે ફરજો તેમના મૂળભૂત મૂલ્યો પર છોડી દે છે, જે ખોટો ક્રમ છે.

હુમલાવીર જે ક્રમમાં કામ કરે તે ક્રમમાં કામ કરો. પહેલાં જે તાર પરથી પકડી શકાય. પછી જે તે રેકોર્ડિંગ સાથે પછી ફરી ચલાવી શકાય. અંતે, પ્રમાણિત હુમલાવીર અંદર પહોંચ્યા પછી જે સુધી પહોંચી શકે.

ત્રણ ફરજો, એક સંવાદ

ઓળખ એ ભાગ છે જેના વિશે લોકો વિચારે છે, અને તે સમસ્યાનો માત્ર એક ત્રીજા ભાગ છે. ઓળખની સાબિતીએ એવા નિરીક્ષક સામે ટકવું પડે જે આદાનપ્રદાન રેકોર્ડ કરે અને પછી ફરી પ્રયાસ કરે. અધિકૃતિ એ અલગ નિર્ણય છે જે સર્વર ઓળખ નક્કી થયા પછી લે છે, અને Windows તેને ઓળખપત્રોની ચકાસણી કરતી સેવાથી અલગ સેવામાં રાખે છે.

જ્યારે ત્રણેય એક જ માનસિક ડોલમાં રહે છે, ત્યારે સામાન્ય પરિણામ એ સર્વર હોય છે જે મજબૂત પ્રમાણીકરણ કરે અને પછી વપરાશકર્તાને બધું જ પહોંચવા દે. તેને પછી સુધારવું હવે નીતિ નક્કી કરવા કરતાં વધુ અઘરું છે, કારણ કે ત્યાં સુધીમાં ફાયરવોલ પ્રોફાઇલ, સરનામાં પૂલ અને માર્ગો બધા જૂની ધારણાને કોડ કરી ચૂક્યા હોય છે.

કોઈપણ સેટિંગને સ્પર્શ કરતાં પહેલાં ત્રણેયને તમારી નોંધમાં અલગ કરો, પછી તેમને સૌથી નબળી કડીથી ઉપર તરફ સુધારો.

MS-CHAPv2 પુનઃપ્રસ્તુતિ પરીક્ષણ કેમ ટકી શકતું નથી

જો સર્વર હજી MS-CHAPv2 સાથે PPTP સ્વીકારે છે, તો ટનલ પાસવર્ડને કોઈ અર્થપૂર્ણ રીતે સુરક્ષિત કરતું નથી. પડકાર અને પ્રતિસાદ પકડી શકાય છે અને ઑફલાઇન હુમલો કરી શકાય છે, અને 2012માં એક જાહેર ક્રેકિંગ સેવાએ સામાન્ય પાસવર્ડ માટે આવા હેન્ડશેકમાંથી લગભગ એક દિવસમાં પુનઃપ્રાપ્તિ દર્શાવી. લાંબો અને વધુ જટિલ પાસવર્ડ ખર્ચ વધારે છે; તે હુમલાવીરને નેટવર્કથી જે સામગ્રી જોઈએ છે તે દૂર કરતું નથી.

તમે જે ગુણધર્મ ઇચ્છો છો તે એવું ઓળખપત્ર છે જે ફરી ચલાવી શકાય નહીં. ક્લાઇન્ટ પ્રમાણપત્રો સાથે EAP-TLS દરેક ઉપકરણને તેની પોતાની ઓળખ આપે છે અને તમને બરાબર એક ઉપકરણ રદ કરવા દે છે.

પ્રમાણપત્રોની તૈનાતી સાચું કામ છે: ખાનગી CA, ક્લાઇન્ટ ચકાસે એવો રદ્દીકરણ માર્ગ, અને કર્મચારી બદલાવ ટકી રહે એવી નવીકરણ યોજના. એ કામને પ્રોજેક્ટ તરીકે લો, તમારા અને કાર્યરત ટનલ વચ્ચેના અવરોધ તરીકે નહીં. તેના માટે એમ બજેટ રાખો જેમ ફાયરવોલ બદલવા માટે રાખો. વહેંચાયેલો પાસવર્ડ ફક્ત પહેલા રદ્દીકરણ સુધી સસ્તો છે.

પૂર્વ-શેર કરેલી કી જોડીને પ્રમાણિત કરે છે, વ્યક્તિને નહીં

L2TP/IPsec પૂર્વ-શેર કરેલી કી સાથે સાબિત કરે છે કે બે ગેટવે સમાન રહસ્ય જાણે છે. તે કઈ વ્યક્તિ જોડાય છે તે વિશે કંઈ કહેતું નથી, અને તે સ્તર પર એક કર્મચારીને બીજાથી અલગ પાડી શકતું નથી. લાંબું રેન્ડમ મૂલ્ય વાપરો, કેટલાક માર્ગદર્શિકા સૂચવે તે દસ અક્ષરોથી ઘણું વધારે, કારણ કે હેન્ડશેક પકડનાર કોઈ પણ કી પર ઑફલાઇન હુમલો કરી શકે છે.

તે પ્રોફાઇલ પરનો દરેક ક્લાઇન્ટ રહસ્ય વહેંચે છે, તેથી એક વ્યક્તિને દૂર કરવાનો અર્થ છે તેને બાકીના બધામાં ફરી વહેંચવું. મશીન-સ્તરના રહસ્ય ઉપર વપરાશકર્તા પ્રમાણીકરણનું અલગ પગલું રાખો, અને ક્લાઇન્ટ વસ્તી વધે તેમ પ્રમાણપત્રો તરફ જાઓ. પૂર્વ-શેર કરેલી કી MS-CHAPv2 સાથે મળીને બે નબળા સ્તર છે, અને બીજું પહેલાને નકામું કરે છે.

અધિકૃતિ Network Policy Server માં છે

Windows પર NPS નક્કી કરે છે કે કોણ જોડાઈ શકે, અને તે પ્રમાણીકરણ પહેલેથી સફળ થયા પછી કરે છે. એ વિભાજન ઉત્પાદનમાં સૌથી ઉપયોગી સખત કરવાનું નિયંત્રણ છે, અને ઘણી ગોઠવણો તેને અસ્પર્શિત છોડે છે.

એવી નીતિ શરતો વાપરો જે વાસ્તવિક મર્યાદાઓ દર્શાવે: જૂથ સભ્યપદ, જે સમયગાળામાં સપોર્ટ કર્મચારીઓ સાથે હોય, અને આરોગ્ય તપાસમાંથી ઉપકરણની સ્થિતિ. જ્યાં માહિતી ઘર્ષણને ન્યાયી ઠેરવે ત્યાં બીજું પરિબળ ઉમેરો, અને યાદ રાખો કે નીતિ દરેક જોડાણ પ્રયાસ માટે મૂલવાય છે, જે તેને દસ્તાવેજને બદલે જીવંત નિયંત્રણ બનાવે છે.

RADIUS હિસાબ તમને એક રેકોર્ડ પણ આપે છે કે કોણ જોડાયું અને ક્યારે. એ લોગ ઘટના સમીક્ષા અને અનુમાન વચ્ચેનો ફરક છે, અને કોઈ તેને વાંચે કે ન વાંચે તે હાજર રહે છે.

સફળ લોગિન શું પહોંચી શકે તે મર્યાદિત કરો

VPN એડેપ્ટર એવા ફાયરવોલ પ્રોફાઇલમાં ઉતરવું જોઈએ જે તેની ભૂમિકાને જરૂરી સેવાઓને મંજૂરી આપે, આખા સબનેટને નહીં. માર્ગ નક્કી કરવાનો પ્રશ્ન ફિલ્ટરિંગથી અલગ છે. પૂર્ણ ટનલ ક્લાઇન્ટ ઉપકરણનું રક્ષણ કરે અને દરેક બાઇટને તમારા અપલિંકમાંથી પસાર કરે, જ્યારે વિભાજિત ટનલ સ્થાનિક ટ્રાફિકને સ્થાનિક રાખે અને ઉપકરણને જે પણ નેટવર્ક પર હોય તેના સંપર્કમાં લાવે.

બંનેમાંથી કોઈ પણ વિકલ્પ સુરક્ષા મૂળભૂત નથી. બંનેને તેઓ ધારે છે તે ફાયરવોલ પ્રોફાઇલની બાજુમાં લખવા પડશે.

નિષ્ફળતાના માર્ગો ચકાસો

શું તૂટવું જોઈએ તે ચકાસો: ખોટો પાસવર્ડ, સમાપ્ત પ્રમાણપત્ર, રદ કરેલું ઉપકરણ, જૂથની બહારનો વપરાશકર્તા. દરેક અલગ બિંદુએ નિષ્ફળ જવું જોઈએ, અને લોગ કહેવું જોઈએ કે કયું હતું. સેટ પહેલાં પરીક્ષણ ખાતા પર ચલાવો, પછી વાસ્તવિક વપરાશકર્તા માટે પુનરાવર્તન કરો. કારણ વિના ઘટના લોગમાં પહોંચતો અસ્વીકાર તમને એ રેકોર્ડની જરૂર પડે તે પહેલાં ઘણો સમય સુધારવા લાયક છે.

પછી પુષ્ટિ કરો કે કયા પોર્ટ પ્રકાશિત છે અને કેમ. PPTP ને TCP 1723 અને પોર્ટ તરીકે નહીં પણ IP પ્રોટોકોલ તરીકે GRE જોઈએ, IKEv2 ને UDP 500 અને 4500 જોઈએ, અને L2TP ને UDP 1701 ઉપરાંત IPsec જોઈએ. ક્લાઇન્ટ જોડાય તે માટે સંચાલન ઇન્ટરફેસ ખોલવું સમારકામ નથી, તે શોધાવાની રાહ જોતી બીજી ઘટના છે.

અંતે, સર્વર શું રેકોર્ડ કરે અને કેટલા સમય માટે તે નક્કી કરો. પ્રમાણીકરણ ઇતિહાસ વગરનું અંતિમ બિંદુ ઘટના પછીનો પહેલો પ્રશ્ન જવાબ આપી શકતું નથી, એટલે કે પ્રયાસ ક્યારેય અધિકૃત હતો કે નહીં.