Собственно принципиальная схема работы следующая: FTP-сервер работающий под ProFTPd с хранением учеток в базе MySQL. К нему есессно подрублен контроль файлов и clamav. Сам сервак находится в DMZ за фаерволом, где на него подключены собственно порты 20, 21 и все выше 1024, для отработки пассива. Также ставим apache и открываем 80 порт на фаерволе, так как некоторым тупым бургам понадобится скачивать из локалок, а по своему опыту работы я неоднократно сталкивался с ситуацией когда у таких “васяток” банально нет чела который им мог бы объяснить как переключить ftp-клиента в пассивный режим, а факи которые им шлешь на почту, почему то не вспомогают. Вот для таких граждан необходимо также иметь web-сервер на котором завести некоторое количество папочек, запароленных на основе .htaccess.

Остальные пакеты это samba сервер, через который внутренние клиенты раскидывают файлы по папкам, с аутентификацией на уровне пользователей. Тут собственно можно сделать два варианта: либо разрешить прохождение smb пакетов из сетки через фаервол, либо засунуть сервак вторым интерфейсом в локалку, но это не особо хорошая идея, ибо хотя шансов что нам сломают ftp крайне мало, но все равно это получается лишний вход. В принципе можно его вывести вторым шнутом во внутренний DMZ, куда уже фильтровать пакетики от внутренних сетей. Такой ход более гиморный, но зато и наиболее спокойный.

Каждому юзверю, или отделу создается папка- желательно конечно с квотированием, иначе ftp-сервер превращается в неконтролируемую файлопойку похуже файл-сервера. В этой связи есть смысл подрубить еженедельную отправку на почту статистики вывода:
df -ah
du -ch -d 1 /ftphome

Теперь по защите всего это хозяйства, как я и сказал: на фаерволе делаем маппинг по портам, или же безусловную трансляцию, закрывая все порты ниже 1024 порта, кроме 20, 21 и 80 вовне, а внутрь от сервера пропускаем все или же только smb протоколы.

После чего все это дело настраиваем и радуемся жизни.

Попытка поставить или обновить не увенчалась успехом, так что стал копаться и обнаружил что оказывается Chrome не дружит с веткой RHEL5, и поддерживается только в версии RHEL6. Переставлять операционку мне уже не хотелось, так что пошукав по инету, нашел пофиксенный исходник Chromium переписанный Ryoji Kamei, который можно скачать с его сайта. Ставится ручками из yum, после добавления репозитория, но там собственно все расписано довольно подробно.

Но поскольку у меня операционка была сделана для определенных задач, то места оказалось не достаточно, так как требуется около 400Мб, и в итоге я, плюнув на все с прибором, полез смотреть работу данной прилады таки в винду. Тут конечно пришлось пошайтанить с проксями и впнами, чтобы гугель не совсем понял откуда пришел данный запрос, но вообщем установил я эту приладу  с данной страницы WebStore – надо отметить, что это бета-версия и весит она 20 метров. К тому же цепляется данная тулза к вашему аккаунту в системе google.

После установки на ваш компьютер, а точнее в вашу бродилку, данная прилада генерит уникальный 12ти значный код, на основе которого и происходит инициализация сессии. Код действителен порядка нескольких минут, в течении которых вы можете инициировать подключение, введя данный код в машине с которой необходимо подключиться. После чего вы получаете совместный доступ к компьютеру, по аналогии с TeamViewer, а целевой рабочий стол получает предупреждение что к нему подключился пользователь с мылом, которое вы указывали при логине в Google. Сама сессия строиться через рандомныйID@id.talk.google.com, и на самом деле довольно ощутимо подтормаживает, именно ввиду того что вы соединяетесь не peer-to-peer, а через средства Google. И вот тут встает большой вопрос, насколько данный вид связи безопасен и закрыт для третьих глаз, поскольку сообщение идет через ssl канал и канал Google-talk, но через гуглевые серваки: 74.125.43.126:443 и 173.194.35.227:19295.

Естественно, что помимо RDP вы получаете еще и видео-чат связь, но помнится еще Гомер изрек “Бойтесь данайцев, дары приносящих”, ибо SSL вещь хорошая, но памятуя о разговорах вокруг зарождения компании Google и участия в этом министерства обороны США, есть небольшое подозрение в том, что никто не мешает ставить на стороне данайцев в смысле компании Google так называемый ssl-декодер, который занимается дешифровкой сессии, преобразуя её в удобочитаемый, для “операторов”, формат. А учитывая что люди предоставляющие данный сервис, через бродилку Google Chrome пробивают практически любые защиты- у меня были пробиты: фаервол конечной машины, виртуальный NAT и фаервол хостовой машины, а также внешний рутер, то подобная тулза становится отличным способом влезть к вам в компьютер, и что самое главное – абсолютно добровольно с вашей стороны.

Благо данная сессия закрывается вместе с Chrome, или же нажатием на кнопку разорвать соединение, но теперь надо просимофорить что случается после её закрытия, так как в моем случае дополнительных сессий после закрытия сессии я не обнаружил, но тема с таким вот доступом к своему компьютеру, причем с полными правами, вплоть до выключения, не может не радовать.

Приехал в офис и стал ломать голову каким образом все коннектится, ибо естественно ни в какой интернет пакеты не уходят, а ломятся на внутреннюю адресацию. В итоге оказалось, после длительных лазаний под столами и трейсов пакетов, что все замучено через так называемый wi-fi мост, с которым я морочился на уровне совмещения рутеров Linksys. Тоже самое поднимается на беспроводных точках доступа от D-link, но тут все было завернуто через оборудование Ubiquiti Networks- американского производителя беспроводного оборудования для 4G и WiMax.

До этого момента я с ними не сталкивался, и оказалось что все те мосты что я делал на указанном оборудовании- просто детский лепет по сравнению с кирогазами Ubiquiti, поскольку они используют их технологию AirMax Technology, позволяющую кидать канал в 100Мб на расстояния до 50 километров. Естественно что эти нереальные расстояния требуют специальных антенн и еще более специальных вышек, для того чтобы сигнал не гасился препятствиями, но расстояние в 2-3 километра, можно покрыть за счет стандартных передатчиков, установленных в зоне прямой видимости.

Другое дело, что для того чтобы все это реально заработало и было к тому же законно, то необходимо приобретать сертифицированное оборудование и получать разрешение гостехнадзора на организацию беспроводного моста.  Хотя вроде бы это можно обойти, если поднимать оптический мост, на лазерных передатчиках, но я что то новых решений найти не смог, кроме древнего Unlike OmniBeam 2000/4000, датированного началом 2YK. К тому же в России как я понимаю достать его, в отличии от оборудования Ubiquiti, практически невозможно. Так что вернемся к Ubiquiti Networks.

На их сайте представлено большое количество оборудования, но для наших целей построений Wi-Fi моста на стандарте 802.11 a/b/g подходит серия NanoStation или же NanoStation Loco, представляющие собой устройства с ethernet интерфейсом 10/100 BASE-TX, коим они подключаются к проводной локальной сети и способны устанавливать беспроводной мост на расстояния до 20 километров со скоростью 25Мб/с, что для терминального подключения, или прокинутого канала интерент в удаленный фоис- более чем достаточно. Также имеется более совершенное устройство Ubiquiti Rocket позволяющее поднимать скорость передачи данных до 100Мб/с.

По деньгам подобное решение получается примерно следующим:
Ubiquiti Rocket M5 стоит в районе 9к рублей, за два передатчика
Ubiquiti NanoStation обойдется где то в районе 6-7к рублей за два передатчика
Направленная антенна Rocket Dish 5G обойдется по 9к за антенну, то есть 18к рублей за прием-передачу
Ну и желательно чтобы в комплект входила грозозащита, предохраняющая активное оборудование от атмосферных разрядов, например Ethernet РГ4 PoE – районе 800 рублей за штуку

