మా క్లయింట్‌ల పనిలో "మూడవ పక్షాలు" ఎలా జోక్యం చేసుకోవడానికి ప్రయత్నించాయి మరియు ఈ సమస్య ఎలా పరిష్కరించబడింది అనే దాని గురించి మీకు చక్కని కథను చెప్పండి.
ఇదంతా ఎలా మొదలైంది
చాలా మందికి అత్యవసరమైన మరియు ముఖ్యమైన సమస్యలను పరిష్కరించడానికి చాలా సమయం అవసరం అయినప్పుడు, ఇది అక్టోబర్ 31, నెల చివరి రోజు ఉదయం ప్రారంభమైంది.
అతను మా క్లౌడ్‌లో సేవలందిస్తున్న క్లయింట్‌ల యొక్క అనేక వర్చువల్ మెషీన్‌లను ఉంచే భాగస్వాములలో ఒకరు, మా ఉక్రేనియన్ సైట్‌లో నడుస్తున్న అనేక విండోస్ సర్వర్లు 9:10 నుండి 9:20 వరకు రిమోట్ యాక్సెస్ సేవకు కనెక్షన్‌లను అంగీకరించలేదని నివేదించారు , వినియోగదారులు చేయలేకపోయారు వారి డెస్క్‌టాప్‌లకు లాగిన్ అవ్వడానికి, కానీ కొన్ని నిమిషాల తర్వాత సమస్య స్వయంగా పరిష్కరించబడినట్లు అనిపించింది.
మేము కమ్యూనికేషన్ ఛానెల్‌ల ఆపరేషన్‌పై గణాంకాలను లేవనెత్తాము, కానీ ట్రాఫిక్ పెరుగుదలలు లేదా వైఫల్యాలు ఏవీ కనుగొనబడలేదు. మేము కంప్యూటింగ్ వనరులపై లోడ్పై గణాంకాలను చూశాము - క్రమరాహిత్యాలు లేవు. మరియు అది ఏమిటి?
అప్పుడు మా క్లౌడ్‌లో మరో వంద సర్వర్‌లను హోస్ట్ చేసే మరొక భాగస్వామి, వారి క్లయింట్‌లలో కొందరు గుర్తించిన అదే సమస్యలను నివేదించారు మరియు సాధారణంగా సర్వర్లు అందుబాటులో ఉన్నాయని తేలింది (పింగ్ పరీక్ష మరియు ఇతర అభ్యర్థనలకు సరిగ్గా ప్రతిస్పందించడం), కానీ ఈ సర్వర్‌లలోని సర్వీస్ రిమోట్ యాక్సెస్ కొత్త కనెక్షన్‌లను అంగీకరిస్తుంది లేదా వాటిని తిరస్కరిస్తుంది మరియు మేము వివిధ సైట్‌లలోని సర్వర్‌ల గురించి మాట్లాడుతున్నాము, వివిధ డేటా ట్రాన్స్‌మిషన్ ఛానెల్‌ల నుండి వచ్చే ట్రాఫిక్.
ఈ ట్రాఫిక్‌ని చూద్దాం. కనెక్షన్ అభ్యర్థనతో కూడిన ప్యాకెట్ సర్వర్‌కు చేరుకుంటుంది:
xx:xx:xx.xxxxxx IP xxx.xxx.xxx.xxx.58355 > 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
సర్వర్ ఈ ప్యాకెట్‌ని అందుకుంటుంది, కానీ కనెక్షన్‌ని తిరస్కరిస్తుంది:
xx:xx:xx.xxxxxx IP 192.168.xxx.xxx.3389 > xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0
దీని అర్థం, సమస్య మౌలిక సదుపాయాల ఆపరేషన్‌లో ఏవైనా సమస్యల వల్ల కాదు, మరేదైనా కారణం కావచ్చు. రిమోట్ డెస్క్‌టాప్ లైసెన్సింగ్‌తో వినియోగదారులందరికీ సమస్యలు ఉన్నాయా? కొన్ని రకాల మాల్వేర్ వారి సిస్టమ్‌లలోకి చొచ్చుకుపోయి ఉండవచ్చు మరియు కొన్ని సంవత్సరాల క్రితం మాదిరిగానే ఈ రోజు అది సక్రియం చేయబడింది. XData и Petya?
మేము దాన్ని క్రమబద్ధీకరిస్తున్నప్పుడు, మేము అనేక మంది క్లయింట్లు మరియు భాగస్వాముల నుండి ఇలాంటి అభ్యర్థనలను స్వీకరించాము.
అసలు ఈ మెషీన్లలో ఏం జరుగుతుంది?
ఈవెంట్ లాగ్‌లు పాస్‌వర్డ్‌ను ఊహించే ప్రయత్నాల గురించి సందేశాలతో నిండి ఉన్నాయి:
సాధారణంగా, రిమోట్ యాక్సెస్ సేవ కోసం ప్రామాణిక పోర్ట్ (3389) ఉపయోగించబడుతుంది మరియు ప్రతిచోటా యాక్సెస్ అనుమతించబడే అన్ని సర్వర్‌లలో ఇటువంటి ప్రయత్నాలు నమోదు చేయబడతాయి. ఇంటర్నెట్ నిరంతరం అందుబాటులో ఉన్న అన్ని కనెక్షన్ పాయింట్లను స్కాన్ చేసే బాట్‌లతో నిండి ఉంది మరియు పాస్‌వర్డ్‌ను ఊహించడానికి ప్రయత్నిస్తుంది (అందుకే మేము "123"కి బదులుగా సంక్లిష్ట పాస్‌వర్డ్‌లను ఉపయోగించమని గట్టిగా సిఫార్సు చేస్తున్నాము). అయితే ఆ రోజు ఈ ప్రయత్నాల జోరు మరీ ఎక్కువైంది.
ముందుకి సాగడం ఎలా?
భారీ సంఖ్యలో తుది వినియోగదారులు వేరే పోర్ట్‌కి మారడం కోసం కస్టమర్‌లు ఎక్కువ సమయం సెట్టింగ్‌లను మార్చాలని సిఫార్సు చేస్తున్నారా? మంచి ఆలోచన కాదు, కస్టమర్‌లు సంతోషంగా ఉండరు. VPN ద్వారా మాత్రమే యాక్సెస్‌ని అనుమతించమని సిఫార్సు చేస్తున్నారా? ఆతురుతలో మరియు భయాందోళనలో, IPSec కనెక్షన్‌లను పెంచని వారి కోసం వాటిని పెంచడం - బహుశా అలాంటి ఆనందం ఖాతాదారులకు కూడా నవ్వకపోవచ్చు. అయినప్పటికీ, ఇది ఏ సందర్భంలోనైనా దైవానుసారం అని నేను చెప్పాలి, సర్వర్‌ను ప్రైవేట్ నెట్‌వర్క్‌లో దాచమని మేము ఎల్లప్పుడూ సిఫార్సు చేస్తున్నాము మరియు సెట్టింగ్‌లతో సహాయం చేయడానికి సిద్ధంగా ఉన్నాము మరియు వారి స్వంతంగా గుర్తించాలనుకునే వారి కోసం, మేము సూచనలను పంచుకుంటాము మా క్లౌడ్‌లో IPSec/L2TPని సైట్-టు-సైట్ లేదా రోడ్ మోడ్-వార్రియర్‌లో సెటప్ చేయడం కోసం మరియు ఎవరైనా తమ స్వంత Windows సర్వర్‌లో VPN సేవను సెటప్ చేయాలనుకుంటే, వారు ఎల్లప్పుడూ ఎలా సెటప్ చేయాలనే దానిపై చిట్కాలను పంచుకోవడానికి సిద్ధంగా ఉంటారు. ప్రామాణిక RAS లేదా OpenVPN. కానీ, మేము ఎంత కూల్‌గా ఉన్నా, క్లయింట్‌ల మధ్య విద్యాపరమైన పనిని నిర్వహించడానికి ఇది ఉత్తమ సమయం కాదు, ఎందుకంటే మేము వినియోగదారులకు కనీస ఒత్తిడితో వీలైనంత త్వరగా సమస్యను పరిష్కరించాల్సిన అవసరం ఉంది.
మేము అమలు చేసిన పరిష్కారం క్రింది విధంగా ఉంది. మేము పోర్ట్ 3389కి TCP కనెక్షన్‌ని స్థాపించే అన్ని ప్రయత్నాలను పర్యవేక్షించడానికి మరియు 150 సెకన్లలోపు, మా నెట్‌వర్క్‌లో 16 కంటే ఎక్కువ విభిన్న సర్వర్‌లతో కనెక్షన్‌లను ఏర్పరచడానికి ప్రయత్నించే చిరునామాలను ఎంచుకునే విధంగా ట్రాఫిక్ పాస్ విశ్లేషణను సెటప్ చేసాము. - ఇవి దాడికి మూలాలు (వాస్తవానికి, క్లయింట్లు లేదా భాగస్వాములలో ఒకరికి ఒకే మూలం నుండి చాలా సర్వర్‌లతో కనెక్షన్‌లను ఏర్పాటు చేయాల్సిన అవసరం ఉంటే, మీరు ఎల్లప్పుడూ అలాంటి మూలాలను “వైట్ లిస్ట్‌కి” జోడించవచ్చు. ఈ 150 సెకన్లలో ఒక తరగతి C నెట్‌వర్క్‌లో, 32 కంటే ఎక్కువ చిరునామాలు గుర్తించబడితే, మొత్తం నెట్‌వర్క్‌ను బ్లాక్ చేయడం అర్ధమే. నిరోధించడం 3 రోజులకు సెట్ చేయబడింది మరియు ఈ సమయంలో ఇచ్చిన మూలం నుండి ఎటువంటి దాడులు జరగకపోతే, ఈ మూలం స్వయంచాలకంగా "బ్లాక్ లిస్ట్" నుండి తీసివేయబడుతుంది. బ్లాక్ చేయబడిన మూలాల జాబితా ప్రతి 300 సెకన్లకు నవీకరించబడుతుంది.
ఈ జాబితా ఈ చిరునామాలో అందుబాటులో ఉంది: , మీరు దాని ఆధారంగా మీ ACLలను నిర్మించవచ్చు.
అటువంటి సిస్టమ్ యొక్క సోర్స్ కోడ్‌ను భాగస్వామ్యం చేయడానికి మేము సిద్ధంగా ఉన్నాము; ఇందులో మితిమీరిన సంక్లిష్టంగా ఏమీ లేదు (ఇవి అక్షరాలా మోకాలిపై రెండు గంటలలో సంకలనం చేయబడిన అనేక సాధారణ స్క్రిప్ట్‌లు), మరియు అదే సమయంలో దానిని స్వీకరించవచ్చు మరియు ఉపయోగించకూడదు అటువంటి దాడి నుండి రక్షించడానికి మాత్రమే, కానీ నెట్‌వర్క్‌ను స్కాన్ చేయడానికి ఏవైనా ప్రయత్నాలను గుర్తించడం మరియు నిరోధించడం:
అదనంగా, మేము మానిటరింగ్ సిస్టమ్ యొక్క సెట్టింగ్‌లకు కొన్ని మార్పులు చేసాము, ఇది ఇప్పుడు RDP కనెక్షన్‌ని స్థాపించే ప్రయత్నానికి మా క్లౌడ్‌లోని వర్చువల్ సర్వర్‌ల నియంత్రణ సమూహం యొక్క ప్రతిచర్యను మరింత నిశితంగా పర్యవేక్షిస్తుంది: ప్రతిచర్య ఒక లోపల అనుసరించకపోతే రెండవది, ఇది శ్రద్ధ వహించడానికి ఒక కారణం.
పరిష్కారం చాలా ప్రభావవంతంగా మారింది: క్లయింట్లు మరియు భాగస్వాముల నుండి మరియు పర్యవేక్షణ వ్యవస్థ నుండి ఎటువంటి ఫిర్యాదులు లేవు. కొత్త చిరునామాలు మరియు మొత్తం నెట్‌వర్క్‌లు క్రమం తప్పకుండా బ్లాక్‌లిస్ట్‌కు జోడించబడతాయి, ఇది దాడి కొనసాగుతుందని సూచిస్తుంది, కానీ ఇకపై మా క్లయింట్‌ల పనిని ప్రభావితం చేయదు.
సంఖ్యలో భద్రత ఉంది
ఇతర ఆపరేటర్‌లు కూడా ఇదే సమస్యను ఎదుర్కొన్నారని ఈరోజు మేము తెలుసుకున్నాము. మైక్రోసాఫ్ట్ రిమోట్ యాక్సెస్ సర్వీస్ కోడ్‌లో కొన్ని మార్పులు చేసిందని ఇప్పటికీ ఒకరు నమ్ముతున్నారు (మీకు గుర్తుంటే, మేము మొదటి రోజున అదే విషయాన్ని అనుమానించాము, కానీ మేము ఈ సంస్కరణను చాలా త్వరగా తిరస్కరించాము) మరియు త్వరగా పరిష్కారాన్ని కనుగొనడానికి సాధ్యమైన ప్రతిదాన్ని చేస్తామని హామీ ఇచ్చింది . కొందరు వ్యక్తులు సమస్యను విస్మరిస్తారు మరియు క్లయింట్‌లకు తమను తాము రక్షించుకోవాలని సలహా ఇస్తారు (కనెక్షన్ పోర్ట్‌ను మార్చండి, సర్వర్‌ను ప్రైవేట్ నెట్‌వర్క్‌లో దాచండి మరియు మొదలైనవి). మరియు మొదటి రోజునే, మేము ఈ సమస్యను పరిష్కరించడమే కాకుండా, మేము అభివృద్ధి చేయడానికి ప్లాన్ చేసిన మరింత గ్లోబల్ థ్రెట్ డిటెక్షన్ సిస్టమ్ కోసం కొంత గ్రౌండ్‌వర్క్‌ను కూడా సృష్టించాము.
ఒక రోజు శత్రువు శవం దాని వెంట తేలుతుందని నది ఒడ్డున వేచి ఉండకుండా మౌనంగా ఉండని ఖాతాదారులకు మరియు భాగస్వాములకు ప్రత్యేక ధన్యవాదాలు, కానీ వెంటనే సమస్యపై దృష్టి సారించింది, ఇది మాకు తొలగించడానికి అవకాశం ఇచ్చింది. అది అదే రోజున.
మూలం: www.habr.com