Փոստի ռմբակոծությունը կիբերհարձակումների ամենահին տեսակներից մեկն է: Իր հիմքում այն հիշեցնում է սովորական DoS հարձակման, միայն տարբեր IP հասցեներից հարցումների ալիքի փոխարեն սերվեր է ուղարկվում նամակների ալիք, որոնք հսկայական քանակությամբ հասնում են էլ. դրա վրա զգալիորեն ավելանում է։ Նման հարձակումը կարող է հանգեցնել փոստարկղից օգտվելու անկարողության, իսկ երբեմն նույնիսկ կարող է հանգեցնել ամբողջ սերվերի ձախողման: Այս տեսակի կիբերհարձակումների երկար պատմությունը հանգեցրել է մի շարք դրական և բացասական հետևանքների համակարգի ադմինիստրատորների համար: Դրական գործոնները ներառում են փոստի ռմբակոծության լավ իմացությունը և նման հարձակումից պաշտպանվելու պարզ ուղիների առկայությունը: Բացասական գործոնները ներառում են մեծ թվով հանրությանը հասանելի ծրագրային լուծումներ այս տեսակի հարձակումների իրականացման համար և հարձակվողի կարողությունը հուսալիորեն պաշտպանվելու հայտնաբերումից:
Այս կիբերհարձակման կարևոր առանձնահատկությունն այն է, որ գրեթե անհնար է օգտագործել այն շահույթ ստանալու համար: Դե, հարձակվողը նամակների մի ալիք ուղարկեց փոստարկղերից մեկին, լավ, նա թույլ չտվեց, որ մարդը նորմալ օգտագործի էլփոստը, լավ, հարձակվողը կոտրել է ինչ-որ մեկի կորպորատիվ էլ. ինչո՞ւ սերվերը կամ խափանվեց, կամ սկսեց դանդաղել, որ այն օգտագործելն անհնարին դարձավ, և ի՞նչ հետո: Նման կիբերհանցագործությունը իրական փողի վերածելը գրեթե անհնար է, ուստի պարզապես փոստի ռմբակոծումը ներկայումս բավականին հազվադեպ երևույթ է, և համակարգի ադմինիստրատորները, ենթակառուցվածքը նախագծելիս, կարող են պարզապես չհիշել նման կիբերհարձակումից պաշտպանվելու անհրաժեշտությունը:
Այնուամենայնիվ, թեև էլփոստի ռմբակոծումն ինքնին առևտրային տեսանկյունից բավականին անիմաստ վարժություն է, այն հաճախ այլ, ավելի բարդ և բազմափուլ կիբեր հարձակումների մաս է կազմում: Օրինակ, երբ կոտրում են փոստը և այն օգտագործում են որոշ հանրային ծառայություններում հաշիվ գողանալու համար, հարձակվողները հաճախ անիմաստ տառերով «ռմբակոծում են» զոհի փոստարկղը, որպեսզի հաստատման նամակը կորչի նրանց հոսքի մեջ և աննկատ մնա: Փոստի ռմբակոծումը կարող է օգտագործվել նաև որպես ձեռնարկության վրա տնտեսական ճնշման միջոց: Այսպիսով, ձեռնարկության հանրային փոստարկղի ակտիվ ռմբակոծումը, որը հաճախորդներից հարցումներ է ստանում, կարող է լրջորեն բարդացնել նրանց հետ աշխատանքը և, որպես հետևանք, հանգեցնել սարքավորումների աշխատանքի դադարեցման, չկատարված պատվերների, ինչպես նաև հեղինակության կորստի և կորցրած շահույթի:
Այդ իսկ պատճառով համակարգի ադմինիստրատորը չպետք է մոռանա էլփոստի ռմբակոծման հավանականության մասին և միշտ անհրաժեշտ միջոցներ ձեռնարկի այդ սպառնալիքից պաշտպանվելու համար։ Հաշվի առնելով, որ դա կարելի է անել փոստի ենթակառուցվածքի կառուցման փուլում, ինչպես նաև, որ համակարգի ադմինիստրատորից շատ քիչ ժամանակ և աշխատանք է պահանջվում, պարզապես օբյեկտիվ պատճառներ չկան ձեր ենթակառուցվածքին փոստի ռմբակոծությունից պաշտպանություն չապահովելու համար: Եկեք նայենք, թե ինչպես է այս կիբերհարձակումից պաշտպանությունն իրականացվում Zimbra Collaboration Suite Open-Source Edition-ում:
Zimbra-ն հիմնված է Postfix-ի վրա՝ այսօր հասանելի ամենահուսալի և ֆունկցիոնալ բաց կոդով փոստի փոխանցման գործակալներից մեկը: Եվ դրա բաց լինելու հիմնական առավելություններից մեկն այն է, որ այն աջակցում է երրորդ կողմի լուծումների լայն տեսականի՝ ֆունկցիոնալությունը ընդլայնելու համար: Մասնավորապես, Postfix-ը լիովին աջակցում է cbpolicyd-ին՝ փոստի սերվերի կիբերանվտանգության ապահովման առաջադեմ գործիք: Ի հավելումն սպամից պաշտպանվածության և սպիտակ ցուցակների, սև ցուցակների և մոխրագույն ցուցակների ստեղծմանը, cbpolicyd-ը թույլ է տալիս Zimbra-ի ադմինիստրատորին կարգավորել SPF ստորագրության ստուգումը, ինչպես նաև սահմանափակումներ սահմանել էլ. նամակների կամ տվյալների ստացման և ուղարկելու համար: Նրանք կարող են և՛ հուսալի պաշտպանություն ապահովել սպամից և ֆիշինգային նամակներից, և՛ պաշտպանել սերվերը էլփոստի ռմբակոծությունից:
Առաջին բանը, որ պահանջվում է համակարգի ադմինիստրատորից՝ ակտիվացնել cbpolicyd մոդուլը, որը նախապես տեղադրված է Zimbra Collaboration Suite OSE-ում ենթակառուցվածքի MTA սերվերի վրա: Սա արվում է zmprov ms «zmhostname» +zimbraServiceEnabled cbpolicyd հրամանի միջոցով: Դրանից հետո դուք պետք է ակտիվացնեք վեբ ինտերֆեյսը, որպեսզի կարողանաք հարմարավետորեն կառավարել cbpolicyd-ը: Դա անելու համար դուք պետք է թույլատրեք կապեր 7780 վեբ-պորտի վրա, ստեղծեք խորհրդանշական հղում՝ օգտագործելով հրամանը ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, այնուհետև խմբագրեք կարգավորումների ֆայլը՝ օգտագործելով nano հրամանը /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, որտեղ պետք է գրել հետևյալ տողերը.
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER = "արմատ";
$DB_TABLE_PREFIX="";
Դրանից հետո մնում է միայն վերագործարկել Zimbra և Zimbra Apache ծառայությունները՝ օգտագործելով zmcontrol restart և zmapachectl restart հրամանները։ Դրանից հետո դուք կունենաք մուտք դեպի վեբ ինտերֆեյս :7780/webui/index.php. Հիմնական նրբերանգն այն է, որ այս վեբ ինտերֆեյսի մուտքը դեռ որևէ կերպ պաշտպանված չէ, և որպեսզի չլիազորված անձանց մուտք գործեն այն, դուք կարող եք պարզապես փակել կապերը 7780 նավահանգստում վեբ ինտերֆեյսի յուրաքանչյուր մուտքից հետո:
Դուք կարող եք պաշտպանվել ձեզ ներքին ցանցից եկող նամակների հեղեղից՝ օգտագործելով էլ. նամակներ ուղարկելու քվոտաներ, որոնք կարող են սահմանվել cbpolicyd-ի շնորհիվ: Նման քվոտաները թույլ են տալիս սահմանել նամակների առավելագույն քանակը, որոնք կարող են ուղարկվել մեկ փոստարկղից մեկ միավորի ընթացքում: Օրինակ, եթե ձեր բիզնեսի մենեջերները ժամում ուղարկում են միջինը 60-80 նամակ, ապա դուք կարող եք սահմանել ժամում 100 էլ. Այս քվոտային հասնելու համար ղեկավարները պետք է յուրաքանչյուր 36 վայրկյանը մեկ նամակ ուղարկեն: Մի կողմից, սա բավական է լիարժեք աշխատելու համար, իսկ մյուս կողմից, նման քվոտայով հարձակվողները, ովքեր մուտք են գործել ձեր մենեջերներից մեկի փոստը, չեն գործարկի փոստով ռմբակոծություն կամ զանգվածային սպամ հարձակում ձեռնարկության վրա:
Նման քվոտա սահմանելու համար դուք պետք է վեբ ինտերֆեյսում ստեղծեք էլփոստի ուղարկման սահմանափակման նոր քաղաքականություն և նշեք, որ այն վերաբերում է ինչպես տիրույթում ուղարկված նամակներին, այնպես էլ արտաքին հասցեներին ուղարկված նամակներին: Դա արվում է հետևյալ կերպ.
Դրանից հետո դուք կարող եք ավելի մանրամասն նշել նամակներ ուղարկելու հետ կապված սահմանափակումները, մասնավորապես, սահմանել ժամանակային միջակայքը, որից հետո սահմանափակումները կթարմացվեն, ինչպես նաև այն հաղորդագրությունը, որը կստանա իր սահմանաչափը գերազանցած օգտատերը: Դրանից հետո դուք կարող եք սահմանել նամակներ ուղարկելու սահմանափակում: Այն կարող է սահմանվել և՛ որպես ելքային տառերի, և՛ որպես փոխանցվող տեղեկատվության բայթերի քանակ: Միևնույն ժամանակ, նամակներին, որոնք ուղարկվում են սահմանված սահմանաչափը գերազանցող, պետք է այլ կերպ վարվեն: Այսպիսով, օրինակ, դուք կարող եք պարզապես ջնջել դրանք անմիջապես, կամ կարող եք դրանք պահել այնպես, որ դրանք ուղարկվեն անմիջապես հաղորդագրություն ուղարկելու սահմանաչափի թարմացումից հետո: Երկրորդ տարբերակը կարող է օգտագործվել աշխատակիցների կողմից նամակներ ուղարկելու սահմանաչափի օպտիմալ արժեքը որոշելիս:
Բացի նամակներ ուղարկելու սահմանափակումներից, cbpolicyd-ը թույլ է տալիս սահմանել նամակներ ստանալու համար: Նման սահմանափակումն առաջին հայացքից հիանալի լուծում է փոստի ռմբակոծությունից պաշտպանվելու համար, բայց իրականում նման սահմանաչափի սահմանումը, նույնիսկ մեծ, հղի է նրանով, որ որոշակի պայմաններում կարևոր նամակ կարող է չհասնել ձեզ: Այդ իսկ պատճառով խորհուրդ չի տրվում միացնել մուտքային փոստի որևէ սահմանափակում: Այնուամենայնիվ, եթե դուք դեռ որոշում եք ռիսկի դիմել, ապա պետք է հատուկ ուշադրությամբ մոտենաք մուտքային հաղորդագրությունների սահմանաչափի սահմանմանը: Օրինակ, դուք կարող եք սահմանափակել վստահելի գործընկերներից ստացվող նամակների քանակը, որպեսզի եթե նրանց փոստի սերվերը վտանգի ենթարկվի, այն չհարձակվի ձեր բիզնեսի վրա սպամի վրա:
Փոստի ռմբակոծման ժամանակ մուտքային հաղորդագրությունների հոսքից պաշտպանվելու համար համակարգի ադմինիստրատորը պետք է ավելի խելացի բան անի, քան պարզապես մուտքային փոստը սահմանափակելը: Այս լուծումը կարող է լինել մոխրագույն ցուցակների օգտագործումը: Նրանց գործողության սկզբունքն այն է, որ անվստահելի ուղարկողի կողմից հաղորդագրություն հասցնելու առաջին փորձից հետո սերվերի հետ կապը կտրուկ ընդհատվում է, ինչի պատճառով նամակի առաքումը ձախողվում է։ Այնուամենայնիվ, եթե որոշակի ժամանակահատվածում անվստահելի սերվերը փորձի նորից ուղարկել նույն նամակը, սերվերը չի փակում կապը, և դրա առաքումը հաջող է:
Այս բոլոր գործողությունների իմաստն այն է, որ զանգվածային նամակների ավտոմատ ուղարկման ծրագրերը սովորաբար չեն ստուգում ուղարկված հաղորդագրության առաքման հաջողությունը և չեն փորձում այն երկրորդ անգամ ուղարկել, մինչդեռ անձը, անշուշտ, կհամոզվի, թե արդյոք իր նամակն ուղարկվել է. հասցեն, թե ոչ.
Կարող եք նաև միացնել մոխրագույն ցուցակը cbpolicyd վեբ ինտերֆեյսում: Որպեսզի ամեն ինչ աշխատի, դուք պետք է ստեղծեք քաղաքականություն, որը կներառի մեր սերվերի օգտատերերին ուղղված բոլոր մուտքային նամակները, այնուհետև, այս քաղաքականության հիման վրա, ստեղծեք Greylisting կանոն, որտեղ կարող եք կարգավորել այն ընդմիջումը, որի ընթացքում cbpolicyd-ը կսպասի: անհայտ անձի ուղարկողի կողմից կրկնվող պատասխանի համար: Սովորաբար դա 4-5 րոպե է։ Միևնույն ժամանակ, մոխրագույն ցուցակները կարող են կազմաձևվել այնպես, որ հաշվի առնվեն տարբեր ուղարկողներից նամակներ հասցնելու բոլոր հաջող և անհաջող փորձերը և, ելնելով դրանց թվից, որոշում է կայացվում ավտոմատ կերպով ուղարկողին ավելացնել սպիտակ կամ սև ցուցակներում:
Ձեր ուշադրությունն ենք հրավիրում այն փաստի վրա, որ գորշ ցուցակների օգտագործումը պետք է կատարվի առավելագույն պատասխանատվությամբ։ Լավագույնը կլինի, եթե այս տեխնոլոգիայի օգտագործումը զուգընթաց ընթանա սպիտակ և սև ցուցակների մշտական պահպանման հետ՝ ձեռնարկության համար իսկապես կարևոր նամակներ կորցնելու հնարավորությունը վերացնելու համար:
Բացի այդ, SPF, DMARC և DKIM չեկերի ավելացումը կարող է օգնել պաշտպանվել էլ.փոստի ռմբակոծությունից: Հաճախ նամակները, որոնք հասնում են փոստի ռմբակոծման գործընթացով, նման ստուգումներ չեն անցնում: Ինչպես դա անել, քննարկվեց .
Այսպիսով, պաշտպանվելն այնպիսի սպառնալիքից, ինչպիսին էլփոստի ռմբակոծումն է, բավականին պարզ է, և դուք կարող եք դա անել նույնիսկ ձեր ձեռնարկության համար Zimbra ենթակառուցվածքի կառուցման փուլում: Այնուամենայնիվ, կարևոր է մշտապես ապահովել, որ նման պաշտպանությունից օգտվելու ռիսկերը երբեք չգերազանցեն ձեր ստացած օգուտները:
Source: www.habr.com