Если у нас расстояние небольшое, то мы вполне можем ограничиться парочкой NanoStation или NanoBridge с антигрозовой защитой (без приобретения дополнительных антенн), и подобное решение обойдется всего в 10-12к рублей по российским ценам за оборудование. Если же заказывать у производителя оборудования Ubiquiti Networks, то полагаю что возможно уложиться и вообще в 5-6к рублей.

Стал ковыряться и обнаружил в логах ipmon интересные записи:
Date em1 @0:38 b LAN_IP,port -> VoIP_server,port PR tcp len 20 60 -S OUT OOW
Date em1 @0:58 b VoIP_server,port -> LAN_IP,port  PR tcp len 20 81 -AP IN OOW NAT
Date em1 @0:58 b VoIP_server,port -> GW_LAN_IP,port  PR tcp len 20 81 -AP IN OOW NAT

Собственно самое интересно в этом флаг OOW, который переводится как out of window, и является багом фильтарции пакетов для которых правило идет со статусом keep state, то есть в момент установленного уже соединения, которое фаервол должен пропускать, он вдруг решает, что это неожиданный пакет и банит его именно по причине OOW. В моем случае- все эти прохождения пакетов были разрешены, и все блокировки были именно по флагу OOW.
Бороться с этим можно двумя способами: либо пропатчив фаервол, либо исключая из правила флаг keep state. Я предпочел последний, тем более что у меня баг срабатывает только на VOIP трафик, тогда как остальной продолжает ходить с флагом keep state.

Самое унылое во всем этом, что судя по инетам данная проблема была пофиксена еще на версии 1.3b5, тогда как у меня в данный момент используется:
# ipf -V
ipf: IP Filter: v4.1.28 (400)
Kernel: IP Filter: v4.1.28
так что видимо с оказией надо будет подумать об обновлении на текущую версию 5.1.0

Кстати просмотреть пакеты дропающиеся по out of window можно с помощью команды:
# ipmon -oI
Тогда как увидеть список загруженных правил можно с помощью команды:
# ipfstat -nio

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

В первую очередь право раздачи удаленных доступов возложить на руководство отделов, а лучше компании, с тем чтобы избежать последующих воплей- как же ты мог допустить!!! Организации всех доступов только по письму начальника отдела. Никаких за шоколадку, на вечер, дочка болеет и прочей слюнявой шняги, ибо если что, то иметь будут персонально вашу задницу.

Крайне желательно, чтобы пользователи не имели вообще никакого доступа к сети, кроме терминального соединения со своей машиной, на которую бы они входили зная свою учетную запись, и IP адрес компьютера, с тем чтобы левому человеку было бы сложно отсканить сетку. В этой связи необходимо создавать базу пользователей и соответствия логинов (и как следствие сертификатов) и IP адресов машин, и поскольку мы заранее знаем какой IP получит сотрудник, то и на фаерволе на виртуальном интерфейсе разрешать прохождение не все ко всем, а определенный IP удаленного клиента, на определенный IP компьютера внутри сети. И только по RDP. Никаких 135, 137 и т.д портов. Ну или же, если у вас в сети есть терминальный сервер, то всех пользователей – на терминальный сервер.

Как я это не ни люблю, но необходимо вести полное логирование безопасности- входов в домен и выходов, а также действий внутри домена.

Естественно, что для удаленного использования, оптимально было бы задействовать двухфакторную аутентификацию, основанную не только на шифровании на основе сертификата, но и на вводе пароля. Ибо если пользователь профуфыкает сертификат, то между логином и доступом в защищенное пространство сети, остается прокладочка в виде пароля. Для этого, для генерации сертификата пользователя, следует использовать команду:
# ./build-key-pass vpn-client
естественно не забывая проделывать все необходимые для генерации процедуры. Но тут мы можем упереться в пользователей не желающих вводить два пароля подряд- их конечно понять можно, но тут уже зависит от вашей настойчивости. Мне, если честно, мои нервы, в этом плане, всегда были дороже.

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

Надеюсь, что указанные шаги, помогут вам повысить безопасность вашего VPN-сообщества, без погружения в пучину админской паранойи.

# cd /usr/ports/security/openvpn
# make && make install
# make clean
в логе инсталяшки видим напоминалку о том, что надо бы врубить работу пакета в /etc/rc.conf, синтаксис которого описан в файле /usr/local/etc/rc.d/openvpn. В этой связи добавляем в /etc/rc.conf следующие строки:
openvpn_enable=”YES”
openvpn_if=”tun”              # driver(s) to load, set to “tun”, “tap” or “tun tap”
openvpn_configfile=”/usr/local/etc/openvpn/openvpn.conf”
openvpn_dir=”/usr/local/etc/openvpn”
Поскольку указанных директорий и файлов у нас нет, то создаем их:
# mkdir /usr/local/etc/openvpn
# touch /usr/local/etc/openvpn/openvpn.conf
а также всю внутреннюю структуру папки /usr/local/etc/openvpn
# mkdir /usr/local/etc/openvpn/ccd
# mkdir /usr/local/etc/openvpn/keys

Надо отметить, что в работе openvpn использует openssl и его структуру, так что если мы планируем еще тщательнее защищаться, то нам надо весь фарш из папки /etc/ssl переносить в нашу папку /usr/local/etc/openvpn/ , включая как папки certs, crl, serial, private, так и  базы данных сертификатов serial и index.txt. Поскольку я бился на удаленной системе посредством ssh, а переться в офис мне совсем не хотелось, то я оставил все на месте, минимизировав перенастройку openssl.

После этого переходим к созданию сертификатов RSA, для чего следуем в папку /usr/local/share/doc/openvpn/easy-rsa/2.0 где редактируем файл /usr/local/share/doc/openvpn/easy-rsa/2.0/vars где прописываем свои настройки, чтобы этого не делать при создании сертификатов:
export KEY_COUNTRY=”RU”
export KEY_PROVINCE=”RF”
export KEY_CITY=”Moscow”
export KEY_ORG=”Peredelka”
export KEY_EMAIL=”admin@odminblog.ru”
export KEY_CN=vpn-server
export KEY_NAME=odmin_root
export KEY_OU=Adminz

После этого надо дать права на исполнение для некоторых файлов:
# chmod +x whichopensslcnf vars clean-all build-ca pkitool build-key-server build-key build-dh
после чего можно инициировать создание файлов ключей (если вы используете bash, то первую команду можно опустить):
# sh
# . vars
# ./clean-all
# ./build-ca
где собственно в диалоге уже будут прописаны наши данные, так что стоит ограничиваться только нажатием энтера.
Теперь создаем сертификат X.509 для нашего сервера, который мы указали в KEY_CN=vpn-server, при этом нам будет предложено задать пароль для обмена ключами, а также надо отметить, что переменную An optional company name [] следует задавать той же что и была указана для создания корневого сертификата Organization Name (eg, company). После этого подписываем наш сертификат своими силами.
# ./build-key-server vpn-server
Создаем сертификат X.509 для клиентской части, при этом имя клиента KEY_CN мы указываем отличным от имени сервера, например vpn-client.
# ./build-key vpn-client
Теперь генерим ключи Диффи-Холмана, которые будут использоваться при хендшейках и обмене ключами:
# ./build-dh
генерация займет некоторое время, но она идет на автомате. На последок создаем файл для TLS аутентификации:
# openvpn –genkey –secret keys/ta.key
после чего в папке keys смотрим полученные ключики, которые соотносятся следующим образом.

