Продолжаем защищаться или fail2ban на страже сервера

  • Linux
Предистория: Недавно настраивал в одной небольшой конторе внешний мультисервер — squid/postfix/apache и так далее. Доступ естественно по ssh, в конторе сразу попросили настроить защиту с мира на все что возможно. «Громкая просьба», но заказчик в данном случае прав — защита нужна, хотя бы от тупых халявщиков и прочей бредни. Естественно пожелание было учтено.
Вообще эпопея началась сразу: как только поднял ssh и proftpd (делал большую часть удаленно), в логи посыпался перебор паролей, на первом этапе быстренько подцепил sshguard — на первое время так сказать хватит. Так как в мир смотрело много сервисов — включая POP3/IMAP4 (ну возжаждал так клиент, web-морды для почты им мало) и прочее, решил поискать что-нибудь поинтересней. Google как говориться в помощь. Плутая в дебрях инета нашол простенькую, но интересную прогу из боекомплекта linux — fail2ban, быстренько пробежался по описанию — дружит почти со всем что можно и нельзя, умеет баннить и jail-ить. Ну что ж — вперед, на танки как говориться.
Читать дальше →

ZImbra: нетривиальная маршрутизация почты - часть 2

  • LDAP
Первая часть тут

Положим, поставила перед вами нелёгкая судьбина следующую задачу: добавить в Zimbr'у alias, он же псевдоним. Но псевдоним тот не простой, а виртуальный, указывающий не на пользователя в локальном домене, обслуживаемом Zimbra, а на некий «внешний» почтовый адрес.
Как законопослушный гражданин, вы наверняка первым делом загрузите интерфейс администрирования Zimbra и в меню Создать выберете «Псевдоним». После совершения указанной манипуляции пред ваши очи предстанет такое вот окно:

Читать дальше →

ZImbra: нетривиальная маршрутизация почты - часть 1

  • LDAP
Zimbra — замечательный Collaboration Suite, но с точки зрения тонкой настройки собственно почтового сервиса MTA (в качестве которого, как мы все знаем, используется Postfix) её веб-интерфейс сильно хромает, а местами так и просто обескураживает.
Например, есть у меня Zimbra на внутреннем почтовике, она полностью закрыта от внешнего доступа и всю исходящую корреспонденцию шлёт внешнему серверу-шлюзу, от него же и принимает оную. Плюс настроен Split-Domain (как именно — см. Split Domain: Configuring Zimbra as the Secondary System), потому что пока на внешнем шлюзе есть нехилый кусок нашего корпоративного домена. Ну да это не суть важно, а важно то, что в моём случае Zimbra по дефолту не может отправлять любую почту, кроме адресованной локальным получателям, куда-либо, кроме того самого внешнего шлюза.
И всё было бы хорошо, если бы в дополнение к собственному домену Zimbra, назовём его domain.com, не появился ещё один внутренний домен с именем lists.domain.com, хостящийся буквально по соседству (VLAN/подсетка совпадают, так что не требуется дополнительная маршрутизация). И вот тут дефолтная конфигурация уже перестала меня устраивать: ведь в этот «соседний» домен тоже нужно каким-то образом отправлять почту, но если оставить всё как есть, то получится абсурдная ситуация: сначала Zimbra будет отправлять сообщение в lists.domain.com через интернет-шлюз на почтовый шлюз, а затем последний уже отправит это письмо обратно через интернет-шлюз… почти туда же, откуда оно и ушло. Таким образом, мы получили бы маршрутизацию почты в lists.domain.com аля «путешествие Афанасия Никитина за три моря» и массу потенциального геморроя.

Читать дальше →