Електронната поща се утвърди като стандарт в деловата комуникация. Благодарение на високата икономическа ефективност на електронните писма и на редица особености, свързани с цитиране на текст и прикачване на файлове, електронната поща е идеалният универсален начин за обмен на документи и учтив делови контакт. Тези характеристики обаче също така станаха причина, поради която електронната поща бе обожавана от спамерите. В резултат на това, днес електронната поща представлява огромен бушуващ океан от спам, в който рядко се срещат делови писма. Ето защо една от основните задачи на администратора на всеки пощенски сървър е да се защитава от спам-разпратки. Нека разгледаме какво може да се направи с това в Zimbra Collaboration Suite Open-Source Edition.
Въпреки че решението е безплатно, Zimbra OSE може да предостави на системните администратори множество изключително ефективни инструменти за преодоляване на проблема с нежеланите писма. Вече писахме за инструменти като Amavis, SpamAssassin, ClamAV и cbpolicyd, които позволяват надеждно филтриране на входящата поща, отсявайки спам-разпратките, както и заразените и фишингови писма. Въпреки това, основният им недостатък е, че всички те работят с вече получените имейли и изразходват системни ресурси за филтриране на ненужни съобщения, които винаги могат да бъдат използвани по-добре. Но какво, ако вашето предприятие е под прицела на голям ботнет, който постоянно изпраща на вашия пощенски сървър толкова много боклукови писма, че само за тяхното филтриране ще отиде значителна част от ресурсите на MTA?
В теорията защитата от това може да се осигури чрез свързване с облачен сервис за филтриране на входящата поща, но на практика този метод на защита не подхожда на всяко предприятие, тъй като в такъв случай се налага да се доверите на трети лица за обработката не само на спам, но и на деловата кореспонденция, което не винаги е безопасно и често противоречи на политика за безопасност на компанията. Освен това възникват рискове, свързани с надеждността на работата на облачния спам-филтър. Изход от тази ситуация може да бъде организирането на защита на сървъра само със собствени сили. Специално за тези цели в Zimbra беше вградена утилита Postscreen, която е предназначена да защитава пощенския сървър от съобщения, изпращани от ботнети, без да натоварва самия пощенски сървър.
Същността на работата на Postscreen е, че тази утилита преглежда всички заявки за свързване с пощенския сървъра и не позволява на клиентите, които й изглеждат подозрителни, да се свързат със сървъра. Според статистиката около 90% от спама в света се разпространява именно от ботнети, затова Postscreen често се използва като първа степен на защита на пощенския сървър от нежелани пощенски разпратки. Благодарение на това пощенският сървър може стабилно да работи без пренатоварване дори в условия на силни спам атаки от големи ботнети.
Принципът на работа на Postscreen е доста прост, утилита е в състояние да провежда редица основни проверки на входящите писма преди да ги предаде на пощенския сървър или на други услуги, които извършват по-дълбока и детайлна проверка на входящите писма. Всяка от проверките може или да бъде премината, или да не бъде. На базата на резултатите от всяка от проверките Postscreen може да приложи едно от трите действия по избор на администратора на Zimbra: Drop, Ignore или Enforce. Действието Drop принудително разрива връзката с клиента в случай, че проверката не е премината, действието Ignore позволява да се игнорират резултатите от проверката при вземането на окончателно решение, но в същото време събира информация и статистика за извършените проверки, а действието Enforce позволява да се вземат предвид резултатите от проведените проверки при вземането на окончателно решение, но същевременно продължава да извършва всички тестове, които са планирани от системния администратор.
Простият принцип на работа не означава, че е лесен за използване и настройка. Проблемът е, че неправилно конфигурираните Postscreen могат да бъдат причина, поради която важни за бизнеса имейли не достигат до адресата. Затова е важно да се подхожда с внимание при настройката на мощния инструмент Postscreen и да се тества постоянно за неговото поведение в различни ситуации.
Postscreen в Zimbra е активиран по подразбиране, но много потребители може да не са доволни от началната конфигурация. Сега ще разгледаме най-добрия вариант за безопасност и минимизиране на рисковете при настройка на Postscreen. Идеята е, че след провал на който и да е от тестовете, Postscreen няма да разкъсва връзката с клиента, а ще извърши всички проверки до края и в случай на провал ще издаде съобщение за грешка. Това ще позволи на активния подател да бъде информиран за недоставката на имейла в случай, че Postscreen го класифицира като спам. Това се постига чрез настройка на стойността enforce в параметрите на проверките. Тази стойност позволява завършването на започнатите проверки до края, без да се разкъсва връзката с клиента при първия провал, но все пак след завършването им да се блокира спам имейла.
За да активирате необходимите проверки, трябва да въведете следните команди:
zmprov mcf zimbraMtaPostscreenDnsblSites ‘b.barracudacentral.org=127.0.0.2*7’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.[10;11]*8’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.[4..7]*6’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.3*4’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.2*3’
Тази команда позволява добавянето на DNS проверка за входящите връзки от две от най-популярните публични спам бази и оценяване на имейлите в зависимост от това в коя база е намерен адресът на подателя. Колкото повече наказателни „звезди“ събере клиентът, толкова по-вероятно е да бъде спамер.
zmprov mcf zimbraMtaPostscreenDnsblAction enforce
Тази команда определя действието, което се предприема след успешното преминаване на DNS проверката. В този случай резултатът от проверката се запомня, а самият имейл продължава да преминава през по-нататъшните тестове.
zmprov mcf zimbraMtaPostscreenGreetAction enforce
Тъй като в SMTP протокола след непосредствено свързване, сървърът първи започва комуникация с клиента и съответно Postscreen може да изпрати приветствие на клиента. Благодарение на това, че много спам клиенти не изчакват края на приветствието и започват да изпращат команди, те могат лесно да бъдат разпознати. Тази команда позволява да се отчетат резултатите от проверката, но в същото време да се продължи с изпълнението на допълнителни тестове.
zmprov mcf zimbraMtaPostscreenNonSmtpCommandAction drop
В рамките на тази проверка Postscreen позволява да се отсеят тези връзки, които не идват от пощенски клиенти. Тъй като те не изпращат никакви писма, може без каквито и да е опасения да бъдат изключени от сървъра.
zmprov mcf zimbraMtaPostscreenPipeliningAction enforce
Тази проверка се основава на факта, че по подразбиране в протокола SMTP клиентът може да изпрати само една команда наведнъж и след това да изчака отговор от сървъра за тази команда. Въпреки това, много спам ботове се държат по друг начин, изпращайки множество команди, без да изчакат отговор от сървъра. Това позволява почти безпогрешно да се идентифицира спам бот.
В принцип най-подходящите проверки за Postscreen ще бъдат повече от достатъчни, за да се отсеят основните спам ботове от сървъра и да се постигне значително намаляване на натоварването на вашия пощенски сървър. В същото време, живите хора ще получават съобщение, че техните писма не са били доставени, което значително намалява риска от загуба на важни писма поради настройките на Postscreen. В случай, че това се случи, можете да добавите надежден подател в белия списък на Postscreen. За да създадете белите и черни списъци на Postscreen, първо е необходимо да създадете файл /opt/zimbra/conf/postfix/postscreen_wblist.
В него ще добавим списък на разрешените и забранените IP адреси и подсетове в формат CIDR. Например, ще блокираме подсет 121.144.169.*, но ще разрешим свързването на единственото IP адреса от тази подсет:
# Rules are evaluated in the order as specified.
# Blacklist 121.144.169.* except 121.144.169.196.
121.144.169.196/32 permit
121.144.169.0/24 reject
Обърнете внимание на важността на реда на записите. Факт е, че Postscreen ще сканира файла с белите и черни списъци до първото съвпадение, и ако блокираната подсет е преди разрешения IP адрес, проверката просто няма да достигне до записа, че този IP адрес е добавен в белия списък и свързването със сървъра няма да се осъществи.
След като файлът с белите и черните списъци е редактиран и запазен, можете да активирате съответната проверка с помощта на следните команди:
zmprov mcf zimbraMtaPostscreenAccessList «permit_mynetworks, cidr: /opt/zimbra/conf/postfix/postscreen_wblist»
zmprov mcf zimbraMtaPostscreenBlacklistAction enforce
Сега Postscreen, освен вече зададените проверки, ще се обръща и към файла с белите и черните списъци, което ще позволи на администратора да решава проблеми с невъзможността за свързване на надеждни податели към сървера.
Източник: habr.com