Ключи сервера:
ca.crt , vpn-server.crt , vpn-server.key, dh1024.pem, ta.key
Ключи клиентской части:
ca.crt , vpn-client.crt , vpn-client.key, ta.key
Серверные ключики копируем из папки создания в папку openvpn, созданную нами первоначально  /usr/local/etc/openvpn/keys, после чего переходим к редактированию файла конфигурации /usr/local/etc/openvpn/openvpn.conf
### openvpn.conf  ###
dev tun0
port 5656
proto udp
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/vpn-server.crt
key /usr/local/etc/openvpn/keys/vpn-server.key
dh /usr/local/etc/openvpn/keys/dh1024.pem
tls-auth /usr/local/etc/openvpn/keys/ta.key 0
client-config-dir ccd
# задаем подсеть сервера VPN
server 172.16.0.0 255.255.255.0
# Прописываем маршрутизацию на внутреннюю сетку (у меня 192.168.0.0)
push “route 192.168.0.0 255.255.255.0″
# Маршрутизация для клиента
route 172.16.0.0 255.255.255.252
tls-server
tls-timeout 120
comp-lzo
auth MD5
cipher BF-CBC
keepalive 10 120
max-clients 100
user nobody
group nobody
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3
#########
Создаем файл c именем клиентского хоста, заданным при генерации сертификата:
# echo “ifconfig-push 172.16.0.2 172.16.0.1″ > /usr/local/etc/openvpn/ccd/vpn-client
при этом у нас получается подсеть для клиента с маской 255.255.255.252 которую мы указывали в файле настроек, так что в нашем случае это будет туннель с клиентской частью 172.16.0.2, серверной частью 172.16.0.1, широковещательным адресом 172.16.0.3 и адресом сетки 172.168.0.0, так что последующих клиентов эта запись будет иметь вид (в файлах для их имён и сертификатов):
ifconfig-push 172.16.0.6 172.16.0.5
ifconfig-push 172.16.0.10 172.16.0.9
ifconfig-push 172.16.0.14 172.16.0.13
если кто не понял то адресация IP идет +4

также создаем файлы журналирования:
# mkdir /var/log/openvpn
# touch /var/log/openvpn/openvpn-status.log
# touch /var/log/openvpn/openvpn.log
Открываем на нашем фаерволе входящий трафик на порт udp/5656 для того чтобы внешние клиенты могли подрубаться к нашему VPN серверу, а также разрешить прохождение трафика через интефрейс OpenVPN и внутресетвой трафик.

Теперь копируем сертификаты клиентской части на внешний носитель, так как они нам буду нужны на локальной машине при настройке удаленного клиента.

Вроде как теперь все должно работать, так что для того чтобы все запустилось- перезапускаем сервер, и настраиваем клиента на локальной машине.
На локальной машине, ставим пакет OpenVPN, который можно взять с офф.сайта. После этого сливаем клиентские файлы: ca.crt , vpn-client.crt , vpn-client.key, ta.key в папочку C:\Program Files\OpenVPN\config (или той куда ставили клиента) и создаем в ней файл клиентских настроек openvpn.ovpn, в который прописываем следующие параметры:
#### openvpn.ovpn ###
dev tun0
proto udp
# внешний IP VPN-сервера
remote X.X.X.X
# порт подключения
port 5656
client
resolv-retry infinite
ca ca.crt
cert vpn-client.crt
key vpn-client.key
tls-client
tls-auth ta.key 1
auth MD5
cipher BF-CBC
ns-cert-type server
comp-lzo
persist-key
persist-tun
verb 3
#########

После этого запускаем клиента и он автоматом ломится на наш сервак и устанавливает сессию.

Собственно на этом можно было бы закочить, если бы в сети не жили беспокойные парни, которым обязом надо поставить себе Windows 7, да еще и x64. Для запуска OpenVPN под Windows 7 следует ставить версию openvpn-2.1_rc19 (или какую нить другую от _rc15). Выкачиваем её и щелкаем правой кнопкой на инсталлер: Свойства -> Совместимость -> Запустить пакет в режиме Windows Vista , а также выставить галку “Выполнять эту программу от имени администратора“. После этого можно запускать инсталлер, который встанет без проблем, после чего на значке OpenVPN GUI надо будет также выставить, что запускать его следует от админа.

Для особо беспокойных, живущих в режиме параноик-мод, файлы ключиков, можно записать например на шифрованный диск или внешний носитель, и запускать клиент только после того как диск будет подмонтирован, тогда в openvpn.ovpn , пути настроек будут выглядеть следующим образом (сертификаты расположены в папке keys):
ca  “X:\\keys\\ca.crt”
cert “X:\\keys\\vpn-client.crt”
key “X:\\keys\\vpn-client.key”
tls-auth “X:\\keys\\ta.key” 1

При установке клиента под Линух, файл конфигурации клиента openvpn.conf должен лежать в папке /usr/local/etc/openvpn , местоположение ключиков задаем естественно из него.

На тему настройки клиента под Mac я видимо отпишусь позже, так как мне это поставили на вид, но настраивать я не стал, так как макаки у меня под рукой нет, а убивать полдня на поиск имиджа по виртуалку меня заломало. Так что как только мне выдадут подопытную обезьяну, то отпишусь по результатам.

Хотя это конечно не безопасно, особенно исходя из концепции параноидальности на сетевом экране, тем более что не далее как в этом феврале была найдена уязвимость BIND 9 ветки, приводившая к DoS севера имен, при трансфере зоны или динамическом обновлении, но тем не менее пропатчив BIND и открыв его только вовнутрь сетки, решил что пользовать можно.

И вот в процессе настройки, когда вроде бы named резолвился для localhost но почему то не хотел стартовать на внутреннем интерфейсе, я решил раскомментировать строку в named.conf содержащую следующее выражение:
query-source address * port 53;

после чего решил добавить страку разрешающую обращение к фаерволу из внутренней сетки по 53 порту, и перегрузил сервак. После чего ssh у сервера интеллигентно отпал. Точнее сервер крутился и при обращении к нему выдавал запрос имени пользователя, но после его ввода, вместо ожидаемого в ответ запроса пароля, просто отключал пользователя. Поскольку сервер был удаленный, я звякнул тамошнему админу, и попытался его руками все вернуть обратно, но замена новых правил фаервола на новые- ничего не дала. Так что пришлось пилить в контору.

Изначально я полагал, что допустил в синтаксисе правил какую то ошибку, из-за которой правила не догружались до конца, но оказалось что таблица правил фаервола была загружена полностью. Да и ssh висел на порту, а вот named почему то отсутствовал. Попытка его стартануть не увенчалась успехом, так что я полез в логи, где обнаружил что прописал в named.conf фалы для зоны “.” дважды, точнее я то прописал один раз, не заметив, что они уже были обозначены. Что и приводило к падению демона named. Но что еще более поразительно- это же и приводило к нестабильной работе сервера ssh, отрубавшего логин к серверу.

Судя по всему, в случае падения демона named, резолвить имена подключений не получалось, так как в /etc/resolv.conf стоял только 127.0.0.1, и по этой самой причине соединение и рубилось на корню.

Так что на всякий случай добавил в /etc/ssh/sshd_config строчку отрубающую резолв имен: UseDNS no , хотя, в принципе, можно было бы и добавить дополнительных DNS серверов в resolv.conf

Собственно памятуя о том, что в XP это делалось через патч драйвера termsrv.dll (если вероисповедание не позволяет использовать  какую нить GPL вроде UltraVNC или TightVNC), который был выдернут из XP SP2 beta, где ограничение на количество подключенных столов отсутствовало, то я решил погуглить на эту тему, и довольно быстро нарыл такую же приладу для Windows 7, которая собственно патчит вышеозначенную утилиту после чего многопользовательский вход через терминал становится доступен для администратора системы и группы пользователей удаленного рабочего стола. Собственно прилада для версии 32 бита и версии 64 бита. Причем судя по всему она использует те же библиотеки, так как на форумах народ пишет, что пользовали как раз старую библиотеку.

