07.21.08
Posted in web, mail, antispam at 2:30 pm by viliar
Раньше роль страшного пугала для пользователей и хостеров из борцов со спамом представлял sorbs, со своей неадекватной политикой включения и выключения хостов в свои списки. В последние пару лет его уверенно потеснил spamhaus. Помимо широко известного скандала с Мажордомо, когда один неадекватный регистратор Godaddy рубанул кучу доменов клиентов Мажоржомо по жалобе spamhaus, они гадят и в более маленьком масштабе:
http://www.spamhaus.org/sbl/sbl.lasso?query=SBL65965
Вот и пара наших серверов попала “заодно” вместе с подсеткой /24 за то, что в этой подсети располагался dns сервер комапнии nameself.com, которая поддерживает (only by dns) домен (2 штука), которые рекламировались спамом. Впрочем, /24 не предел. Многие пользователи colocation у компаниии RTCOMM помнят еще блок по /16 от того же spamhaus…
Permalink
05.13.08
Posted in linux, mail at 2:03 pm by viliar
Заметил, что почему-то ко мне в блог много приходит по запросам относительно postfix с авторизацией пользователей через dovecot sasl. Ума не приложу что тут сложного, но наверно стоит общий образец нарисовать. Postfix совсем не обязательно компилировать с поддержкой именно dovecot sasl и держать в системе хедеры и прочая от dovecot для этого. Sasl как-никак стандарт и начиная с какой-то версии postfix, по-моему с 2.3 можно просто указать тип sasl в
main.cf. По-большему счету вот все, что нам нужно:
/etc/postfix/main.cf
smtpd_sasl_auth_enable=yes
broken_sasl_auth_clients = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
/etc/dovecot/dovecot.conf
auth default {
mechanisms = PLAIN LOGIN DIGEST-MD5 CRAM-MD5
passdb sql {
args = /etc/dovecot/dovecot-sql.conf
}
userdb prefetch {
}
# needed for lda
userdb sql {
args = /etc/dovecot/dovecot-sql.conf
}
user = authdovecot
# It’s possible to export the authentication interface to other programs:
socket listen {
master {
path = /var/run/dovecot/auth-master
mode = 0600
user = vmail
}
client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix
}
}
}
Из конфига dovecot важно вобщем-то только часть про client{}
Permalink
04.18.08
Posted in mail, antispam at 12:56 pm by viliar
Открыл для себя Америку. Оказывается некоторые хосты, в том числе рамблер при приеме почты делают обратную проверку получателя. Если их хост заблокирован по каким-то причинам, то и принимать почту с блокирующего хоста они не будут.
SMTP-02861(ilimpulp.ru) [142336561] return-path rejected, got:578 xxx@xxx address rejected with reverse-check
Такая вот патовая ситуация получается. Наверно это побочный эффект, основная цель все-таки в проверке, существует ли такой отправитель.
Updated: К этому же типу относится ошибка типа:
“451 Could not complete sender verify”.
Permalink
04.13.08
Posted in mail, antispam at 2:30 am by viliar
Для тех, кто любит банить подсети, ну или просто пытается составить себе картину, с каких адресов больше всего валится спам. Есть замечательный ресурс:
http://www.spamcop.net/spamstats.shtml
Помимо “Worst /24,/16 blocks based on total spam count or on spam ratio” там есть чертовски удобная вещь: “Browseable map of IPv4 netspace”. Для каждого из диапазонов ip можно посмотреть наиболее спамовые подсети. Собственно, благодоря статистике спамкопа я сначала пришел к довольно не новой мысли о необходимости банить динамические и диалапные диапазоны. Впоследствии там же нашел dyn/dial диапазоны Turketelecom, которые неохвачены ни pbl.spamhaus.org, ни в dul.dnsbl.sorbs.net.
Единственное - затрудняюсь сказать, какая периодичность у них в обновлении данной информации.
Permalink
04.11.08
Posted in mail, antispam at 10:31 am by viliar
Учитывая масштабы спама одолевающего в последнее время - все больше задумываюсь над разными алгоритмами блокировки этой гадости. К примеру, на одном из хостинговых серверов по работе статистика следующая: По совокупным усилиям всех rbl листов и черных списков за сутки
заблокирован прием почты с 200283 уникальных ip, которые пытались
отправить почту 3263992 раз. Больше трех миллионов…
В последнее время получило довольно широкое распространение блокировка всех non-MTA customer ranges, то бишь тех диапазонов, которые предполгают лишь доступ в интернет, а отправку почты только через smtp сервер интернет-провайдера. Весьма целесообразное решение, но весь впорос в его конкретном вооплощении.
Можно использовать rbl листы:
pbl.spmahaus.org ( за удовольствие стянуть полностью зону rsync’ом нужно будет платить)
dul.dnsbl.sorbs.net
dul.ru
Минус - некоторое, но постоянное отставание от реального положения дел, так как постоянно добавляются новые подсети,
существующие меняются и переодически появляется некоторое
количество хостов в таких подсетях, которые используются как почтовые сервера отдельных организаций и у частных лиц.
В некоторых куроводствах в интернете можно встретить рекомендации блокировать по паттернам в обратной зоне по примерному регекспу:
pool|modem|dial|cable|client|dsl|dhcp|dyn|ppp.
Основная мысль - если человек хочет отправлять почту со сервера, размещенного да adsl канале или в домашней сети, то он сделает нормальную обратную запись. Остальные идут лесом. То есть, в отличии от rbl листов - не надо никакого выносить из какого-то блок-листа. Как только администратор сделал нормальную обратную запись - все в порядке, почта ходит.
Естественно, что для того, чтобы не блокировать почту с нормальных хостов нужны более конкретные регекспы, пусть даже они будут значительно более сложными. Добавлю сюда свои несколько копеек. В качестве эксперимента собрал по этому регекспу список хостов за сутки на одном из серверов. Получилось 66571 уников:
#wc -l uniqhosts
66571 uniqhosts
#head uniqhosts
dsl88.241-38078.ttnet.net.tr
adsl-598433fb.monradsl.monornet.hu
pool-71-115-197-105.spknwa.dsl-w.verizon.net
82.200.213.84.dial.online.kz
dsl88-226-60417.ttnet.net.tr
8-219-112-92.pool.ukrtel.net
bl4-220-22.dsl.telepac.pt
96.89.220.87.dynamic.jazztel.es
201-92-50-50.dsl.telesp.net.br
201-34-151-6.jvece702.dsl.brasiltelecom.net.br
По количеству вхождений получилась следующая статистика:
#grep modem uniqhosts | wc -l
236
#grep client uniqhosts | wc -l
1448
#grep dhcp uniqhosts | wc -l
1667
#grep dial uniqhosts | wc -l
3470
#grep cable uniqhosts | wc -l
4045
#grep pppoe uniqhosts | wc -l
4756
#grep pool uniqhosts | wc -l
7820
#grep ppp uniqhosts | wc -l
8139
#grep adsl uniqhosts | wc -l
12105
#grep dynamic uniqhosts | wc -l
15091
#grep dyn uniqhosts | wc -l
19182
#grep dsl uniqhosts | wc -l
29025
Если делать более точными регекспы во избежание блокировки
нормальных хостов, типа pppoe.org и *dsl*, то кол-во совпадений
естественно снизится. Кто-то этим может пренебречь, но для предоставляемых сервисов клиентам это недопустимо. В принципе, по всех обратным зонам проcлеживается некоторая тенденция, которая наверняка описана в этом документе: http://www.tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes-00, но мне его было лень читать, поэтому нашел сам.
По получившимуся регекспу улов получается значительно более весомый:
#cat uniqhosts | perl -lane ‘print if m/(\d+(\.|-)){3}[a-zA-Z]/’ | wc -l
47878
Рекомендую 
Конечно, лучше использовать все в совокупности, поскольку ни одно из средств не дает стопроцентного результата.
Ну и под конец опишу еще один вариант поддержания информации о таких сетях в актуальном состоянии. Этот вариант будет работать только с добросовестными интернет-провайдерами, которые не ленятся прописывать названия сеток и как-то это дело структурировать:
$ whois -h whois.ripe.net PIPEX-DSL-DYNAMIC| grep inet | awk ‘{ print $2 ” ” $4 }’ | while read net; do ipcalc -r $net; done | grep -v de
81.178.128.0/17
81.179.64.0/18
81.179.128.0/18
81.179.192.0/18
85.210.64.0/18
85.210.0.0/18
85.210.128.0/18
85.210.192.0/18
85.211.0.0/16
81.178.70.0/23
81.178.72.0/21
81.178.80.0/20
81.178.96.0/19
Несколько полезных ссылок:
http://www.senderbase.org/
http://www.db.ripe.net/whois
http://ipindex.homelinux.net/index.php
Permalink
03.25.08
Posted in linux, mail at 1:46 am by viliar
В процессе обсуждения в списках рассылки dovecot@dovecot.org
поднятого мною вопроса о невозможности компиляции xexec с версией 1.1 Stephan Bosch сделал патч, который я, соответственно, протестировал у себя. Пропатченный модуль нормально работает с новой веткой dovecot 1.1, которая, правда, пока находится на стадии rc, но этой весной должен выйти стабильный релиз.
Патч и уже пропатченную версию модуля я, с разрешения авторов модуля и патча, поместил в вики.
Прямые ссылки на файлы:
dovecot-xexec-1.1.v2.patch.
xexec.dovecot.v1.1.tar.gz.
Из-за пертрубаций в dovecot вики выложил файлы и у себя:
xexec.tar.gz
dovecot-xexec-1.1.v2.patch
xexec.1.1.v2.tar.gz
Permalink
03.18.08
Posted in linux, mail at 4:51 pm by viliar
Согласно рекомендациям Timo я сделал такой простейший патч:
— src/master/mail-process.c.orig 2008-03-18 19:55:04.000000000 -0400
+++ src/master/mail-process.c 2008-03-18 19:55:35.000000000 -0400
@@ -75,7 +75,8 @@ mail_process_group_lookup(enum process_t
struct mail_process_group lookup_group;
lookup_group.process.type = type;
- lookup_group.user = t_strdup_noconst(user);
+ /*lookup_group.user = t_strdup_noconst(user);*/
+ lookup_group.user = “”;
lookup_group.remote_ip = *ip;
return hash_lookup(mail_process_groups, &lookup_group);
@@ -89,7 +90,8 @@ mail_process_group_create(enum process_t
group = i_new(struct mail_process_group, 1);
group->process.type = type;
- group->user = i_strdup(user);
+ /*group->user = i_strdup(user);*/
+ group->user = “”;
group->remote_ip = *ip;
i_array_init(&group->processes, 10);
— src/login-common/sasl-server.c.orig 2008-03-19 09:36:56.000000000 -0400
+++ src/login-common/sasl-server.c 2008-03-19 09:37:21.000000000 -0400
@@ -51,7 +51,7 @@ master_callback(struct client *client, e
case MASTER_LOGIN_STATUS_INTERNAL_ERROR:
break;
case MASTER_LOGIN_STATUS_MAX_CONNECTIONS:
- data = “Maximum number of connections from user+IP exceeded”;
+ data = “Maximum number of connections from ip exceeded”;
break;
}
call_client_callback(client, reply, data, NULL);
patch
Вcе работает, но имхо, это может быть только временным воркэраундом, так как работает не так, хотелось бы. Оное ограничивает только кол-во _логинов_ с одного ip. Может кому-то это покажется тем же самым или совсем несущественной разницей, но при этом не ограничиваются коннекты, их можно
сделать сколько угодно, переполнив пул соединений сервера. Так
что будем ждать более правильного решения. Правда в мейллист
все-таки отпишусь, чтобы как-то повлиять на предполагаемую реализацию сего. Кстати, хотелось бы иметь возможность
ограничивать как общее кол-во соединений с ip, так и кол-во соединений к конкретному аккаунту.
Permalink
Posted in linux, mail at 2:42 am by viliar
Вчера в мейллист dovecot’а написал вопрос об возможных путях решения вопроса об ограничении одновременного кол-ва коннектов с одного хоста, как это можно сделать, опять же, в том же CGP. На что уже сегодня получил ответ от Timo (автора dovecot’а) и еще один.
> Hi everyone!
> >
> > I want to manage mail server resource part (like it can CGP) and with it
> > I have one question. Is any way to limit overall max simultaneous
> > connections to imap/pop3 server from one(each) host, except use
> > iptables/ipfw and so on? Like a patch to dovecot or, maybe, it can be
> > released in future versions?
Probably in future versions.
> > I know about
> > mail_max_userip_connections in dovecot 1.1
It should be pretty easy to patch this code to ignore the user and just
limit IPs. You could basically just remove “user” from struct
mail_process_group and fix the code to compile. Or even easier:
static struct mail_process_group *
mail_process_group_lookup(enum process_type type, const char *user,
const struct ip_addr *ip)
{
user = “”; // use the same empty user for everyone
// …
static struct mail_process_group *
mail_process_group_create(enum process_type type, const char *user,
const struct ip_addr *ip)
{
struct mail_process_group *group;
user = “”; // use the same empty user for everyone
и
Sounds like
> > Probably in future versions.
could be trivially implemented with a “mail_process_group_lookup_key”
setting that defaults to %u
Opensource всячески рулит Есть решение на уровне патча для исходных текстов, а также, возможно, это будет реализовано в более поздних версиях. И то и другое хорошо. Первое я даже попробую реализовать в ближайшее время.
//Странно, что этот вопрос никто не задавал до меня. Хорошо, что я его задал. Если это еще и реализуют, это будет совсем прекрасно.
Всем приятной ночи :-)
Permalink
03.12.08
Posted in linux, mail at 8:38 pm by viliar
Немного в продолжение предыдущего поста. Я обещал написать про
xexec. В процессе все тех же поисков рулеза нашел в документации
dovecot’а информацию про этот модуль. Помечен, как
экспериментальный, но мне думается не в силу качества кода,
а в силу того, как они сами написали, что его действия не попадают в стандарты rfc по imap протоколу и, соответственно, не поддерживаются никакими клиентами.
Имхо, замечательная вещь, возможно, в будущем панацея для системных администраторов почтового сервера. Собственно описание можно ограничить одной фразой с сайта:
“Execute any server side application and communicate with it through plugins over IMAP”
Для начала немного примеров:
# telnet 127.0.0.1 143
Trying 127.0.0.1…
Connected to 127.0.0.1.
Escape character is ‘^]’.
* OK Dovecot ready.
001 login viliar@dungeon.local xxxXx
001 OK Logged in.
002 xexec user
* OK User: viliar@dungeon.local, effective uid: 2003
002 OK command exited successfully
Теперь чуть подробнее
003 xexec more
* OK Dovecot gave next info about you:
* OK your account viliar in domain dungeon.local
* OK home at /home/mail/dungeon.local/viliar/ and your uid 2003
* OK connected by IMAP service
* OK local ip 127.0.0.1, your ip 127.0.0.1
003 OK command exited successfully
То есть плагин используется в контексте пользовательского процесса, с
его привелегиями! Теперь давайте вспомним, что я писал про passwd-like файлы. Можно на стороне нарисовать очень простой интерфейс, который будет проверять полученные данные от довекота о пользователе, проверять входные данные и менять файлы конфигурации, которые созданы под его юидом. Никакого доступа к чувствительной информации. Кайф? Не то слово.
Ну и так, до кучи поменяем пароль:
004 xexec chpass XdaRT34
* OK password successefully updated
004 OK command exited successfully
005 logout
* BYE Logging out
005 OK Logout completed.
Connection closed by foreign host
На стороне сервера это будет выглядеть примерно таким образом:
/etc/dovecot/dovecot.conf
plugin {
quota = maildir:ignore=Trash
xexec = date:/usr/local/bin/date
xexec2 = user:/usr/local/bin/user %u
xexec3 = chpass:/usr/local/bin/chpass %u
xexec4 = more:/usr/local/bin/more.sh %n %d %s %p %l %r %h %i
}
Скрипты могут быть любыми, хоть как тут для примера, на баше. Это не то узкое место, где обязательно нужно оптимизировать, потому что эти скрипты не будут так часто запускаться и обрабатывать бешенные обьемы информации, как какой-нибудь демон типа spamassassin, которому с точки зрения ресурсов стоит предпочесть написанный на сях dspam.
Плюсы очевидны. Гибкость и безопасность. Если, условно, сравнить с postfixadmin, хотя это сравнение, я понимаю, не очень корректно, так как сравнивается протокол и интерфейс администрирования. Скорее я сравниваю и то и другое как возможность администрирования почтового сервера и это касается скорее не самого postfixadmin’а, а методов работы таких “вебморд”.
У них, как правило, конкретная привязка к определенному типу хранилища. Ну может быть к нескольким однотипным, на основе sql. Postfixadmin работает только с mysql. Это ограничивает нас существенно. И этому, возможно, очень замечательному интерфейсу я должен дать _полный_ доступ до базы. Это самое ужасное. При возникновении дыр в нем самом, или специфических дыр в php в этом случае можно, простите за выражение, огрести по полной. При совокупности дыр, через mysql, если кому-то придет нелепая идея использовать его еще для чего-то, можно тоже
получить и утечку данных и все-такое. Но это уже из области допущений и можно в расчет не принимать. Но все равно несекурно
совсем как получается. Можно ограничить доступ до административного интерфеса при помощи basic auth и вобще заставлять пользователей ходить только через https. Таким образом мы уменьшаем число потениальных взломщиков только до числа зарегистрированных пользователей. Но это из разряда вспомогательных решений и не хотелось бы надеяться только на дополнительные меры. Хочется секурного “из коробки”, чтобы в основании были более безопасные методы работы с информацией.
При использовании xexec мы получаем возможность использовать любой интерфейс на стороне сервера и на стороне клиента, то есть веб-приложения. Написать, например, модуль для squirrelmail. И это будет
значительно более безопасное решение, потому что веб-интерфейсу мы не даем ключ от квартиры пароль от базы, где лежат
все данные. Ну а если доводить идею об безопасности до абсурда, то сквирмейл, во избежания модификации скриптов, если будут дыры - держать на read-only разделе с единым профилем для всех. Шучу.
Это так, немного информации к размышлению и очередной бонус
активно развивающемуся проекту dovecot. Модульность рулит
Permalink
Posted in linux, mail at 3:42 pm by viliar
Чуть раньше, чем я стал выяснять вопрос с sqlite хранилищем я пытался нарисовать немного другую схему с, так сказать, распределенным хранилищем всей информации, как то домены, аккаунты и алиасы. Для тех, кто работал с CommuniGate (я пишу о ветке 4.1.x, с обновленным монстром, включающим себя сильно позднее даже ip телефонию я не работал) сервером, полагаю, понятно, что я имею в виду. Но, все-таки поясню для остальных. В CGP информация обо всем этом лежит не в каком-то отдельном месте, отдельной базе, но в каталогах самих доменов, аккаунтов следующим образом:
о домене
/var/CommuniGate/Domains/domain.ru/Settings/access.settings
/var/CommuniGate/Domains/domain.ru/Settings/domain.settings
/var/CommuniGate/Domains/domain.ru/Settings/domainAliases.data
об аккаунте:
/var/CommuniGate/Domains/domain.ru/mail.macnt/account.info
/var/CommuniGate/Domains/domain.ru/mail.macnt/account.settings
/var/CommuniGate/Domains/domain.ru/mail.macnt/INBOX.mdir
При запуске Коммунигейта вся информация считывается в память. Что может быть весьма долго, до 2-3 минут на моей памяти при большом кол-ве доменов/аккаунтов. (сотни доменов и тысячи аккаунтов), зато это компенсируется дальнейшим очень быстрым доступом до этих данных. При этом, правда, следует учесть,
что изменения данных на уровне файловой системы, не через
Коммунигейтовские интерфейсы будут замечены только после перезапуска сервера.
Соответсвенно, я стал выяснять, нельзя ли что-то похожее реализовать в связке postfix/dovecot. В процессе изысканий выяснилось, что умничка dovecot умеет работать со можеством passwd-ike файлов. По шаблону. В версии 1.0.x это будет выглядеть
так (из минусов - файлы будут перечитываться каждый раз заново, а может, только если mtime менялся - нужно смотреть сам код):
passdb passwd-file {
args = /mail/%d/%n/settings
}
где :%d, как вы догадались, домен, а %n - имя аккаунта.
Красота? Красота. Уже довольно похоже на файловую структуру CGP.
Но этого, конечно, маловато. Нам недостаточно только логина и пароля. А что делать с квотой и пр? Это тоже пока не из области фантастики, благодаря гибкости довекота:
userdb passwd-file {
args = /mail/%d/%n/settings
}
userdb prefetch {
}
Последний пункт, according documentation, попытка выйграть
некоторое кол-во тактов процессора, возвращая вместе с паролем
дополнительную информацию об аккаунте. Один запрос вместо двух. Все это вобщем-то есть в вики.
Вот, например, что мы еще можем хранить в passwd-like файле:
# cat /mail/skymail.local/hensen/settings
hensen:{plain}test:2000:2000::::userdb_nice=10 userdb_quota=maildir:storage=2048 quota=maildir:storage=2048
Пояснять отдельные моменты не буду, отмечу лишь, что home задается mail_loction, но можно и здесь. Плюс, что нам дает еще эта схема? Возвращять один uid на пользователя, если нужно, а можно один для домена. Что хорошо для виртуального хостинга, для использования общей файловой квоты на аккаунты. В общем, наметки выглядят довольно вкусно, если еще учитывать возможности плагина xexec, о котором я напишу отдельным постом. Получается, на этой базе можно выстроить хорошую конфигурацию pop3/imap сервера, дополнительно используя namespaces и managesieve. Да,
к довекоту есть интерфейс managesieve, правда на данный момент отдельным патчем. К версии 2.0, которая пока неизвестно, когда
будет, Timo Sirainen предполагает переработать патч и включить в основную ветку.
А что, собственно, делать с postfix? Каким он боком будет в этой схеме? На часть вопросов ответ у меня есть. Из-за других, я собственно и стал рассматривать другие варианты хранилища.
Первая - хорошая новость. Postfix c версии 2.3 может использовать
процесс dovecot-auth для авторизации (через sasl) пользователей.
Одним зайцем меньше. Что существенно. Но остаются самые большие зайцы. Как вписывать в эту схему алиасы и домены я пока не придумал. Использовать для них отдельное хранилище? Дублируются данные и встает вопрос о необходимости постоянной синхронизации. Мне этот вариант не нравится. Пришлось гнать от себя прочь всякие
извращенные мысли,типа inotify демона, который будет отслеживать
изменения файлов settings,aliases в этих каталогах и обновлять базу
postfix’а. Или демона, который будет считывать информацию из каталогов домена и по tcp будет отвечать postfix’у.
Т.к. Postfix поддерживает такой тип таблиц в девел версии: tcp:
Но это ни разу не production решения.
Все должно быть проще. Чем больше компонентов в системе, тем больше шансов, что что-то отвалится. Может быть в будущих версиях postfix’а что-то изменится к лучшему, а может найдется решение, которое вроде бы перед глазами, но я его пока не вижу.
Permalink
« Previous entries · Next entries »