Домашний сервер — ESXi, параноя

Автор: vik_kr Дата: . Категория: Терминальные технологии

На хабре много статей, про то настройку тех или иных кусочков домашнего сервера. Хотелось бы поделиться еще одним вариантом построения домашней сети, нацеленной на сисадмина или разработчика. На этот раз на базе ESXi. 

Кого заинтересовало — добро пожаловать под кат.

Я не буду рассказывать про установку и настройку ESX и гостевых систем, ибо в сети полно статей на эту тему, да и документация на официальном сайте вполне приличная. А расскажу я некоторые идеи, которые я реализовал дома и некоторые тонкости. Но обо всем по порядку.

Начнем с самого сервера — IBM System X3200 M2. Достался он мне практически даром. Узнал от друга, что его друг продает какой-то сервер. Созвонились, встретились, и — вуаля, сервер после небольшого моддинга, занял почетное место старой машинки на базе еще Celeron'a 1.8. Должен отметить правда, что корпус был слегка помят, а именно, не хватало нижней части передней крышки, а внутри не было оперативной памяти вообще. Но это мелочи. Сложнее оказалось достать 2 недостающие салазки в корзину. В городе в прямой продаже нет, в специализированных магазинах под заказ — ждать 1.5 мес и сумма 1.5к за штуку… отказался от этой идеи. Заказал с Китая за 500р с доставкой, пришли за те же 1.5 мес. 

Итого имеем:

  1. Сервер IBM System X3200 M2
    • Intel® Xeon® X3320 2.5GHz
    • 4Г DDR2 800MHz
    • 5 жестких дисков общим объемом около 2TB (без рейда)
    • ESXi
  2. Ноутбук Asus F3SE (заменяет мне комп — стационарной машины, кроме сервера у меня нет, фактически, это мое рабочее место и средство для развлечений),
  3. Точка доступа LinkSys WRT54GS v7 (WAN, 4xLAN 100Mb,WiFi), перепрошитая с dd-wrt micro (эх, сколько мы с ней пережили :) ),
  4. Телефон с WiFi — Nokia E52.


Цели конечной системы:

  1. Максимально разгрузить ноутбук по программному обеспечению,
  2. Предоставить платформу для разработки и тестов (схема примерно такая: установил, настроил, попробовал, выключил; когда понадобилось — включил заново),
  3. Вместе со смотрящими в сеть сервисами, обеспечить корпоративный уровень защиты сервера и данных. В случае дилеммы «функционал/безопасность» выбирать безопасность.


Итак, приступим к самой интересной части. С этого момента будем считать, что сервер подключен к сети, функционирует 24/7, есть безлимитный интернет, установлен ESXi, создано несколько гостевых систем (win2k8 — 1шт, winxp — 1шт, Fedora 14 — N шт в минимальной конфигурации, или любой другой дистрибутив по вкусу и цвету), если где-то что-то запускается (mc, nano, sudo и прочее), то подразумевается, что оно уже установлено.

Шаг 1. Выбор функционала

Что же нам будет необходимо? 
  1. Веб сервера (Apache, IIS, GlassFish/Tomcat),
  2. СУБД (MSSQL, MySQL, FireBird, PostgreSQL),
  3. Torrent-клиент, FlyLinkDC клиент,
  4. SSH доступ ко всем linux-серверам, RDP до одного из Win серверов,
  5. Файловое хранилище.


Шаг 2. Архитектура сети


И вот что у нас примерно должно получиться:
image

Хочу сразу предостеречь уважаемых хабровчан от холивара на тему организации данной сети, она продиктована некоторыми субъективными требованиями, и, пока что, изменяться может только виртуальная ее часть. Простите, но «так исторически сложилось». Однако, конструктивная критика приветствуется. Учту в дальнейшем.

Как видно из диаграммы, из всех виртуальных машин, к физической сети подключена только одна — GALAXY. Этот сервер будет являться шлюзом ко всем виртуальным машинам, будет следить за доступом к важным портам (SSH, RDP) а также вести разнообразные логи.

Шаг 3. Настройка шлюза