Скачиваем, запускаем, после чего перегружаем машину. Естественно что сделать это из управления сессией мы не можем, поэтому прибегаем с консоли управления, откуда просто вводим:

shutdown -r  (не перепутать с ключиком -s, иначе нам придется пилить в дальний офис)

После этого получаем полноценный сервер терминалов, но по крайней мере в XP количество максимальных соединений было ограничено 3 конкурирующими сессиями, так что разгоняться больше 3-5 пытаться не стоит. Единственно, что если мы хотим мочить удаленных пользователей из под админа терминальной машины, нам необходимо отключить контроль учётных записей UAC в Windows.

А вот тут начинается самое интересное, так как в функционале удаленных рабочих столов Windows Server 2008+ появился интересный функционал Terminal Server RemoteApp, позволяющий запускать удаленные приложения на клиентской машине, без использования терминальной консоли, что позволит нам снизить нагрузку на трафик, так как нам не придется отрисовывать все плюхи, а также обрезать дикому юзверю весь иной функционал. Собственно имея все это в Server 2008 можно было бы предположить что этот же функционал доступен и на Windows 7. Только в случае рабочей станции он отключен, и его необходимо подключить в реестре, для чего, на удаленной машине (уже сервере терминалов), идем в ветку реестра:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList
где меняем значение параметра fDisabledAllowList с 0 на 1, после чего в этой же ветке создаем папку с названием Application (вроде можно и произвольное название) в которой создаем подпаки приложений доступных для запуска с удаленного сервера терминалов, путем создания строковых параметров:
Name – имя приложения
Path – директория приложения (именно директория, а не полный путь до файла)

После этого терминалку перегружаем и переключаемся на настройку нашей локальной машины:
запускаем терминального клиента mstsc , настраиваем адрес нашего терминального сервера, подключение, и затем в настройке расширенных параметров сохраняем настройки сессии с расширением *.rdp, после чего открываем этот файл блокнотом и добавляем или изменяем следующие строки:

remoteapplicationmode:i:1
remoteapplicationprogram:s:имя бинарника приложения
disableremoteappcapscheck:i:1
alternate shell:s:rdpinit.exe

В имени бинарника надо писать имя запускающего  файла, прописанного в строковых параметрах. Самое интересное, что этот способ дает возможность запускать приложения Windows 7 Pro и выше как на удаленных машинах под управлением Windows 7, так и под управлением Windows XP SP3. Для меня пока не функционально, но для того чтобы например ограничить доступ удаленных юзеров к их рабочим столам- весьма интересно.

Тогда приходится влезать в это болото, которое называется маршрутизация средствами Windows платформ. Для начала посмотрим что  у нас прописано в таблице маршрутизации на сервере. Входим в терминальную консоль cmd и даем команду:
> route PRINT
которая нам высветит список имеющихся в системе интерфейсов, таблицу маршрутизации и постоянные маршруты. Кстати точно эту же картинку можно получить и командой:
> netstat -rn
Теперь собственно мы можем добавить статический маршрут, средствами командной строки. Предположим что нам надо срутить пакеты в сеть 172.16.0.0/24 через внутренний маршрутизатор 192.168.10.250, для чего задаем следующую команду:
> route add 172.16.0.0 mask 255.255.255.0 192.168.10.250 if 1
на самом деле можно со спокойной совестью опустить, маршрут подцепится и без этого, просто пакеты будут рутиться через внутренний интерфейс 127.0.0.1. Для того чтобы удалить данный маршрут достаточно сказать:
> route delete 172.16.0.0
При добавлении машртура мы можем получить загадошное сервисное сообщение “Запрошенная операция требует повышения”, для чего правой клавишей шелкаем в иконку командной строки и говорим “запуск от имени администратора”.
Но вся беда с том, что такие маршруты живут до следующей перезагрузки, поэтому нам необходимо сказать чтобы маршруты сохранялись на потсоянной основе, для чего задаем ключик -p:
> route -p add 172.16.0.0 mask 255.255.255.0 192.168.10.250

Собственно для меня это наиболее удобный вариант, так как не требует ковыряния с системе, да и подходит как для Windows Server, так и для простых рабочих станций под управлением виндусни; но особо беспокойные умы могут  воспользоваться на MS Server службой Network Policy and Access Services, для чего идем в Диспетчер сервера -> Роли -> Добавить роли -> Службы политики сети и доступа -> Маршрутизация (автоматом добавится Служба удаленного доступа) после чего уже в оснастке управления маршрутизации через правый клик на имени сервера включаем машрутизацию и, зайдя в раздел Статические маршруты прописываем необходимые нам маршруты. Там же можно настроить и политики прохождения пакетов (вкладка Основное, свойства интерфейсов), а также динамическую маршрутизацию, путем добавления RIP или IGMP протоколов.

Возникает стойкое ощущение того, что Microsoft прикупил и этот сервис также, но посмотрим как пойдет дальше. Хотя помимо мелкомягких мы знаем еще одну компанию СУП, чьи админы также любят проводить  технические работы на живом железе.

Так что не боясь предстать капитаном очевидность в этот раз я распишу как организовать программный маршрутизатор средствами FreeBSD. И хотя писалось все это еще под 4.2, но тем не менее и под 7.4 все эти же рецепты применимы, разве только с той разницей, что все пакеты отличаются версиями с большую сторону. Сказать откровенно, я предпочитаю программные маршрутизаторы за их дешевизну, простоту и быстроту в настройке, поскольку для программного маршрутизатора сгодится любая древняя машинка, главное чтобы в ней была возможность поставить дополнительные сетевухи. При этом программный маршрутизатор отличается от аппаратных аналогов тем, что произведя один раз настройку маршрутизатора вы следующий настроите уже за полчаса, а не будите копаться в мануалах нового для вас агрегата, купленного клиентом с оказией, не понимая почему це фича вдруг оказалась багой. К тому же вменяемый аппаратный маршрутизатор стоит не малых денег и вполне сопоставим по стоимости с хорошим компом, который помимо того что будет с сотни раз мощнее, также при этом сможет, естественно при желании, стать принт-сервером, фаерволом, проксей, поточным антивирем и еще чем угодно, и что самое основное- это решение маштабируемое, то есть добавление нового интерфейса сопряжено с гораздо меньшими затратами, нежели при попытке расширения аппаратного маршрутизатора, главное подобрать материнку с 2-3 слотами под сетевуху, ибо найти две интегрированные не проблема. И естественно формула скорость работы/цена для программного маршрутизатора будет на порядки ниже аппаратного, так как стоимость гигабитного маршрутизатора уже будет сопоставима с покупкой мощного сервера для офиса. Ну это просто вода относительно того за что я люблю программные рутеры, а теперь собственно перейдем к самой настройке маршрутизатора.

Для начала устанавливаем систему FreeBSD 7.4 и настраиваем её в соответствии с нашими требованиями, то есть можно настроить как защищенную систему если она торчит в инет, или служит для защиты серверной фермы от локалки; ну а ленивцы могут ограничиться просто установкой нужных пакетов, если она будет служить просто для маршрутизации пакетов между сетями внутренней сети предприятия.

Собственно для начала имеем две сетки: 192.168.0.0/24 (основная) и 192.168.10.0/24 (дополнительная) которые нам и надо совокупить посредством нашего настроенного сервера FreeBSD, в который мы же загодя воткнули две-три-четыре и более сетевых карт (максимум который у меня прекрасно существовал было 5 сопряженных сетей, не считая вирутальных интерфейсов). Предположим что для сетевых интерфейсов мы выбрали IP адреса: 192.168.0.1 и 192.168.10.1

