జూలై 19, 2019న, క్యాపిటల్ వన్ ప్రతి ఆధునిక కంపెనీ భయపడే సందేశాన్ని అందుకుంది-డేటా ఉల్లంఘన జరిగింది. ఇది 106 మిలియన్లకు పైగా ప్రజలను ప్రభావితం చేసింది. 140 US సోషల్ సెక్యూరిటీ నంబర్లు, ఒక మిలియన్ కెనడియన్ సోషల్ సెక్యూరిటీ నంబర్లు. 000 బ్యాంకు ఖాతాలు. అసహ్యకరమైనది, మీరు అంగీకరించలేదా?
దురదృష్టవశాత్తు, జూలై 19న హ్యాక్ జరగలేదు. ఇది ముగిసినట్లుగా, పైజ్ థాంప్సన్, a.k.a. అనియత, మార్చి 22 మరియు మార్చి 23, 2019 మధ్య కట్టుబడి ఉంది. అంటే దాదాపు నాలుగు నెలల క్రితం. నిజానికి, బయటి కన్సల్టెంట్ల సహాయంతో మాత్రమే క్యాపిటల్ వన్ ఏదో జరిగిందని కనుగొనగలిగింది.
ఒక మాజీ అమెజాన్ ఉద్యోగి అరెస్టయ్యాడు మరియు $250 జరిమానా మరియు ఐదు సంవత్సరాల జైలు శిక్షను ఎదుర్కొంటాడు... కానీ ఇంకా చాలా ప్రతికూలత మిగిలి ఉంది. ఎందుకు? ఎందుకంటే హ్యాక్లతో బాధపడుతున్న చాలా కంపెనీలు సైబర్క్రైమ్ల పెరుగుదల మధ్య తమ మౌలిక సదుపాయాలు మరియు అప్లికేషన్లను బలోపేతం చేసే బాధ్యత నుండి తప్పించుకోవడానికి ప్రయత్నిస్తున్నాయి.
ఏమైనా, మీరు ఈ కథనాన్ని సులభంగా గూగుల్ చేయవచ్చు. మేము డ్రామాలోకి వెళ్లము, కానీ మాట్లాడతాము సాంకేతిక విషయం యొక్క వైపు.
అన్నింటిలో మొదటిది, ఏమి జరిగింది?
క్యాపిటల్ వన్లో దాదాపు 700 S3 బకెట్లు నడుస్తున్నాయి, వాటిని పైజ్ థాంప్సన్ కాపీ చేసి బయటకు తీశారు.
రెండవది, ఇది తప్పుగా కాన్ఫిగర్ చేయబడిన S3 బకెట్ విధానం యొక్క మరొక సందర్భమా?
లేదు, ఈసారి కాదు. ఇక్కడ ఆమె తప్పుగా కాన్ఫిగర్ చేయబడిన ఫైర్వాల్తో సర్వర్కు యాక్సెస్ పొందింది మరియు అక్కడ నుండి మొత్తం ఆపరేషన్ను నిర్వహించింది.
వేచి ఉండండి, ఇది ఎలా సాధ్యమవుతుంది?
సరే, సర్వర్లోకి లాగిన్ చేయడం ద్వారా ప్రారంభిద్దాం, అయినప్పటికీ మన దగ్గర చాలా వివరాలు లేవు. ఇది "తప్పుగా కాన్ఫిగర్ చేయబడిన ఫైర్వాల్" ద్వారా జరిగిందని మాత్రమే మాకు చెప్పబడింది. కాబట్టి, సరికాని భద్రతా సమూహ సెట్టింగ్లు లేదా వెబ్ అప్లికేషన్ ఫైర్వాల్ (ఇంపర్వా), లేదా నెట్వర్క్ ఫైర్వాల్ (iptables, ufw, shorewal, మొదలైనవి) యొక్క కాన్ఫిగరేషన్ వంటి సాధారణమైనది. క్యాపిటల్ వన్ తన నేరాన్ని మాత్రమే అంగీకరించింది మరియు రంధ్రాన్ని మూసివేసినట్లు చెప్పింది.
క్యాపిటల్ వన్ మొదట్లో ఫైర్వాల్ దుర్బలత్వాన్ని గుర్తించలేదని, అయితే దాని గురించి తెలుసుకున్న తర్వాత త్వరగా పని చేసిందని స్టోన్ చెప్పారు. పబ్లిక్ డొమైన్లో కీలకమైన గుర్తింపు సమాచారాన్ని హ్యాకర్ వదిలివేయడం వల్ల ఇది ఖచ్చితంగా సహాయపడిందని స్టోన్ చెప్పారు.
మేము ఈ భాగంలోకి ఎందుకు లోతుగా వెళ్లడం లేదని మీరు ఆలోచిస్తున్నట్లయితే, పరిమిత సమాచారం కారణంగా మేము ఊహాగానాలు మాత్రమే చేయగలమని అర్థం చేసుకోండి. క్యాపిటల్ వన్ వదిలిపెట్టిన రంధ్రంపై హ్యాక్ ఆధారపడి ఉందని ఇది అర్ధం కాదు. మరియు వారు మాకు మరింత చెబితే తప్ప, మేము క్యాపిటల్ వన్ వారి సర్వర్ని తెరిచి ఉంచిన అన్ని మార్గాలను జాబితా చేస్తాము, ఎవరైనా ఈ విభిన్న ఎంపికలలో ఒకదానిని ఉపయోగించగల అన్ని మార్గాలతో కలిపి. ఈ లోపాలు మరియు పద్ధతులు క్రూరమైన తెలివితక్కువ పర్యవేక్షణల నుండి చాలా క్లిష్టమైన నమూనాల వరకు ఉంటాయి. సాధ్యాసాధ్యాల పరిధిని బట్టి, ఇది నిజమైన ముగింపు లేకుండా సుదీర్ఘ కథగా మారుతుంది. అందువల్ల, మనకు వాస్తవాలు ఉన్న భాగాన్ని విశ్లేషించడంపై దృష్టి పెడదాం.
కాబట్టి మొదటి టేకావే: మీ ఫైర్వాల్లు ఏమి అనుమతిస్తాయో తెలుసుకోండి.
తెరవాల్సినవి మాత్రమే తెరవబడతాయని నిర్ధారించుకోవడానికి ఒక విధానాన్ని లేదా సరైన ప్రక్రియను ఏర్పాటు చేయండి. మీరు సెక్యూరిటీ గ్రూప్లు లేదా నెట్వర్క్ ACLల వంటి AWS వనరులను ఉపయోగిస్తుంటే, ఆడిట్ చేయడానికి చెక్లిస్ట్ చాలా పొడవుగా ఉండవచ్చు... కానీ చాలా వనరులు స్వయంచాలకంగా సృష్టించబడినట్లే (అంటే CloudFormation), వాటి ఆడిటింగ్ను ఆటోమేట్ చేయడం కూడా సాధ్యమే. లోపాల కోసం కొత్త వస్తువులను స్కాన్ చేసే హోమ్మేడ్ స్క్రిప్ట్ అయినా, లేదా CI/CD ప్రాసెస్లో సెక్యూరిటీ ఆడిట్ లాంటిదే అయినా... దీన్ని నివారించడానికి చాలా సులభమైన ఎంపికలు ఉన్నాయి.
కథలోని "తమాషా" భాగం ఏమిటంటే, క్యాపిటల్ వన్ మొదటి స్థానంలో రంధ్రం చేసి ఉంటే.. ఏమీ జరగలేదు. కాబట్టి, స్పష్టంగా చెప్పాలంటే, నిజంగా ఏదో ఎలా ఉంటుందో చూడటం ఎల్లప్పుడూ షాకింగ్గా ఉంటుంది అందంగా సాధారణ కంపెనీ హ్యాక్ కావడానికి ఏకైక కారణం అవుతుంది. ముఖ్యంగా క్యాపిటల్ వన్ అంత పెద్దది.
కాబట్టి, లోపల హ్యాకర్ - తరువాత ఏమి జరిగింది?
సరే, EC2 ఉదాహరణలోకి ప్రవేశించిన తర్వాత... చాలా తప్పులు జరగవచ్చు. మీరు ఎవరినైనా అంత దూరం వెళ్లనిస్తే మీరు ఆచరణాత్మకంగా కత్తి అంచున నడుస్తున్నారు. అయితే అది S3 బకెట్లలోకి ఎలా వచ్చింది? దీన్ని అర్థం చేసుకోవడానికి, IAM పాత్రల గురించి చర్చిద్దాం.
కాబట్టి, AWS సేవలను యాక్సెస్ చేయడానికి ఒక మార్గం వినియోగదారుగా ఉండటం. సరే, ఇది చాలా స్పష్టంగా ఉంది. కానీ మీరు మీ అప్లికేషన్ సర్వర్ల వంటి ఇతర AWS సేవలను మీ S3 బకెట్లకు యాక్సెస్ చేయాలనుకుంటే ఏమి చేయాలి? IAM పాత్రలు దానికోసమే. అవి రెండు భాగాలను కలిగి ఉంటాయి:
- విశ్వసనీయ విధానం - ఏ సేవలు లేదా వ్యక్తులు ఈ పాత్రను ఉపయోగించవచ్చు?
- అనుమతుల విధానం - ఈ పాత్ర దేనిని అనుమతిస్తుంది?
ఉదాహరణకు, మీరు S2 బకెట్ను యాక్సెస్ చేయడానికి EC3 ఇన్స్టాన్స్లను అనుమతించే IAM రోల్ని సృష్టించాలనుకుంటున్నారు: ముందుగా, EC2 (మొత్తం సేవ) లేదా నిర్దిష్ట సందర్భాలు పాత్రను "స్వీకరించగల" ట్రస్ట్ పాలసీని కలిగి ఉండేలా రోల్ సెట్ చేయబడింది. పాత్రను అంగీకరించడం అంటే, వారు చర్యలు చేయడానికి పాత్ర యొక్క అనుమతులను ఉపయోగించవచ్చు. రెండవది, ఒక నిర్దిష్ట బకెట్ను యాక్సెస్ చేసినా... లేదా క్యాపిటల్ వన్ విషయంలో వలె 3 కంటే ఎక్కువ అయినా, S700లో ఏదైనా "పాత్ర పోషించిన" సేవ/వ్యక్తి/వనరులను అనుమతుల విధానం అనుమతిస్తుంది.
మీరు IAM రోల్తో EC2 ఉదాహరణలో ఉన్నప్పుడు, మీరు అనేక మార్గాల్లో ఆధారాలను పొందవచ్చు:
- మీరు ఇక్కడ ఉదాహరణ మెటాడేటాను అభ్యర్థించవచ్చు
http://169.254.169.254/latest/meta-data
ఇతర విషయాలతోపాటు, మీరు ఈ చిరునామాలో ఏదైనా యాక్సెస్ కీలతో IAM పాత్రను కనుగొనవచ్చు. వాస్తవానికి, మీరు ఒక సందర్భంలో ఉంటే మాత్రమే.
- AWS CLIని ఉపయోగించండి...
AWS CLI ఇన్స్టాల్ చేయబడితే, అది IAM పాత్రల నుండి క్రెడెన్షియల్లతో లోడ్ చేయబడుతుంది. ఉదాహరణ ద్వారా పని చేయడమే మిగిలి ఉంది. అయితే, వారి ట్రస్ట్ పాలసీ తెరిచి ఉంటే, పైజ్ నేరుగా ప్రతిదీ చేయగలడు.
కాబట్టి IAM పాత్రల సారాంశం ఏమిటంటే అవి కొన్ని వనరులను ఇతర వనరులపై మీ తరపున పని చేయడానికి అనుమతిస్తాయి.
ఇప్పుడు మీరు IAM యొక్క పాత్రలను అర్థం చేసుకున్నారు, మేము పైజ్ థాంప్సన్ చేసిన దాని గురించి మాట్లాడవచ్చు:
- ఫైర్వాల్లోని రంధ్రం ద్వారా ఆమె సర్వర్కి (EC2 ఉదాహరణ) యాక్సెస్ని పొందింది
అది భద్రతా సమూహాలు/ACLలు లేదా వారి స్వంత వెబ్ అప్లికేషన్ ఫైర్వాల్లు అయినా, అధికారిక రికార్డులలో పేర్కొన్నట్లుగా రంధ్రం ప్లగ్ చేయడం చాలా సులభం.
- ఒకసారి సర్వర్లో, ఆమె స్వయంగా సర్వర్గా "లాగా" వ్యవహరించగలిగింది
- IAM సర్వర్ పాత్ర ఈ 3+ బకెట్లకు S700 యాక్సెస్ను అనుమతించినందున, అది వాటిని యాక్సెస్ చేయగలిగింది
ఆ క్షణం నుండి, ఆమె చేయాల్సిందల్లా ఆదేశాన్ని అమలు చేయడం List Buckets
ఆపై ఆదేశం Sync
AWS CLI నుండి...
కథ యొక్క నైతికత: మీ భద్రతను తనిఖీ చేయండి; సాధారణ తనిఖీలను నిర్వహించండి; భద్రతా విధానాలకు కనీస హక్కు సూత్రాన్ని గౌరవించండి.
(
మూలం: www.habr.com