Не мудрствуя лукаво, выложу конфиг фаирвола со своего шлюза, с небольшими изменениями. Само собой, все интерфейсы подняты, настроены статические IP, прописаны DNSы, шлюзы, на точке настроен необходимый NAT. Прошу прощения, но все IP и порты заменены или затерты. В этом плане — я параноик если что. :)

firewall.sh
#!/bin/sh

modprobe ip_nat_ftp
modprobe ip_conntrack_ftp
modprobe nf_conntrack_tftp

ipt='/sbin/iptables'

home='#.#.#.#/24'
vmnet='#.#.#.#/24'
mehome='#.#.#.#'
mevmnet='#.#.#.#'

venera='#.#.#.#'

${ipt} -F -t nat
${ipt} -F -t filter
${ipt} -F -t mangle

#established
${ipt} -t filter -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
${ipt} -t filter -A OUTPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT

#allow forwarding
echo "1" > /proc/sys/net/ipv4/ip_forward
${ipt} -t filter -P FORWARD DROP

#log some new connections
${ipt} -A INPUT -m state --state NEW -p tcp --dport 12121 -j LOG --log-level INFO --log-prefix "SSH-NEW : "
${ipt} -A FORWARD -m state --state NEW -d ${venera} -j LOG --log-level INFO --log-prefix "VENERA : "

#localhost
${ipt} -t filter -A INPUT -i lo -j ACCEPT

#icmp home
${ipt} -t filter -A FORWARD -p icmp -s ${home} -j ACCEPT
${ipt} -t filter -A FORWARD -p icmp -d ${home} -j ACCEPT
${ipt} -t filter -A INPUT -p icmp -s ${home} -j ACCEPT
${ipt} -t filter -A OUTPUT -p icmp -d ${home} -j ACCEPT
#icmp vmnet
${ipt} -t filter -A FORWARD -p icmp -s ${vmnet} -j ACCEPT

#dns tcp
${ipt} -t filter -A INPUT -p tcp --sport 53 -j ACCEPT
${ipt} -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
${ipt} -t filter -A FORWARD -p tcp --dport 53 -j ACCEPT
${ipt} -t filter -A FORWARD -p tcp --sport 53 -j ACCEPT

#dns udp
${ipt} -t filter -A INPUT -p udp --sport 53 -j ACCEPT
${ipt} -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
${ipt} -t filter -A FORWARD -p udp --dport 53 -j ACCEPT
${ipt} -t filter -A FORWARD -p udp --sport 53 -j ACCEPT

#ssh
${ipt} -t filter -A INPUT -p tcp --dport 12121 -j ACCEPT

#nat venera (GlassFish[80->8080], SSH[3333->12121])
${ipt} -t nat -A PREROUTING -d ${mehome} -p tcp --dport 3333 -j DNAT --to ${venera}:12121
${ipt} -t nat -A PREROUTING -d ${mehome} -p tcp --dport 80 -j DNAT --to ${venera}:8080
#${ipt} -t filter -A FORWARD -d ${venera} -p tcp --dport 8080 -j ACCEPT
${ipt} -t nat -A POSTROUTING -s ${venera} -j SNAT --to-source ${mehome}
#firwarding for venera
${ipt} -t filter -A FORWARD -s ${venera} -j ACCEPT
${ipt} -t filter -A FORWARD -d ${venera} -p tcp --dport 12121 -j ACCEPT
${ipt} -t filter -A FORWARD -d ${mehome} -p tcp --dport 80 -j ACCEPT

#исходящие временное. оставьте для разрешения доступа этого сервера куда угодно
${ipt} -t filter -A OUTPUT -p all -j ACCEPT

# политика по умолчанию
${ipt} -t filter -A INPUT -p all -j DROP
${ipt} -t filter -A OUTPUT -p all -j DROP


По аналогии с сервером VENERA, настраиваем остальные сервера, включая и исключая нужные порты правилами. Обращу Ваше внимание, что блоке nat venera закомментирована 3я строчка. 
Она разрешает соединения к SSH порту 12121. Закомментирована она по описанной ниже причине.

Шаг 4. Параноя