Смотрим что за интернерфейсы установлены в системе:
# ifconfig
тут нам главное понять какой интерфейс какой, для чего не плохо было бы ознакомиться с чипами карт. Порядок интерфейсов обычно идет от проца к периферии, а у дополнительных интерфейсов в зависимости от нумерации слотов, возрастая от видюхи. Но проверить все это можно эмперическим путем просто воткнув рабочий кабель в систему, посе чего интерфейс перейдет из статуса status: no carrier в status: active. Предположим у нас в системе два интерфейса rl0 и rl1.
Поняв какие интерфейсы будем сопрягать, идем в /etc/rc.conf и добавляем необходимый интерфейс, так как там уже должен присуствовать один из интерфейсов, если в процессе настройки системы FreeBSD мы поднимали сетку.
##### /etc/rc.conf #####
ifconfig_rl0=”inet 192.168.0.1 netmask 255.255.255.0″
ifconfig_rl1=”inet 192.168.10.1 netmask 255.255.255.0″
#####################
Чтобы поднять теперь интерфейс, выполним
# /etc/netstart
Второй интерфейс rl1 ожил и теперь пингуется из подсети 192.168.10.1, но для того чтобы сервер настроить как маршрутизатор необходимо в ядре разрешить пересылку пакетов между пакетами, за что отвечает парметр net.inet.ip.forwarding. Его значение в системе в данный момент:
# sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 0
где значение 0 означает что маршрутизация запрещена, поэтому для включения функционала маршрутизации, нам необходимо присвоить этому значению 1, для чего выполняем:
# sysctl net.inet.ip.forwarding=1
net.inet.ip.forwarding: 0 -> 1
Теперь настройка маршрутизации завершена и маршрутизатор будет фурычить до перезагрузки системы, после чего значение net.inet.ip.forwarding переключится обратно в 0. Для того чтобы избежать этого добавляем в файл /etc/rc.conf следующую строку:
gateway_enable=”YES”
после чего уже безбоязненно можем перегрузить машину.
При такой схеме наш маршрутизатор будет рутить только сопряженные с ним сети, представленные интерфейсами, или же алиасами на интерфейсах, в том же случае когда у нас в сети уже существуют маршрутизаторы, прикрывающие еще какие то сети, то тогда поднимаем на нашей машине статическую таблицу маршрутизации. Делается это также в файле /etc/rc.conf
##### /etc/rc.conf #####
static_routes=”network1 network2 network3″
route_network1=”-net 10.10.15.0/24 192.168.0.25″
route_network2=”-net 172.168.10.0/24 192.168.0.25″
route_network3=”-net 192.168.168.0/24 192.168.10.111″
#####################
то есть мы задаем названия маршрутов, которые дальше выводим в виде сетки, и внешнего, для нашего маршрутизатора, интерфейса шлюза.
Также в случае использовании настроенного сервера FreeBSD в качестве внутреннего маршрутизатора, необходимо на внешнем шлюзе, заданном для рабочих станций и серверов сети дефолтным маршрутом, поднять маршрутизацию на внутреннюю сеть задав маршрут в 192.168.10.0, через 192.168.0.1. На самом деле тут обычно и возникает самый косячный момент, особенно в случае использования интернет шлюзом аппаратных фаерволов типо D-Link, у которых вроде функционал рутинга имеется, но чтобы настроить удаленный маршрут надо долго и упорно танцевать с бубном, так что гораздо проще для нашего уже настроенного маршрутизатора задать дефолтовым маршрутом интернет-шлюз, а все машины предприятия завернуть на него- это добавит лишний хоп, но уберет проблему настройки маршрутизации на сторонних серверах.

И вот собственно при попытке их вытащить с многострадального хостинга, выяснилось что сделать это не представляется возможным, так как при трансфере стандартным leechftp которым я пользовался стопяцот лет, русские названия превращаются в нечитабельную крокозябру, так что трансфер по ftp на русском превратился в серьезный головняк, так как выяснять какие файлы какие и потом их переименовывать (как мне посоветовали веселые разработчики) было реально сизифовым трудом. Опять же загоном сайта в архив эта проблема не решалась, так как файлы в архиве тоже были со сбитой кодировкой. Поэтому пришлось задуматься в чем проблема того что скачать ftp на русском не представляется возможным.

А оказалось что проблема в том, что кодировку utf-8 поддерживает весьма небольшое количество ftp-клиентов, так что следующим этапом стал поиск удобоваримого клиента, в резьтате чего сформировался следующий список:

SmartFTP
FileZilla (вроде как в варианте патченной версии)
плагин к FireFox- Fireftp
Lftp
FTPRush

Из них я попробовал несколько штук, и остановился на SmartFTP- правда к сожалению данный клиент является коммерческим, что подразумевает что за него надо бы платить денег. Так как с FileZilla у меня возникли таки траблы с переносом файлов, Fireftp эпизодически задумывалось о судьбах рунета, в вот SmartFTP работал отлично, так что в данный момент я использую исключительно его, в том числе и для работы с файлами по ftp на русском, поскольку решать проблему русскоязычных файлов никто не захотел. SmartFTP оказался отличным ftp-клиентом, который помимо возможности скачать ftp на русском позволяет выполнять все необходимые для ftp-клиента функции: качать, переносить директории и файлы без трансфера на удаленную машину, редактировать удаленные файлы, менять права и многое-многое другое. Единственный вскрывшийся глюк оказался в том, что при редактировании файла на локальной машине- следует убирать выделение с файла, так как он, при попытке сохранения изменений, будет удален.

В итоге ребутнули сервак 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 клиент, не требующий уже никаких вводов логина и дополнительных настроек.

Почитав немного про 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’ку их же производства.

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

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

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

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

Погуглив, почитав и пообщавшись по форумам с людьми, выявил для себя следующие моменты:
под платформу лучше всего использовать отдельный сервер, поскольку на виртуалке могут возникнуть траблы как с трафом, так и с производительными мощностями, особенно в случае если трафик от провайдера приходит в одном кодеке, а в офисе мы используем другой;
для дедика вполне хватит сore2 или core i3, как минимум с 2Гб оперативы на борту, так что на первое время вполне сгодится какой нить десктоп, если руководство жмет деньги на приобретение полноценного сервера;
использовать лучше кодек g711, при этом под каждый активный разговор отводится порядка 64 кбит/с, так что умножаем на это число количество входящих линий и получаем необходимую под VoIP полосу пропускания;
использовать можно FreeBSD или CentOS, хотя тут мнения разделяются, как собственно и в любой холиваре- единственное что я пока осознал, что обновления для платформы Asterisc выходят на Cent OS с большим опозданием, по сравнению с фрей;
для сервака лучше использовать внешний, отдельный IP, поскольку при пробросе SIP портов (5060 udp/tcp и выделенный upd диапазон для траффа) через NAT могут возникнуть проблемы (в моем случае точно, поскольку на D-Link’e эти проблемы возникли даже при пробросе rdp);
можно использовать аналоговые телефоны, но для них придется докупать либо специальную карту в сервер, чья стоимость составляет около 2к грина, либо же VoIP шлюз, который также стоит в районе 200 грин;
цены на IP-телефоны начинают от 4к за более менее нормальные аппараты, так что имеет резон использовать бесплатные софтовые клиенты, так как в этом случае контора попадает только на гарнитуры, чья стоимость составляет от 700 рублей за штуку;
если планируется иметь факс, то его лучше вешать на аналоговую линию, поскольку для передачи факсимильных сообщений требуется идеализированный траффик, в противном случае факсы будут приходить крайне отстойного качества;
сама платформа Asterisc метит траффик, так что использовать для него приоритезацию траффика QoS не составляет проблемы;
некоторые провайдеры имеют свойство зафильтровывать SIP траффик, чтобы потенциальные клиенты не пользовались сторонними сервисами, так что придется либо брать данный вид трафа у этого провайдера, либо же каким то образом договариваться с ним;
в этом же ключе я пробивал возможность использования VoIP со шлюзом Checkpoint, который я уже успел несколько подзабыть за прошедшие полгода, в связи с чем выяснилось несколько моментов: в стандартной поставке Checkpoint FW будет корректно обрабатывать и пропускать VoIP траффик, и даже фильтровать его по политикам безопасности (при заведении объекта шлюза VoIP), а также симафорить с помощью IPS блейда, имеющего стандартными несколько сигнатур для проверки VoIP траффика. Но есть хочется чего то большего, то необходимо приобретать блейд  Voice over IP (VoIP) Software Blade, который этих сигнатур имеет большее количество и к тому же может не только проверять VoIP траффик, но и при необходимости вносить изменения в пакеты: транслировать адреса или вносить исправления в заголовки. Единственный момент здесь в том, что данный блейд встает только на версию R65, то есть весьма и весьма древнюю, так как на новых версиях SPLAT данный блейд не работает.

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

