Одминский блог

Untangle Re-Routing: це не бага, це фича

Как я у же отметил ранее, в процессе знакомства с новой, для меня, платформой Untangle я натолкнулся на довольно странное поведение. Начал я с того, что закачав образ на удаленный сервер ESXi, решил спокойно ночью поднять VPN сервер, чтобы утром уже логиниться не через rdp, а через IPSec. Подтянул образ, залил его в инвентори, начал установку.  Все поставилось прекрасно, но как только я настроил сетку на одном из интерфейсов- у меня все упало, т.е. соединение отвалилось без возможности восстановления таким образом, будто упала сеть. Имея все таки некоторое представление о работе шлюзов и фаервольных решений, я прикинул, что отвалиться ESXi уж не мог точно, ибо в любом случае новый шлюз мог бы залочить только свой виртуальный интерфейс, а не доступ во внутреннюю сетку, так что с утра я начал исходить из того, что сработал закон Мерфи, который мне в процессе многочисленных настроек неоднократно напоминал о своей существовании, когда ты нажимаешь на кнопку сохранить, а во всем офисе рубится свет;  и у меня в момент настройки Untangle порушилась сеть.

В итоге ребутнули сервак ESXi, все поднялось, так что вечером я выехал на удаленную площадку. Прибыв на место, немного пошакалил по свичам, ибо решил было, что проблема крылась в них, но все было вроде нормально, так что я приступил снова к настройке Untangle. Надо отметить, что я, как истинный российский одмин, хотя и веселюсь на эту тему, некоторое время уже как читаю мануал только после того как все сломалось, так что в данном случае я полагал, что официального wiki how-to-install untangle вполне достаточно для того чтобы поставить платформу. Стартанул сервак на ESXi, и как только, судя по процентным соотношениям загрузки, платформа запустила сетевые интерфейсы у меня снова полегла сеть. Это меня подвигло в совершеннейшие не понятки, поскольку сеть лежала наглухо- то есть она отсутствовала как класс- пинги не проходили даже до свича, в который была воткнута машина, не говоря уже про какие то шлюзы и сервера, сидевшие на соседях по каскаду. Рубанув сервер, снова поднял ESXi и удалил с него Untangle, решив поднять его в тестовом варианте у себя на машине. В итоге на след. день, подняв его в оболочке VMware Workstation я так же радостно положил сетку своего офиса, но поскольку доступ к виртуальной среде у меня уже был не по сети, то отрубив интерфейсы на виртуально машине, я полез в инет с извечным вопросом “whatafuck?”.

Оказалось, что в платформе Untangle реализована технология Re-Router (до этого мне с ней как то не доводилось встречаться), благодаря которой данная платформа безопасности  интегрируется в существующую сетевую топологию без каких либо дополнительных перенастроек инфраструктуры, путем заворачивания на себя всего трафика на уровне L2 протоколов. Примерно тоже самое происходит при уязвимости men-in-middle, когда машина внутри сетки производит так называемую атаку ARP spoofing, отвечая на все ARP broadcasts “ЭТО ЙА!” и тем самым беря на себя функционал центрального шлюза и вообще всех машин в сетке, так что в ARP таблице свичей все пакеты замыкаются на интерфейсе Untangle,и даже после падения платформы трафик не будет проходить до динамического изменения ARP таблицы.  Данная технология интегрирована в ядро, и в первом приближении не отключабельна, так что на форуме Untangle тамошние спецы рекомендуют относиться к ней как к данности, и в этой связи, в обязательном порядке, использовать на сервере два интерфейса, даже в случае необходимости использования одного- как в моем варианте VPN-сервера. Но в этом случае рабочий интерфейс надо делать внешним, а внутренний переводить в режим bridge и бриджевать его на внешний интерфейс
Настройка в админской части Untangle: Config -> Networking -> Internal Interface
Config Type: bridge
Bridge to: External (static)

Кстати таким же образом можно организовывать проброс трафика к внешнему шлюзу, но это уже другой разговор. В случае виртуальной машины, как у меня, я просто добавил в работающую конфигурацию еще один интерфейс, подтянул его встроенным detect’ом и привязал к внешнему интерфейсу, после чего лежащая сетка ожила в течении 30 секунд. Еще в течении 15 минут поднял VPN-сервер и настроил подключение. Самое приятное, что openVPN сервер сам генерит клиентскую часть, так что просто логинимся через бродилку к VPN-серверу, заходим внутрь и из настроек openVPN сервера, раздела Clients, говорим для определенного пользователя Distribute Client, после чего либо скачиваем его по приложенным ссылкам, либо отправляем его на email который можно вписать в форму отправки. Клиент после установки получает полностью настроенный OpenVPN клиент, не требующий уже никаких вводов логина и дополнительных настроек.