Кульминацией сего повествования, является реализация техники port knocking
Возможно кто-либо из вас сталкивался с этой темой, но по тем или иным причинам отбросил ее реализацию.
Кому лень Кто не может сходить по ссылке выше, в двух словах расскажу что это и с чем едят. Эта техника позволяет открывать нужный порт, только после того, как с этого же IP постучались на некую последовательность портов. Причем порты из этой последовательности могут быть даже не открыты. Достаточным признаком, является посылка на этот порт пакета с флагом SYN ( ну или другого, по вашему усмотрению). После того как последовательность верно активирована, выполняется команда, открывающая нужный порт в фаирволе. чтобы закрыть этот порт, нужно, согласно этой же технике, постучаться таким же образом на другую последовательность портов. 

Само собой «все уже украдено до нас» (С). Существует демон knockd и клиент вместе с ним, реализующий данный функционал.
Все было бы достаточно просто, если бы я не столкнулся со странной проблемой. Бинарника под RPM системы нет (ткните носом, пожалуйста, если я плохо искал). 
Качаем исходники, распаковываем.

./configure
make


Приехали, из исходников код не компилируется с ошибкой gcc «PATH_MAX — undeclared»… что же делать? :) 
Правильно. Залезть в исходники и посмотреть что же там не так. Благо, помимо служебных файлов, там всего 4 файла: реализация клиента, сервера и реализация собственного списка (.h + .c). После недолгих размышлений вписал между существующими инклудами еще один в файле сервера: 
#include <limits.h>


и все заработало :)
Кстати, с форумов народ пишет, что под FreeBSD ставят без проблем из портов, но я на своей (да, есть у меня и такая виртуалка для тестов) не пробовал. Отпишитесь, пожалуйста, об объективных результатах с последней версией.

Документация к knockd неплохая. Демон простой, удобный, проверил — работает. Так что, с Вашего разрешения, описывать его не буду, но приведу примерный конфиг для данного случая с фаирволом для полноты картины:
[options]
logfile = /var/log/knockd.log

[openSSH]
sequence = порт1,порт2,порт3
seq_timeout = 5
command = /sbin/iptables -A FORWARD -s %IP% -p tcp --dport 8080 -j ACCEPT
tcpflags = syn

[closeSSH]
sequence = порт3,порт2,порт1
seq_timeout = 5
command = /sbin/iptables -D FORWARD -s %IP% -p tcp --dport 8080 -j ACCEPT
tcpflags = syn


Дома использую несколько последовательностей для открытия разных портов к разным виртуальным машинам. К сожалению, порты выбрал только TCP, ибо с ними можно соединяться простым telnet'ом. Но как только разберусь с мобильным клиентом knockd для UDP, обязательно все сделаю как нужно.

На остальных виртуальных машинах заводим необходимые службы, настраиваем все как нам нравится. Не забываем пробросить через виртуальный шлюз нужные порты, и прописать нечто в /etc/knockd.conf, если необходимо. Пользуемся.

Выводы


Этот сервер у меня уже с конца января 2011 года. Чего я на нем только не перепробовал делать/пробовать. И разные сервисы, и Gentoo, и FBSD, и GlassFish, и фаирволы/нат, FireFox на виндовой машине через SSH + XMing и т.п. И все это в одной машине. Теперь я с уверенностью могу заявить, что виртуализация — это круто. К сожалению пока еще не удалось попробовать KVM и XEN (лайв сиди с XEN не в счет — нужно ручками пощупать), но запускать на виртуальной машине еще один гипервизор… даже для моего извращенного мозга, это слишком. Видимо просто не пришло его время.

Скоро придет из другого Китая USB звуковуха, и у меня появится навороченный будильник с управляемым производственным календарем из 1Ски. ^_^
В общем и целом, у кого есть возможность поставить сие чудо на выделенную машину — дерзайте. Возможно кому-то этот топик поможет настроить сервер на работе. Так или иначе, буду рад, что помог.

Спасибо за внимание.

P.S. Я не претендую на 100% защищенность данной схемы, но она куда лучше открытых портов, успокаивает мою параною и дает неоценимый опыт длительного использования. Само собой, стандарные порты на конечных серверах изменены, где это возможно. Не хватает блока по IP адресам злостных брутфорсеров, но это еще все впереди.

 

Источник: http://habrahabr.ru