На 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

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

Смена 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

Но в версии 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

Поскольку я обновлял часть из них буквально перед уходом из конторы, то и версии прошивы были различными. Здесь следует оговорить несколько моментов:

Начиная с версии прошивки I.08.74 устройство не поддерживает FEC trunks (Cisco Systems’ Fast EtherChannel for aggregated links) и CDP (Cisco Discovery Protocol). Вместо них введены, базирующиеся на IEEE стандарте, протокол LACP aggregated links (предназначенный как раз для организации транков) и протокол LLDP для оповещения по сети и сбора информации о соседних устройствах.

Для апргейда до актуальной версии прошики I.10.xx необходимо иметь как минимум версию I.08.07, если она ниже, то сначала обновляемся до неё, после чего вторым обновлением поднимаем прошивку до I.10.xx. Версия промежуточной прошивки может отличаться у разных моделей.

Конфиги созданные с помощью прошики I.10.65 или новее, не поддерживаются предыдущими версиями прошивок, так что в случае варианта даунгрейда устройства, все придется настраивать заново.

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

Перепрошить дейвайс можно двумя способами: через XMODEM соединение, и загрузкой с TFTP сервера. Работу с TFTP я рассмотрю позднее, ибо она требует настроить TFTP сервер, а пока попробуем перепрошить с помощью соединения  XMODEM. Сам XMODEM является простейшим протоколом передачи данных и отлично зарекомендовал себя еще на BBSках в далеких 70х годах. Не буду вдаваться в его подробности, ибо кому интересно тот почитает сам, а перейду сразу к нашей процедуре. Итак для перепрошивки нам необходим сам файл прошивки, скаченный с офф.сайта; стандартный RS-232 кабель  “мама-мама” и компьютер с com-портом, или, в связи с тем, что сейчас найти такой компьютер практически нереально, переходник usb-serial. Подключаемся к свичу с помощью встроенного терминала Windows (пуск -> стандартные -> связь -> HyperTerminal) со стандартными параметрами: 9600 без управления потоком, дважды щелкаем Enter и мы в строке управления CLI. Для начала нам надо перевести терминал на более высокую скорость, ибо загрузка имиджа на 9600 будет идти почти полтора часа. Для этого говорим:
# configure
# console baud-rate 115200
После чего перегружаем свич и подключаемся уже с использованием указанной скорости
Даем команду  # menu и в загрузившимся меню выбираем Download OS и выставив XMODEM говорим execute (также можно сделать это прямо из CLI задав команду # copy xmodem).  После этого нажимаем ентер и задаем отправку файла через терминал:  выбираем Передача -> Отправить файл, во вкладке Протокол выставляем XMODEM и выбираем необходимый файл прошивки.Минут 10-15 файл закачивается после чего перегружаем свич. Процесс первой загрузки будет идти несколько дольше чем обычно, так что не стоит начинать кусать локти раньше времени.

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

И вот здесь начинается некоторая непонятка, ибо Checkpoint обещает выпуск обновленного полнофункционального VPN клиента Secure Client, поддерживающего 64битные системы, только в конце второго квартала, и на данный момент предлагает два вида решения: использование облегченного VPN клиента Endpoint Connect (он также интегрирован в продукт Endpoint Security Client R73), входящего в комплект Connectra, но при этом поддерживающего соединение со шлюзами, начиная от NGX R65 HFA40. В данный момент единственная версия клиента  Endpoint Connect, поддерживающая 64битные системы, является  Endpoint Connect R73, который дает возможность подключения к системам выше R65 HFA40 и Connectra R66.

Для использования этой версии клиента также необходимо произвести апгрейд поддержки Endpoint Connect на шлюзах, путем установки установки патча поддержки R73. Последняя актуальная версия клиента Endpoint Connect, а также патч для шлюза VPN-1 и портала Connectra доступны для скачивания на офф.сайте Checkpoint.

Лицензируется использование этого продукта в виде Check Point Endpoint Security – Secure Access license, путем приобретения лицензии на удаленное рабочее место, то есть если два пользователя работают с одной машины, то нужна всего одна лицензия, если же один пользователь предполагает работать с двух разных машин, то две лицензии.

Другим вариантом использования VPN клиента на 64битныхз платформах, является использование продукта SSL Network Extender (SNX) для построения шифрованного туннеля 3го уровня SSL VPN. Версия SNX R71 HFA1 for Windows поддерживает 64битные платформы Windows 7/Vista/XP. Этот клиент скачивается с портала Check Point Security Gateways по запросу пользователя, пытающегося установить шифрованное соединение через протокол HTTPS. Продукт поддерживает шлюзы, начиная с версии NGX R60 и выше. Для использования версии R71, на шлюзах также должен быть установлен патч поддержки этой версии, который можно скачать на офф.сайте Checkpoint.

Лицензируется использование данного продукта путем приобретения лицензии SNX (на определенное количество пользователей: 25, 100, 250 и т.д) или также Check Point Endpoint Security – Secure Access license, которая приобретается по количеству удаленных рабочих мест.

Так что все разговоры о том, что Endpoint Connect поддеривается только VPN порталом Connectra либо развод на лишние, причем не малые, бабуськи, либо просто незнание материала.

Вообщем ответ тех.поддержки был, что shit happend- сие есть баг (баг заключается в том, что дропаются те пакеты у которых исходящий порт такой же как и входящий- 53; если же порт стандартно выше 1024 порта, то они проходят нормально), посему надо откатить устройство на более раннюю версию прошивки, но как оказывается сам я это сделать не могу, а это указывается ручками на стороне сервис центра производителя SMP, где оператор ручками указывает какому MAC адресу на какую прошивку перегрузиться. Но самое веселое, что это уже сделали, попросив меня ручками передернуть устройство. И мало кого волнует, что я в 50 километрах от устройства и самое близкое когда собирался туда заехать – это конец недели.

Все это очень мило, но тогда не понятно зачем там вообще в устройстве кнопка перепрошить устройство на специфическую прошивку. Надеюсь, что 7 прошивка, которую мне сегодня перезальют будет лучше чем 8.0.42, поскольку баг, со слов поддержки, будет исправлен не столь оперативно, как решаются проблемы для тех же Checkpoint Edge, которые являются клонами sofaware с той лишь разницей, что управляться могут централизованно и поддерживаются старшим братом.