Рубрика: IT безопасность, Сети | Ваш отзыв »

Платформа безопасности Untangle

Начал ковыряться с новым продуктом Untangle, который мне посоватевал Евгена-сан, в качестве альтернативы VPN серверу, который я начал ковырять некоторое время назад, поскольку IPSEC от D-Link на замечательной железке DFL-210 отказывался подниматься, а Checkpoint UTM – клиент зажался приобретать.

Почитав немного про Untangle на их оффсайте, пришел в неописуемый восторг, поскольку производитель этого open-source продукта предлагает большое количество бесплатных, и платных модулей к своему решению, построенному на базе Debian GNU/Linux. Само по себе решение очень классное и представляет наборный шлюз, который поднимается в минимальной конфигурации и управляется через веб-консоль, при этом давая возможность сисадмину подключать и отключать те или иные модули, предлагаемые в виде дополнительного софта: spam blocker, phish blocker, spyware blocker, web filter, kaspersky antivirus, commtouch spam booster, wan failover, wan balancer, virus blocker, IPS, protocol control, firewall, captive portal, ad clocker, policy manager, directory connector, openVPN, attack blocker, bandwidth control, web cache и некоторое количество тулзов для управления.
Самое главное, что часть основных блейдов (по аналогии с checkpoint назову их так) предоставляется бесплатно- это фаерволл, openVPN, web filter lite, virus/spam/attack/phish/spyware blocker. Остальные можно поставить на 14дней и поковырявшись, прикупить себе уже в нормальное использование- меня например сразу заинтересовали bandwidth control и wan failover поскольку воротить такое руками муторно, а у производителя Untangle эти решения стоят по:
630 баксов на три года за bandwidth – позволяющий QoSить и лимитить юзверей по использованию канала;
126 баксов за три года wan failover, позволяющего построить полноценный isp redundancy, который у checkpoint например стоит полтора косаря за год;
модуль Каспера, позволяющий поднять полноценное сканирование на ходу от всевозможных угроз на всем многообразии протоколов, обойдется в 252 бакса на три года;
полноценный Web-filter выйдет в 630 грина на три года, при том что фильтрует по 53 категориям, на 20 языках, и держит в базе на данный момент около 450М веб-сайтов.
Управление порталом очень удобное и более того- он встает как на стандартную машину с минимальной конфигурацией: P4 Processor (или аналогичный AMD), 80 GB HDD, 2 NIC и 1 GB RAM; так и на VMware Workstation и ESXi- единственный момент что в случае ESXi надо заводить ручками диск и карточки, так как Untangle не понимает vmware дрова использующиеся платформой ESXi, поэтому пришлось драйв ставить BusLogic, а сетевухи e1000.  На Workstation же встал без проблем (кстати на том в 16 гигов), в течении буквально 10-15 минут элементарного инсталлятора.  Также на сайте компании, предлагается приобрести у них либо сервак, спецом заточенный под платформу Untangle, либо же специальную UTM’ку их же производства.

Но вот после установки на сервер, начались довольно интересные грабли, о которых я расскажу несколько позднее.

Рубрика: IT безопасность, Обзоры | Ваш отзыв »

VMware bridged mode vs kerio vpn client

Забавная тут ситуевина приключилась с одним сервисом, который я настраивал для клиента. Поднимал Help Desk- первоначально на своей машине в виртуальном окружении VMware Workstation, после чего установил на клиентскую машину VMware Player и перенес машину. Надо отметить что виртуальная машина крутится под Cent OS, а сервер под Win 2003, так что никаких особых проблем не ожидалось.

Но в процессе запуска- выяснилось что машинка не подхватывает IP адрес по DHCP, при работе в bridged mode, а при попытке задать статический IP я получал ругань на тему того, что данный IP уже используется, при том что данный адрес был однозначно свободен. Озадачившись данной проблемой проверил на всякий случай фаервол винды, но как оказалось он был отключен. Поковырявшись в меру возможностей в серваке и vmware, решил не озадачивать клиентского админа, а переставил Player на Workstation и попробовал поднять виртуалку в таком варианте. Но проблема осталась той же самой, при этом когда я переключил сетки в NAT вариант-  поднимался внутренний IP и все начинало нормально шуршать.

