હેક થયેલ વેબ ગેટવે હજી શું સુધી પહોંચી શકે?
વેબ ગેટવે મુલાકાતી શું ખોલે તે મર્યાદિત કરે છે, હેક થયેલ યજમાન શું જોડી શકે તે નહીં. બે સમીક્ષાઓ, એક અધિકાર કોષ્ટક અને પહોંચ માપવાના આદેશો.
ધારો કે ગેટવે યજમાન તેના પ્રમાણપત્ર હજી માન્ય હોય ત્યારે જ છેતરાયેલ છે. મુલાકાતી કયા પૃષ્ઠો માંગી શકે તે નિયંત્રિત કરતું દરેક નિયમ અમલમાં રહે છે, અને તે નિયમોમાંથી કોઈ પણ હુમલાખોર હવે તે યજમાનથી ડેટાબેઝ સબનેટ તરફ ખોલતા જોડાણને મર્યાદિત કરતું નથી. આ જ અંતર એ કારણ છે કે ફક્ત-વેબ પ્રવેશબિંદુ વિભાજિત નેટવર્ક જેવો જ દાવો નથી. બંને દાવાઓને અલગ સમીક્ષાઓની જરૂર છે, જુદા જુદા પ્રારંભિક બિંદુઓથી, તેમાંથી કોઈ પણ પ્રામાણિકપણે કરી શકાય તે પહેલાં.
બે દાવા, અને તેમાંથી ફક્ત એક જ મુલાકાતીથી શરૂ થાય છે
પ્રથમ દાવો વ્યક્તિ વિશે છે: બ્રાઉઝર અને માન્ય સત્ર ધરાવતો મુલાકાતી એક એપ્લિકેશન ખોલી શકે છે અને બીજું કંઈ નહીં. ફક્ત-વેબ પ્રવેશબિંદુ તે દાવાનો સારો જવાબ આપે છે, કારણ કે મુલાકાતીને માર્ગને બદલે પૃષ્ઠ મળે છે. તે જવાબ રાખવા યોગ્ય છે, અને તે એકમાત્ર દાવો પણ છે જે મોટાભાગના રેખાચિત્રો નોંધે છે.
બીજો દાવો ઘટક વિશે છે: ગેટવે, અથવા તેની પાછળની એપ્લિકેશન પ્રક્રિયા, બીજા કોઈના નિયંત્રણમાં છે એમ ધારવામાં આવે છે. તે ધારણાથી પ્રશ્ન કયા URL માન્ય છે તેમાંથી બદલાઈને પ્રક્રિયા હજી કયા લક્ષ્યો અને ઓળખ સુધી પહોંચી શકે છે તે બને છે.
બંને દાવાઓના માલિકો અલગ છે, અલગ પુરાવા આપે છે અને સ્વતંત્ર રીતે નિષ્ફળ જાય છે. ઓળખ ટીમ સત્ર પરીક્ષણથી પ્રથમ દાવો દર્શાવી શકે છે; બીજા માટે નેટવર્ક નીતિ, સેવા-ખાતાની સમીક્ષા અને યજમાન નિયંત્રણો જરૂરી છે. જે રચના ફક્ત મુલાકાતીનો અડધો ભાગ નોંધે છે તે સમીક્ષા સ્લાઇડ પર પૂર્ણ અને ઘટનાના સમયે પાતળી દેખાય છે, કારણ કે છેતરપિંડી પછી મહત્વપૂર્ણ નિયંત્રણો ક્યારેય અવકાશમાં ન હતા. કયું નિયંત્રણ કયા દાવાને સમર્થન આપે છે તે નામ આપો, નહીં તો એક ગેટવે નિયમ બંનેને જમા થશે.
એક કામ કરેલી ખર્ચ સેવા, અને તે જે બે રીતે હારે છે
એક ખર્ચ સેવા લો: 10.60.4.10 પરનું જાહેર ગેટવે કર્મચારીઓને પ્રમાણિત કરે છે અને મંજૂર વિનંતીઓને પોર્ટ 8443 પરની એપ્લિકેશન શ્રોતા પર મોકલે છે, અને તે એપ્લિકેશન expenses_app ભૂમિકા તરીકે 10.60.4.20:5432 પરના એક PostgreSQL શ્રોતા સુધી પહોંચે છે. કર્મચારીઓને સામાન્ય આંતરિક પ્રવેશ મળવાનો આશય નથી. સામાન્ય કામગીરીમાં રચના ખરેખર ડેટાબેઝ શ્રોતાને ક્યાંય પ્રકાશિત કર્યા વિના એપ્લિકેશન-વિશિષ્ટ પ્રવેશ આપે છે. સરનામાં મહત્વપૂર્ણ છે, કારણ કે આ લેખમાંનું દરેક પછીનું પરીક્ષણ તેમને નામ આપે છે.
હવે ગેટવેને વિશ્વાસપાત્ર સમૂહમાંથી દૂર કરો. 10.60.4.10 ની પ્રક્રિયા હુમલાખોરની થાય પછી તે કયા લક્ષ્યો સુધી પહોંચી શકે? મુલાકાતીઓને મર્યાદિત કરતું URL ફિલ્ટર ગેટવે યજમાન ડેટાબેઝ સબનેટ તરફ ખોલતા જોડાણ વિશે કંઈ કહેતું નથી.
તેના બદલે એપ્લિકેશન પ્રક્રિયા દૂર કરો, અને અધિકાર આકાર બદલે છે: expenses_app ભૂમિકા, તે સર્વર જે સેવાઓ સુધી પહોંચી શકે છે, અને તે ખાતું જે ફાઇલો વાંચી શકે છે. બંને કિસ્સામાં આગળનું દરવાજું ફક્ત-વેબ રહી શકે છે જ્યારે બેકએન્ડ સીમા ગેરહાજર છે. તેથી આગળના દરવાજા પરનું લેબલ બંને પ્રશ્નોમાંથી કોઈનો જવાબ નથી.
દરેક પક્ષ પાસે ખરેખર જે અધિકાર છે તેનો નકશો બનાવો
ઇચ્છિત પરવાનગીઓ તરીકે લખાયેલો કરાર સામાન્ય રીતે રચનાને તમને પાછી પરત કરે છે. તેને ધારણ કરેલા અધિકાર, વધારાને રદ કરતા પરીક્ષણ અને તે પરીક્ષણના માલિક તરીકે લખો, પછી દરેક પંક્તિ પરીક્ષણયોગ્ય બને છે. આ કોષ્ટક ઉપરના ઉદાહરણ માટેની દરખાસ્ત છે, ઉત્પાદન દાવો નથી:
| Component | Authority it actually holds | Check that proves the denial | Owner of the check |
|---|---|---|---|
| Identity provider | Issues assertions and session cookies, and holds no network path of its own | A request to the application URL without a session is redirected to the login page | Identity team |
| Public gateway host | TCP reachability to whatever its routing table and egress rules permit | An egress rule drops 10.60.4.20:5432 and the probe reports the port filtered | Network platform team |
| Application role | SQL privileges granted to expenses_app inside the expenses database | A privilege query shows no ownership or create right on any other schema | Application team |
| Database listener | Accepts connections only from the source ranges named in its host-based rules | A connection from an unlisted address is refused before authentication | Database administrator |
| Management path | Administrative access reserved for patching, monitoring and recovery | A staff workstation cannot reach the administrative port or jump through it | Platform owner |
માલિકી અધિકારને અનુસરે છે. ઓળખ ટીમ દાવાઓની માલિક છે, નેટવર્ક પ્લેટફોર્મ ટીમ માર્ગોની, એપ્લિકેશન ટીમ ડેટાબેઝ ભૂમિકાની, ડેટાબેઝ વ્યવસ્થાપક શ્રોતા અને તેના યજમાન-આધારિત નિયમોનો, અને પ્લેટફોર્મ માલિક વ્યવસ્થાપન સપાટીનો. માલિક વિનાનો ઇનકાર દસ્તાવેજમાંનું વાક્ય છે, નિયંત્રણ નથી.
આ વિભાજન બેવડી ગણતરી પણ અટકાવે છે. પોર્ટ પ્રતિબંધ કોષ્ટક વિશેષાધિકાર વ્યક્ત કરી શકતો નથી, અને ડેટાબેઝ ભૂમિકા યજમાનને અસંબંધિત સબનેટ તરફ સોકેટ ખોલતા રોકી શકતી નથી.
ગેટવે શું સુધી પહોંચી શકે તે દાવો કરવાને બદલે ગણો
સીમાનો દાવો તેની પાછળની ગણતરી જેટલો જ સારો છે. ગેટવે યજમાન પર ત્રણ આદેશો માર્ગ પસંદગી, જીવંત પ્રોબ અને બહિર્ગમન નીતિ આવરી લે છે:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputઆઉટપુટ તે ક્રમમાં વાંચો. માર્ગ કહે છે કે 10.60.4.20 તે યજમાનથી જ પસંદ થાય છે કે નહીં; પ્રોબ કહે છે કે શ્રોતા જવાબ આપે છે કે નહીં; નિયમ સૂચિ દર્શાવે છે કે નીતિ પેકેટ રોકે છે અથવા તેના માર્ગમાં ક્યારેય કંઈ હતું જ નહીં.
એપ્લિકેશન યજમાનથી ગણતરીનું પુનરાવર્તન કરો. ત્યાંથી ડેટાબેઝ બાજુ એપ્લિકેશન ભૂમિકા તરીકે ચલાવાયેલ એક ક્વેરી છે:
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'બીજી સ્કીમા વાંચી ન શકતી ભૂમિકા હેઠળ સફળ જોડાણ માલિક ભૂમિકા હેઠળના સફળ જોડાણથી અલગ પરિણામ છે. ફક્ત બીજું જ એક શોધ છે.
ઇનકાર નોંધો, પછી સમીક્ષાને તારીખ આપો
સ્વીકૃતિ ઇરાદા નહીં પરંતુ પરિણામ તરીકે લખાય છે: કર્મચારી સત્ર શ્રોતા સુધી પહોંચી શકતું નથી, ગેટવે યજમાન અસંબંધિત સબનેટ સુધી પહોંચી શકતું નથી, અને એપ્લિકેશન ભૂમિકા ડેટાબેઝ બનાવી શકતી નથી. દરેક નામાંકિત માલિક અને તારીખ સાથે અલગ પરીક્ષણ છે.
મોનિટરિંગ, પેચિંગ અને પુનઃપ્રાપ્તિ તેમના માટે રચાયેલા વ્યવસ્થાપન માર્ગ દ્વારા પહોંચી શકાય તેમ રાખો. જે સીમા તેના માલિકને પણ અવરોધે છે તે વિક્ષેપ બને છે, અને તે વિક્ષેપનો સામાન્ય પ્રથમ પ્રતિસાદ નિયમને ફરી પહોળો કરવાનો છે. CISA પરિમિતિ માર્ગદર્શિકા ન્યાયી પોર્ટ અને પ્રોટોકોલ સુધી આંતરિક અને બહાર જતા પ્રવેશને મર્યાદિત કરવાનું કહે છે, જેમાં આંતરિક નેટવર્ક વચ્ચેનો ટ્રાફિક પણ સામેલ છે, જે બેકએન્ડથી શરૂ થતી દિશા છે જે મોટાભાગના રેખાચિત્રો છોડી દે છે.
સમીક્ષાને તારીખ આપો અને તેના માલિકનું નામ આપો. ગેટવે ઇમેજ, રૂટિંગ ટેબલ અથવા એપ્લિકેશન ભૂમિકામાં કોઈપણ ફેરફાર પછી ગણતરી અને વિશેષાધિકાર ક્વેરી ફરી ચલાવો.