*** 23.12.09 *** Баг после отката не исчез, по прежнему дропаются входящие и исходящего 53 порта, но зато разрешилась проблема с доступом по https к консоли. Оказалось, что сервер https, для внешних подключений, переехал со своего стандартного порта на 981, т.к. обращение https://server:981 позволяет достучаться к серверу из вне.

SMB – это протокол совместного межсетевого использования файлов (ненавижу переводить английскую терминологию) который входит в Microsoft Windows. Уязвимость вызывает ошибку SMB при обработке специально сконфигурированного SMB-пакета. Удаленный злоумышленник может использовать данную уязвимость через специально созданный особым образом сетевой пакет. Удачное использование уязвимости приведет к отказу в обслуживании атакуемой машины и её зависанию, вплоть до ручной перезагрузки системы. Данную уязвимость невозможно использовать для перехвата контроля или установки злонамерного программного обеспечения на атакуемую систему.

Со слов экспертов безопасности код эксплоита уже доступен, хотя специалисты Microsoft и высказывают сомнения относительно возможности использования этого эксплоита для атаки. Пользователям как обычно остается ждать святого дня Microsoft приходящегося на второй вторник месяца, т.е. в данном случае 8.12 и уповать на системы предотвращения вторжений IPS, которые способны предотвратить проникновение в систему не корректно сконфигурированных SMB пакетов.

Первое, что пришло в голову это воспользоваться стандартной функцией управляемого свича Bandwidth Control , то есть ограничение скорости по порту- наиболее дешево и сердито, но как оказалось, например для имеющихся у клиентов HP ProCurve 2ХХХ серии данный функционал оказался недоступен, после чего погрузился в интернет с ключевым словом шейпер и bandwidth control . Варианты типо checkpoint не рассматривались, поскольку в первом приближении нужен был недорогой и простой аппаратный шейпер, хотя они и присутствуют начиная с safe@office в составе QoS, но устройства начального уровня мне не подходят, поскольку safe@office держит до 50-70 пользователей, а остальные начинаются от трешки зелени.
В результате нарыл некоторое количество моделек:

Для начала россыпью идут устройства от Planet: управляемый свич FGSW-2624SF и 8ми портовые гигабитники GSD-802PS / GSD-802S

почти в этом же ключе, хотя мне нравятся меньше, маршрутизаторы D-Link DGS-3610-26 / DI-1137C-1TP

какой то не понятный, но близкий сердцу названием маршрутизатор TP-Link TL-R480T

вроде как поддерживают большинство маршрутизаторов и рутеров от Linksys WRT310N / EZXS55W / EZXS88W / EZXS16W / WET610N / WRT160N / WRT610N / WRT110 но надо вчитываться в каждое дополнительно

как более дорогой аналог: Cisco Catalyst 3500  (команда Rate Limiting)

ну и наколенные варианты Zyxel P-334WT EE которые я не очень лю, поскольку уже имел опыт неприятной работы с их оборудованием

Вариант с Planet мне понравился больше всего, поскольку пользовался ими длительное время и никаких нареканий на их оборудование не имею, кроме разве что слишком низкой цены но пораскинув немного мозгами, пришел к тому что не плохо было бы иметь на внешнем шейпере и ips с доступом к нефильтрованному трафику, поэтому вероятнее всего в ближайшее время буду настраивать шейпер под freebsd с прикрученным туда же snort’ом

Несколько слов об SSH: это сетевой протокол прикладного уровня используемый в среде Unix/Linux, с помощью которого осуществляется удаленное управление операционной системой и на его базе организуются зашифрованные туннели. Также его можно использовать для передачи файлов также как и протокол FTP. Так что в данном случае мы осуществляем удаленное управление сервером на базе Iphone.

Установка поддержки SSH с помощью Cydia

Наверняка стает вопрос, почему надо использовать ssh, коли он разработан для Unix систем? Но поскольку iPhone OS является кастрированной версией Mac OS X, которая в свою очередь базируется на ядре UNIX системы, то можно сказать что iPhone OS это облегченная версия UNIX, по этой причине мы и можем использовать SSH.

Поскольку компания Apple не включает поддержку sshв телефоны iPhone мы вынуждены, предварительно сделать jailbreak системы. После того как мы произвели джейлбрейк, то можем спокойно переходить к установке ssh: заходим в Cydia и в поиске задаем “OpenSSH” пакет. Нажимаем иконку Install и устанавливаем на iPhone, после чего перегружаем телефон. Когда система загрузится, никаких новых иконок не появится, но тем не менее утилита SSH поднимается в автоматическом режиме и прослушивает удаленные запросы на предмет установления соединения.

*** У Вас наверняка включена автоблокировка телефона? Дело в том, что в процессе передачи файла по SSH телефон должен быть в активном состоянии, для этого необходимо отключить автоблокировку: идем Settings -> General -> Auto-Lock и выставляем Never.

Передача файлов с использованием SSH

В вашем iPhone уже имеется поддержка SSH и он прослушивает входящие покеты на предмет  SSH запроса. Перед тем как передавать файлы на ваш iPhone, необходимо задать IP адрес для iPhone.

Проверить IP адрес можно по следующему пути Settings -> Wi-Fi. Нажимаем на имя активного соединения WiFi и просматриваем подробности. Вы видите IP адрес телефона и его сетевые настройки, там же вы можете задать настройки сети для вашего  iPhone. В нашем примере IP адрес будет 10.0.1.5.

Поскольку IP адрес вам уже известен, переходим к следующему шагу- установке подключения к iPhone с компьютера.

Подключения компьютера к iPhone с помощью WinSCP

Для пользоватей  Windows я бы порекомендовал скачать программу WinSCP, которая является свободнораспространяемым SSH клиентом для Win XP/Vista. Установка WinSCP элементарна и ни чем не отличается от установки стандартной программы в среде Windows. Для пользователей Unix и Mac систем- в самих системах есть встроенная поддержка ssh и встроенный клиент.

Установив приложение, запускаете WinSCP и, чтобы подключиться к iPhone, нажимаете New. В пункте host name, пишите IP адрес вашего iPhone. В user name и password, используете стандартную связку “root” and “alpine”. Остальные поля не трогаете. После этого нажимаете “Login” для установки соединения с вашим iPhone. Нажимаете “Yes” если вам будет предложено добавить host key в кэш.

*** Вместо кнопки “Login” вы можите нажать “Save…” с тем чтобы сохранить сессию для дальнейшего использования.

Нажмите “Yes” если вам будет предложено сохранить ключи.

После подключения вы увидите структуру файловой системы вашего iPhone. Теперь вы можите передавать файлы между вашим iPhone и компьютером простым перетаскиванием файлов между окошками WinSCP.

Наглядную иллюстрацию этой картины, я получил вчера на семинаре, посвященном новому поколению продукта Checkpoint R70 Blades.  Семинар  был посвящен софтварной версии системы предотвращения вторжений IPS Blade, пришедшей на смену системе Smart Defense. Новую систему отличает повышенная производительность,  более совершенные механизмы обнаружения и защиты, и по заверению вендора, в ней решены печально известные проблемы работоспособности Smart Defense.

Так вот, собственно одна из лабораторных работ предполагала настройку VPN-1 с включенным IPS Blade стандартной конфигурации, и последующей эмуляцией атаки через систему.  После удачного завершения лабораторки стали разбирать логи на машине, которая была подключена к внешней системе через провайдера нового поколения Yota; и вот тут то и выяснился очень забавный момент, что с того момента как мы запустили IPS, буквально через полторы минуты, на машину пошли атаки различных типо: IP Fragments, Teardrop, Ping of death.