В итоге обратился к админу с описанием проблемы и предположением о том, что какая то тулза препятствует нормальному прохождению пакетов, выступая видимо фаерволом. Поковырявшись, админ сказал что обнаружил что на серваке зачем то был установлен, тысячу лет назад, kerio vpn client, который он благополучно снес. После данной манипуляции все зашуршало прекрасно, так что причина крылась именно в kerio vpn client который видимо как любой ipsec клиент имеет встроенный фаервол у которого имеются свои взгляды на прохождение пакетов. У клиента от checkpoint, например, таких проблем замечено не было.

Рубрика: IT безопасность, Сети | Отзывов: 2 »

Пространные рассуждения про VoIP трафик

Один из клиентов жадно захотел IP телефонию, в связи с чем начал понемногу рыть в этом направлении, но ощущение от знакомства с телефонизацией офиса по VoIP оказалось примерно такое же, как будто я заглянул в бездонный колодец, так что видимо ближайшие несколько недель у меня пройдут под эгидой SIP протокола.

Начну с того что я остановился сразу на платформе Asterisc, во первых потому что это наиболее популярный open-sourse, во-вторых потому что по данной платформе огромное количество полезной информации в интернете.
(more…)

Рубрика: Check Point, FreeBSD, Linux, Дела Одминские | Ваш отзыв »

Проброс портов на D-Link DFL-210

В процессе войны с поганейшим агрегатом из всех что мне доводилось встречать, под названием D-Link DFL-210, возникла необходимость попасть в сеть клиента, при том, что VPN я поднять на нем пока не смог, ибо соединение устанавливается, но как то не понятно реализована внутренняя маршрутизация, хотя я настраивал точно по имеющимся в инете ФАКам, и после установления соединения, пингуется только внутренний интерфейс. Но это тема для другого разговора, а пока я быстро решил поднять на коленке проброс RDP на внутренний хост, с тем чтобы быстро решить необходимую мне задачу.

На D-Link сайте нашел веселые картинки, показывающие как и что сделать, но поскольку мне их публиковать ломы. то распишу руками.
1. Логинимся на рутер
2. Создаем объект на который будем пробрасывать порты:
Objects -> Address Book -> InterfaceAddresses -> Add IP4 Address
Name: Имя-сервера
Address: IP-адресс сервера
3. Создаем правила проброса портов:
Rules -> IP Rules -> Add IP Rule Folder -> Входим в новую папку и Add IP Rule (две штуки)

3.1. Правило проброса:
Вкладка General:
Action: SAT
Service: rdp
Source (interface/network): any/all-nets
Destination (interface/network): core/wan_ip
Вкладка SAT:
Включаем кнопочка на Destination IP
New IP Address: Имя-сервера (из п.2)
New Port: 3389
Включаем чекбокс: All-to-One Mapping: rewrite all destination IPs to a single IP

3.2 Правило прохождения пакета:
Вкладка General:
Action: Allow
Service: rdp
Source (interface/network): any/all-nets
Destination (interface/network): core/wan_ip

По версии D-Link на этой торжественной ноте можно говорить: Configuration -> Save and Activate, но у меня после этого канал поднимался где то на полторы минуты, после чего соединение висло, а рутер говорил что он был перезапущен из-за ошибки: “Could not establish bi-directional communication after configuration upload”. Зная как работает D-Link, я пришел к тому, что второе правило, которое гарантирует прохождение пакета- не отрабатывает тот самый пресловутый  bi-directional , который D-Link обещает всем выбравшим в действии правила Allow, для того чтобы не создавать два правила туда и назад. Но це оказалась не фича, а бага, поэтому я добавил третье правило:

Вкладка General:
Action: Allow
Service: rdp
Source (interface/network): wan/Имя-сервера (из п.2)
Destination (interface/network): any/all-nets

После этого коннект поднялся нормально, даже не смотря на ту же самую ошибку, которая так и осталась висеть в причине перезапуска, но уже не мешала стабильности соединения.

Рубрика: Сети | Отзывов: 20 »

Настройка IP в CentOS

Настраивал себе систему в VmWare Player, после чего перенесли её на ESX Server, ну и по пути возникла необходимость, из дома, сменить на системе IP адрес и повесить дополнительный алиас на интерфейс. Поскольку настраивал центосину до этого исключительно из окошек Х, пришлось немного поморщить голову, но после прочтения официального мануала, все оказалось проще некуда.

