Прийшов час перейти до поштової серваке.
- Сервак з ексченджем практично мертвий (1 гіг оперативки) + спам фільтр нагинають його до землі, при збільшенні глибини фільтрації встає просто «колом».
- Сам спам-фільтр не такий гарний, як би нам хотілося (як не дивно пропускає спам в казахських доменів).
Так як в даний момент моє вивчення направлено на вивчення freebsd, то відповідно і поштовий шлюз буде на ньому. Sendmail мені здався досить заморочений (напевно це для фанатів більше), я вирішив зупинитися на Postfix.
Ну ось, Exchange прибраний всередину, шлюз тепер побудований на операційній системі більш придатною для цієї мети і здається, що ви в безпеці. Але не поспішайте так думати, адже Exchange як був доступний з Інтернету, так і залишився. І при неправильній конфігурації він може стати сервером для спам-розсилок, джерелом поширення вірусів і метою для атак. Втім, метою для атак він може стати в будь-якому випадку, адже атакувати не можна тільки ту систему, яка виключена. Зайдіть на будь-який сайт, який дає огляди по знайденим уязвимостям, і подивіться статистику. Ви можете заперечити, що застосовуєте останні латки, але ж уразливості завжди на крок попереду і де гарантія, що ви встигнете залатати дірки перш, ніж відбудеться неприємність.
Ось висновок команд, доступних за умовчанням в Exchange:
250-VRFY 250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS = LOGIN 250-AUTH GSSAPI NTLM LOGIN
Відключити ж непотрібні команди, повзаючи по меню System Manager, вам навряд чи вдасться.
а) Немає можливості підібратися до Exchange безпосередньо ззовні, а значить провести атаку або отримати доступ до ваших даних через діри в іншому ПО, наприклад, через IIS, який потрібно для установки Exchange. Атака ж на Postfix загрожує виходом з ладу тільки Postfix, який не містить ні користувальницьких бюджетів, ні важливих даних. До того ж, наскільки мені відомо, за останні кілька років в Postfix не виявлено критичних вразливостей і швидше за все не буде знайдено таких дірок, які можуть привести до катастрофи. З огляду на все вищесказане, можна зробити висновок, що ризик втрати даних через крах Postfix дорівнює нулю.
б) Виходячи з пункту «а», ясно, що часу на відновлення функціонування пошти на шлюзі знадобиться менше, ніж системі Exchange, що містить дані, я б навіть сказав багато менше, якщо врахувати, що в деяких випадках установка всієї системи з нуля, в нашому випадку операційної системи і Postfix, єдино прийнятний вихід. Все, що вам потрібно, це зберегти кілька конфігураційних файлів і при установці нової системи перенести їх назад. А можна зробити ще простіше - створити образ жорсткого диска. У разі катастрофи потрібно буде просто заново записати образ на жорсткий диск і оновити конфігураційні файли. Таким чином, простий системи буде зведений до мінімуму.
г) Налаштування Postfix на порядок простіше і навіть використовуючи значення за замовчуванням, він пропонує достатній рівень безпеки, чого не скажеш про Exchange. Встановіть спершу Postfix на шлюз, а потім розбирайтеся з настройками Exchange скільки вам влізе, не побоюючись зробити ті чи інші помилки, які приведуть до небажаних наслідків.
Якщо вам підходить цей варіант, то потрібно зробити зовсім небагато, звичайно, за винятком описаного вище. Установка Exchange і операційних систем тут не описується.
Postfix встановлюємо ось так.
Ставити будемо звичайно з портів:
нам буде наданий вибір
в даному випадку нам знадобиться тільки SASL.
Після закінчення складання вся документація в / usr / local / share / doc / postfix /. файли конфігурації в / usr / local / etc / postfix /
У FreeBSD інформація про поштові програмах знаходиться в /etc/mail/mailer.conf
У нашому випадку він повинен виглядати так
Крім того, так як sendmail, як такої, нам більше не знадобиться, додамо в /etc/make.conf рядок
При перезібравши та встановлення миру sendmail більше не братиме участі.
Вкажемо в /etc/rc.conf. що sendmail ми більше не імпользуем
Почнемо з Postfix. Не забули, що MX-запис в DNS вказує на нього (не забудьте її змінити або нити айпішники на серверах). Повторюю ще раз, що ми описуємо взаємодію Postfix і Exchange, і якщо ви не бачите тут рядків, що стосуються smtp-аутентифікації або ще чого-небудь, то це не означає, що цього не повинно бути в конфігурації вашого сервера.
Відкриваємо для редагування файл main.cf.
Ім'я вашої машини:
Ім'я вашого домену:
Ваші довірені мережі:
mynetworks = 127.0.0.0/8, 192.168.44.0/24
mynetworks = 127.0.0.0/8, 192.168.44.20
Таким чином, ви забороняєте внутрішнім клієнтам використання Postfix в обхід Exchange.
Локальні одержувачі, залишити значення порожнім, так як їх на цій машині просто немає:
Якщо ми повинні вважати своїми кілька доменів, то їх можна перерахувати тут:
mydestination = $ myhostname, localhost. $ mydomain, $ mydomain, seq.ru, seq1.ru
Зазначаємо, в якому файлі у нас буде описаний маршрут до Exchange:
Після збереження файлів main.cf і transport даємо команду:
яка при першому виклику створить файл transport.db, а в подальшому буде оновлювати цей файл, з огляду на зміни в файлі transport.
Далі подаємо команду:
яка перезапустить Postfix з урахуванням змін у файлі main.cf.
Повернулася команда, що Postfix не стартував.
З Postfix закінчили, переходимо до Exchange. Exchange повинен бути налаштований на обробку пошти для наших доменів. Відкриваємо System Manager, переходимо до Connectors. і вибираємо «New -> SMTP Connector».
Встановимо Apache з портів:
Потім додамо в /etc/rc.conf рядок для того що б можна було запускати демона apache
Тепер відредагуйте конфігураційний файл apache /usr/local/etc/apache22/httpd.conf командою
Налаштування Apache в якості зворотного проксі може бути темою для окремої статті. Наведу лише найпростіший приклад для доступу до OWA на основі Apache 2.x.
LoadModule proxy_module libexec / apache2 / mod_proxy.so
LoadModule proxy_http_module libexec / apache2 / mod_proxy_http.so
Далі додамо наступні рядки:
Ось, власне, і все. І хоча тут представлена проста схема, вона з успіхом може застосовуватися в більш складних мережах, коли є кілька поштових серверів, які обслуговують кілька доменів, і не обов'язково це повинні бути Exchange-сервера.
Далі буде …