Teardrop – представляет собой DoS атаку, использующую уязвимость сборки пакетов при фрагментации: атакующая сторона посылает фрагменты перекрывающие друг друга, т.ч. при сборке на стороне жертвы пакета в цельное состояние, происходит зависание системы.

Ping of Death – также относится к DoS атаке, в результате которой атакующая сторона посылает echo запрос заведомо превышающий разрешенный размер для IP протокола в 65,535 байт, т.ч при получении данного запроса и попытке его обработки на удаленной системе происходит переполнение буфера, что в свою очередь приводит систему к  выходу из строя.

Ip Fragment – тип атаки направленной на безусловное установление соединения с атакуемой машиной, путем некорректной сборки фрагментированных пакетов.

Как видно из описания, каждая из этих атак является потенциально опасной и приводит либо к выходу системы из строя, либо к попытке захвата контроля над удаленной системой.

Вообщем как говорила Рената Литвинова:  как страшно жить! Не знаю как Вы, а я в инет без защиты – ни ногой.

Смена IP адреса уникальна для каждой отдельной операционной системы, и в данном мануале не рассматривается.  Рекомендую обратиться к мануалам OS, в случае если эта тривиальная процедура вызывает чувство беспокойства

Сценарий:
Host name сервера Smart Center ‘test’.  IP адрес = 10.0.30.200, и адрес на который мы хотим его сменить  10.0.30.150.

Кстати:
Для начала необходимо запросить новую лицензию в  Check Point User Center account.

Поехали:

1. Открываем SmartDashboard и правим объект политики  ‘test’
2. Меняем IP адрес во вкладке ‘General’ на новый IP
3. Правим вкладку Topology, изменяем старый IP на новый адрес, и кликом на OK закрываем объкт
4. Щелкаем  File -> Save.
5. Останавливаем SmartCenter сервер с помощью команды "cpstop"
6. Изменяем файл /etc/hosts file, чтобы ‘test’ перенаправлялся на 10.0.30.150
7. Изменяем IP адрес на внешнем интерфейсе SmartCenter сервера
   ***
   Не забыть поменять маршрут по умолчанию для внешнего интерфейса OS
8. Если лицензия сервера SmartCenter привязывалась к внешнему IP адресу, то изменяем лицензию для нового IP
9. Перегружам SmartCenter сервер
10. Пингуем host tets по его hostname, чтобы убедиться что резолв на новый адрес работает корректно
11. Подключаемся к SmartDashboard, проверяем и устанавливаем Security Policy.

Большинство функциональных возможностей описанных в модели OSI присутствует, в той или иной мере, во всех сетевых коммуникациях, но существует также модели OSI, где 2-3 уровня слиты воедино.

Семиуровневая модель OSI

7. Прикладной Уровень(Application Layer) Прикладной уровень отвечает за доступ приложений в сеть. На этом уровне партнеры связи установлены, качество обслуживания установлено, установление подлинности пользователя и секретность рассматриваются, и любые ограничения на синтаксис данных установлены. (Этот уровень – не приложение как таковое, хотя некоторые приложения могут выполнять функции прикладного уровня.) Задачами этого уровня является перенос файлов, обмен почтовыми сообщениями и управление сетью.
* FTP (англ.  File Transfer Protocol) – протокол передачи файлов
* TFTP (англ. Trivial File Transfer Protocol) – простой протокол передачи файлов
* Telnet (англ. TELecommunication NETwork) – терминальное соединение с удаленным хостом (текстовое управление)
* SMTP (англ. Simple Mail Transfer Protocol) – упрощенный протокол передачи почтовых сообщений
* CMIP (англ. Common Management Information Protocol) – общий протокол управления информацией
* SNMP (англ. Simple Network Management Protocol)- упрощенный протокол управления сетью
* NFS (англ. Network File System)- протокол сетевого доступа к сетевым файлововым системам
* FTAM (англ. File Transfer Access and Management) – метод доступа и управления переноса файлов

6 Уровень Представления данных (Presentation Layer) Уровень представления служит для обеспечения возможности общения между приложениями на разных хостах.  Этот уровень отвечает за обработку и преобразование данных (кодирование, сжатие и т.д.) прикладного уровня в исходную информацию передаваемую на транспортный уровень.  Протоколы уровня представления являются составной частью функций трех верхних уровней модели. Порою именуют синтаксическим уровнем.

5 Сеансовый (Session Layer) Сеансовый уровень отвечает за установление сеансов обмена информацией между целевыми хостами.  Стек протоколов сеансового уровня обычно является составной частью функций трех верхних уровней модели.

4 Транспортный (Transport Layer) Транспортный уровень разбивает потоки информации на небольшие фрагменты (пакеты) для передачи их на сетевой уровень. Также занимается сборкой пакетов и контролем доставки и целостности переданных данных.

Наиболее распространенные протоколы транспортного уровня включают:

• TCP (англ. Transmission Control Protocol) – протокол управления передачей
• NCP (англ. Netware Core Protocol) протокол базирующийся на протоколе IPX. В сетях Netware служит для обмена информацией между рабочей станцией и сервером.
• SPX (англ. Sequenced Packet Exchange) — протокол последовательного обмена пакетами
• TP0-4 – протоколы передачи классов от 0 до 4

3 Сетевой Уровень (Network Layer) Сетевой уровень управляет передачей данных и маршрутизация пакетов на основе подсетей и  адресов. На этом же уровне происходит преобразование сетевых адресов в MAC-адреса, для дальнейшей передачи через нижние уровни.

Наиболее часто на сетевом уровне используются протоколы:

• IP (англ. Internet Protocol) – маршрутизируемый  межсетевой протокол, основа стека протоколов TCP/IP
• IPX (англ. Internetwork Packet Exchange)- протокол межсетевого обмена, основа стека протоколов SPX
• CLNP (англ. Connectionless Network Protocol) – сетевой протокол без организации соединений

2 Канальный Уровень (Data Link Layer)  Канальный уровень отвечает за фрагментацию, передачу и прием кадров данных. Этот уровень получает запросы сетевого уровня и использует сервис физического уровня для приема и передачи пакетов данных. Спецификации IEEE 802.x делят канальный уровень на два подуровня: управление логическим каналом (LLC) и управление доступом к среде (MAC).  LLC обеспечивает обслуживание сетевого уровня, а подуровень MAC регулирует доступ к разделяемой физической среде.

Наиболее часто используемые на уровне 2 протоколы включают:

• HDLC для последовательных соединений
• IEEE 802.2 LLC (тип I и тип II) обеспечивают MAC для сред 802.x
• Ethernet- множественный доступ с контролем несущей
• Token ring- сетевая структура с несущим маркером
• FDDI- оптиволоконная сеть
• X.25-протокол предачи наддных на основе телефонных сетей, с контролем ошибок
• Frame relay- протокол ретрансляции кадров

1 Физический Уровень (Physical Layer) Физический уровень принимает пакеты данных от верхнего канального уровня и преобразует их в оптические или электрические сигналы, соответствующие 0 и 1 бинарного потока. Эти сигналы посылаются через среду передачи данных на приемный узел. Механические и электрические/оптические свойства среды передачи определяются на физическом уровне и включаютя:

• Тип кабелей и разъемов
• Разводку контактов в разъемах
• Схему кодирования сигналов для значений 0 и 1

К числу наиболее распространенных спецификаций физического уровня относятся:

• EIA-RS-232-C, CCITT V.24/V.28 – механические/электрические характеристики несбалансированного последовательного интерфейса.
• EIA-RS-422/449, CCITT V.10 – механические, электрические и оптические характеристики сбалансированного последовательного интерфейса.
• IEEE 802.3 — Ethernet
• IEEE 802.5 — Token ring