તમારું VPN ગેટવે સમાધાનિત છે: ખરેખર શું ખુલ્લું છે
હેક થયેલું VPN ગેટવે પોતાના ટનલની અંદર જુએ છે, પણ તેનો અર્થ દરેક સત્ર પર કબજો નથી. પુનઃપ્રાપ્તિ પહેલાં ટ્રાફિક, પહોંચ અને સંગ્રહિત રહસ્યો અલગ કરો.
VPN ગેટવે જે ટનલનું રક્ષણ કરે છે તેના અંતમાં બેસે છે, એટલે કે તે એ એન્ક્રિપ્શન સમાપ્ત કરે છે, તેને પસાર થવા દેતું નથી. જો હુમલાખોર હોસ્ટને નિયંત્રિત કરે, તો ટનલ બહારથી સ્વસ્થ દેખાય છે, જ્યારે વચ્ચેનું મશીન હવે વિશ્વસનીય નથી. ઉપયોગી પ્રશ્ન એ નથી કે બધું ડિક્રિપ્ટ થાય છે કે નહીં. પ્રશ્ન એ છે કે તે હોસ્ટ શું જોઈ શકતું, ક્યાં સુધી પહોંચી શકતું અને કયા રહસ્યો ખરેખર તેના પર સંગ્રહિત હતા. આ ત્રણ જવાબો ઘણા અલગ છે, અને પ્રતિભાવ પણ તેમની સાથે અલગ છે.
ગેટવે ટનલ સમાપ્ત કરે, તેથી તે અંદર જુએ
VPN માં એન્ક્રિપ્શન હોપ દર હોપ થાય છે, અને ગેટવે એ હોપ છે. તે બહારનું સ્તર ઉતારે છે, નીતિ લાગુ કરે છે અને અંદરનું પેકેટ આગળ મોકલે છે, તેથી દરેક વહન કરાયેલું પેકેટ કોઈક સમયે તે હોસ્ટની મેમરીમાં વાંચી શકાય તેવા સ્વરૂપમાં હોય છે. તે ખામી નહીં, રચના છે. તેથી ગેટવે સમાધાનિત થવું એ ટનલની ક્રિપ્ટોગ્રાફી સમાધાનિત થવાથી અલગ ઘટના છે.
હુમલાખોર પહેલાં જે મેળવે છે તે સ્થાન છે: વહન કરાયેલા ટ્રાફિકનું નિરીક્ષણ કરવાની, ફોરવર્ડિંગ બદલવાની, અથવા બેકએન્ડની જગ્યાએ જવાબ આપવાની ક્ષમતા. તે પછી શું મેળવે તે હોસ્ટ પર આધાર રાખે છે, અને અહીં લોકો વધુ પડતો અંદાજ કરે છે. ફક્ત ગેટવેમાં પ્રવેશ બ્રાઉઝરની TLS સત્ર ચાવીઓ આપતું નથી, કારણ કે તે ક્યારેય ગેટવે પર નહોતી.
ત્રણ ખુલ્લા થવાની ઘટનાઓ, જે સમાન માપની નથી
પ્રશ્નને વહન કરાયેલા ટ્રાફિક, પહોંચી શકાય તેવી સિસ્ટમો અને સંગ્રહિત રહસ્યોમાં વિભાજિત કરો, પછી દરેકનો અલગ જવાબ આપો.
| Exposure | What the attacker gains | What does not follow |
|---|---|---|
| Carried traffic | Plaintext of whatever the tunnel forwards without its own encryption | Keys for TLS sessions that terminate at the application |
| Reachable systems | Whatever the backends accept from the gateway's address | Control of every connected client endpoint |
| Stored secrets | The specific keys, tokens and accounts present on that host | Possession of every client certificate or of a CA key |
વચ્ચેની હરોળ એ છે જે છોડી દેવાય છે. ગેટવે પાસે સામાન્ય રીતે ખાનગી નેટવર્કમાં માર્ગ હોય છે અને એવું સ્રોત સરનામું હોય છે જેને બેકએન્ડ પહેલેથી વિશ્વાસ કરે છે, તેથી રસપ્રદ પ્રશ્ન એ છે કે તે બેકએન્ડ તે સરનામેથી શું મંજૂરી આપે છે. સાંકડી ક્લાયન્ટ-એક્સેસ નીતિ સારો નિયંત્રણ છે, પણ હોસ્ટ પરનો હુમલાખોર સામાન્ય ક્લાયન્ટ વાપરે તે ઇન્ટરફેસ સુધી મર્યાદિત નથી.
નીચેની હરોળ નક્કી કરે છે કે ઘટના કેટલો સમય ચાલશે. સર્વર કી અને CA કીના અસરક્ષેત્ર સંપૂર્ણપણે અલગ છે, અને એ જ રીતે સ્થાનિક એડમિન ખાતું અને માત્ર-વાંચવા માટેનું મોનિટરિંગ ટોકન.
ટનલની અંદરનું HTTPS હજી પણ HTTPS છે
એપ્લિકેશનનું TLS એપ્લિકેશનમાં સમાપ્ત થાય છે, VPN ગેટવે પર નહીં, તેથી સમાધાનિત ગેટવે તે પ્રવાહો માટે ફક્ત સાઇફરટેક્સ્ટ જુએ છે. તે હુમલાખોરને શું મળે છે તેની વાસ્તવિક મર્યાદા છે, અને તે સ્પષ્ટ કહેવા લાયક છે, કારણ કે વિરુદ્ધ દાવો ગભરાટ અને ખરાબ નિર્ણયો ફેલાવે છે. બે શરતો તેને તોડે છે. જો માર્ગમાં વિશ્વસનીય પ્રમાણપત્ર ધરાવતો નિરીક્ષણ ઘટક હોય, તો ગેટવે રચના મુજબ સાદું લખાણ જોઈ શકે છે. જો એપ્લિકેશનનું અંતિમ બિંદુ પોતે સમાધાનિત હોય, તો ટનલ અપ્રસ્તુત છે.
તેથી તેઓએ શું જોયું તેનો જવાબ શરતી છે, અને તેને ચુકાદા તરીકે જાહેર કરવાને બદલે શરતો તરીકે લખવો જોઈએ.
ફરી વિશ્વાસ કરતા પહેલાં શું બદલવું પડશે
હોસ્ટ ફરીથી બનાવવું જરૂરી છે અને ભાગ્યે જ પર્યાપ્ત. જે હુમલાખોર પાસે હજી પણ વ્યવસ્થાપન ખાતું, ડિપ્લોયમેન્ટ ક્રેડેન્શિયલ અથવા સાઇનિંગ કી છે તે હોસ્ટને પોતાની ઇચ્છા મુજબ પાછું લાવી શકે છે. પુનઃપ્રાપ્તિ એવા વ્યવસ્થાપન માર્ગથી શરૂ થવી જોઈએ જે સમાધાનિત મશીન પર આધારિત ન હોય.
શું ફેરવવું તે નક્કી કરતા પહેલાં તેના પર શું હતું તેની યાદી બનાવો. ચાવીઓ, સેવા ખાતાં, API ટોકન, સ્થાનિક વપરાશકર્તાઓ, નિર્ધારિત કાર્યો, વિશ્વાસ સંબંધો અને ડિપ્લોયમેન્ટ પાઇપલાઇન બધા ઉમેદવારો છે, અને દરેકનો એક માલિક છે જેણે તેની પુષ્ટિ કરવી જોઈએ.
ss -lntup
getent passwd
crontab -l
ip route show table allતે યાદી એ જોવાનો સૌથી ઝડપી માર્ગ છે કે હોસ્ટ શું આપતું હતું અને ક્યાં સુધી પહોંચી શકતું. પહેલાં પુરાવા સાચવો, પ્રતિભાવ માલિકની પ્રક્રિયા અનુસાર, કારણ કે પુનર્નિર્માણ બરાબર તે જ નષ્ટ કરે છે જે તપાસને જોઈએ છે. NIST SP 800-61 સુધારો 3 તૈયારી, શોધ, પ્રતિભાવ અને પુનઃપ્રાપ્તિને એક જોખમ પ્રક્રિયાના ભાગો ગણે છે, રીસ્ટાર્ટ સૂચના તરીકે નહીં.
એવી સીમાઓ જે આગામી ઘટનાને સસ્તી બનાવે
ચાર સીમાઓ જરૂર પડે તે પહેલાં બનાવવા યોગ્ય છે. ગેટવે દ્વારા પ્રમાણીકરણ ન કરતો સ્વતંત્ર પુનઃપ્રાપ્તિ માર્ગ રાખો. સાઇનિંગ સત્તા ટ્રાફિક પરિચર્યા કરતા હોસ્ટથી અલગ રાખો. ગેટવે ક્યાં સુધી પહોંચી શકે તે મર્યાદિત કરો, જેથી સમાધાનિત ગેટવે આપમેળે સમાધાનિત વ્યવસ્થાપન નેટવર્ક ન બને. અને નોંધો કે દરેક ક્રેડેન્શિયલ કોનું છે, જેથી ફેરવવું પુરાતત્વ પ્રોજેક્ટને બદલે એક ફોન કૉલ બને.
આમાંથી કંઈ પણ સમાધાન અટકાવતું નથી. તે તેને મર્યાદિત કરે છે, અને ખરાબ અઠવાડિયા અને ખરાબ ત્રિમાસિક વચ્ચેનો ફરક બનાવે છે.