તે નબળાઈની શોધ કઈ VPN પ્રક્રિયાને લાગુ પડે છે?

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

ક્રમ મહત્વપૂર્ણ છે: પહેલા ઘટક, બીજું ચેતવણી, ત્રીજું ઉપાય.

અહેવાલ પોર્ટનું નામ આપે છે, પ્રોગ્રામનું નહીં

જે એન્ડપોઇન્ટનું ખરેખર મૂલ્યાંકન થયું તેનાથી શરૂ કરો. HTTPS વ્યવસ્થાપન પોર્ટ સામેની પ્રોબે વેબ સેવા, તેનો TLS સ્ટેક અને તેની સામે બેસેલ કોઈપણ પ્રોક્સી માપ્યા; બીજા પોર્ટ પરના OpenVPN અથવા WireGuard શ્રોતા વિશે તેણે કંઈ શીખ્યું નહીં. રિવર્સ પ્રોક્સી અને વ્યવસ્થાપન એજન્ટો આને વધુ ખરાબ કરે છે, કારણ કે પ્રમાણપત્ર અને બેનર આગળના ભાગના હોઈ શકે જ્યારે નબળી લાઇબ્રેરી પાછળની પ્રક્રિયામાં તેની પાછળ બેસે છે.

પરિણામ સાથે ગંતવ્ય, પરિવહન, પોર્ટ અને સેવાનું નામ નોંધો, જેથી અવકાશ શોધ સાથે મુસાફરી કરે.

ચાલતું બિલ્ડ ખરેખર શું છે

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

systemctl status openvpn-server@server --no-pager
ps -o pid,lstart,args -C openvpn
ss -lntup | grep -E '1194|443'
dpkg -l | grep -i -E 'openvpn|libssl'
ldd "$(command -v openvpn)" | grep -i ssl

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

બિલ્ડને ચેતવણીના અવકાશ સાથે મેળવવું

ચેતવણીઓ ઉત્પાદનો, આવૃત્તિઓ અને ક્યારેક જરૂરી શરતો વર્ણવે છે, અને તે ત્રણ ક્ષેત્રો હંમેશા પેકેજ આવૃત્તિ સાથે મેળ ખાતા નથી. OpenVPNની એપ્રિલ 2014ની Heartbleed ચેતવણી ઉપયોગી ઐતિહાસિક ઉદાહરણ છે, કારણ કે તે અસરગ્રસ્ત Access Server આવૃત્તિઓને વેબ સેવાઓ અને VPN ડીમનથી અલગ પાડે છે, જેમનું એક્સપોઝર અલગ હતું. પાઠ એ છે કે લખાણ કયા ઘટકને આવરી લે છે તે વાંચો, OpenSSL શબ્દને પેટર્ન-મેચ કરવાને બદલે.

તે ચેતવણી પણ જૂની છે. તેના પેચ કરેલ રિલીઝ નંબર હવે ઇન્સ્ટોલેશન સલાહ નથી, અને 2014માં સુધારેલ ખામી આજે તમે ચલાવો છો તે શાખામાં પછીની સમસ્યાઓ વિશે કંઈ કહેતી નથી.

મતભેદ ઉકેલવો, પછી એક્સપોઝર બંધ કરવું

જ્યારે ઇન્વેન્ટરી અને મૂલ્યાંકન અસહમત હોય, ત્યારે તપાસો કે બંને સમાન એન્ડપોઇન્ટ અને રનટાઇમ વર્ણવે છે કે નહીં: બીજું સરનામું, ફ્રન્ટ-એન્ડ પ્રોક્સી, બીજી સેવા, પોર્ટ સાથે હજી જોડાયેલી જૂની પ્રક્રિયા, અથવા પેકેજ મેનેજરે ક્યારેય ન જોયેલી બંડલ કરેલ લાઇબ્રેરી. અહેવાલ ફરીથી લખતા પહેલાં સીમા પર તેને ઉકેલો.

સમર્થિત સુધારો લાગુ કરો, અસરગ્રસ્ત સેવા ફરી શરૂ કરો અને ખાતરી કરો કે નવું બિલ્ડ જ હવે ચાલે છે. ડિસ્ક પર પેચ કરેલ ફાઇલ હોય અને જૂની પ્રક્રિયા હજી ટ્રાફિક સેવા આપે, તે ઉપાય નથી.

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