Смена IP производится следующим образом:
Открываем файлец /etc/sysconfig/network-scripts/ifcfg-eth0 и смотрим что мы в нем имеем:

DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:0C:29:BC:B7:60
ONBOOT=yes

Собственно как понятно из файла- IP адрес он цепляет от DHCP сервера, хотя мне казалось что я его задавал лапками, поэтому отрубаем DHCP и меняем настройки на:

DEVICE=eth0
BOOTPROTO=static
HWADDR=00:0C:29:BC:B7:60
ONBOOT=yes
DHCP_HOSTNAME=crm_security.lan
IPADDR= новый_IP_адрес
NETMASK=255.255.255.0
GATEWAY= новый_шлюз
TYPE=Ethernet

После перезагрузки машины или рестарта сетевых служб, с помощью команды service network restart , система переподхватит новый IP адрес.

Теперь по поводу алиасов- там же где мы правили файло с сетевыми настройками, создаем файлик ifcfg-<if-name>:<alias-value> Единственно что надо учесть тот момент что алиас не может цеплять свой адрес по DHCP, поэтому следует задавать статический адрес, для чего создаем файл /etc/sysconfig/network-scripts/ifcfg-eth0:0 и в него прописываем следующие строки:

DEVICE=eth0:0
ONBOOT=yes
BOOTPROTO=static
IPADDR=алиас_IP
NETMASK=255.255.255.255

Если нужно добавить пул алиасов, скажем от 192.168.10.1 до 192.168.10.200, то сделать это можно либо создав 200 конфигурационных файлов для алиаса, либо описав весь пул адресов, для чего создадим файл /etc/sysconfig/network-scripts/ifcfg-eth0-range0 и внесем в него следующие строки:

IPADDR_START= 192.168.10.1 # первый IP в пуле
IPADDR_END= 192.168.10.200 # последний IP в пуле
NETMASK=255.255.255.255
CLONENUM_START=1 # число <alias-value> с которого будет начинаться пул
NO_ALIASROUTING=yes

Рубрика: Linux | Отзывов: 2 »

Ускоряем разрешение доменных имен через resolve.conf

Системный файл /etc/resolv.conf является файлом конфигурации процедур сервера доменных имен. В этом файле хранится информация об используемых DNS серверах, и этот файл перечитывается при вызове процедуры разрешения имен. В файл можно поместить информацию о трех DNS серверах, причем алгорит действия будет таким, что запрос всегда уходит на стоящий первым в списке сервер. В случае если он не отвечает в течении некоторого времени (по умолчанию 5 секунд), то запрос отправляется на вторичный сервер DNS, если он не отвечает, то запрос переходит к третичному серверу DNS. То есть по умолчанию система всегда использует первый из списка сервер, и обращается ко второму и третьему только в случае, если первичный сервер не отвечает.

Но в версии BIND 8.2 были добавлено некоторое количество новых опций, с помощью которых мы можем несколько ускорить работу разрешения доменных имен для нашего сервера:

Опиция timeout позволяет задавать время таймаута для присутствия в очереди запросов. По умолчанию этот параметр равен 5 секундам (максимально 30), так что если мы хотим ускорить отработку запроса, то выставляем этот параметр например на 2 секунды:
options timeout:2

Опция rotate позволяет использовать из списка доменных серверов все адреса, а не только первый, который может быть перегружен многочисленными запросами. Причем вторичный и третичный сервера используются только в случае отказа в обслуживании первого сервера. Поэтому с помощью этой опции мы можем разгрузить первичный сервер и отправить часть запросов на остальные сервера, указанные в resolve.conf
options rotate

Единственно что следует помнить о том что мы используем эту опцию, ибо в случае отладки, например почтового демона, мы никогда не будем знать какой из доменных серверов дал нам ответ на наш запрос. Еще один момент заключается в том, что данная опция будет полезна не всем программам, ибо часть из них, например ping, одноразово инициализирует резолвер и после разрешения имени выходит. Тогда как почтовые демоны, отправляющие многочисленные запросы разрешения доменных имен, будут использовать этот функционал.

Опираясь на все вышесказанное, resolve.conf  будет иметь следующий вид:

nameserver 1.1.1.1
nameserver 2.2.2.2
nameserver 3.3.3.3
option rotate
option timeout:2

Рубрика: Интернет | Ваш отзыв »