Атака на FreeSWITCH закончилась

Уфф... DOS атака на мой сервер закончилась. Вот какой траффик порождала атака сегодня:


Это уже после того, как я активировал iptables, соответственно мы видим, что исходящий трафик практически нулевой - мой телефонный сервер не отвечал на эту атаку, потому что до него запросы не доходили.

Суммарно на мой сервер было отправлено 2475 Mb данных, атака длилась 30 часов. Сервер выдержал.

Смотря внимательно на данные, которые отправляли хакеры на мой сервер, мы видим, что они в SIP пакетах использовали прокси (поле VIA), в результате телефонный сервер слал ответ не на сервер хакеров, а на другой сервер, таким образом мой собственный сервер выступал в роли хакерского сайта, долбящего пакетами совершенно невинный сервер! Пока я не заметил атаку, мой сервер успел отправить на невинную жертву 1 Гб данных! Сервер этот, кстати, был сайтом по нелегальному заработку - они предлагали отдать им деньги и зарабатывать 1% в день.

Причина атаки

Я считаю, что атака была направлена не на меня, а на тот самый сайт по мошенническому заработку в сети, адрес которого стоит в поле VIA. Такой изощренный метод атаки, когда хакеры заставляют другие сайты атаковать на их жертвы.
Возможно, этот сайт кого-то кинул на деньги, и его решили таким образом за'DDoS'ить.

Выводы

В результате всего этого я сделал для себя неожиданные открытия. Посмотрев другие логи на сервере в папке /var/log(sshd.log, apache2/error_log, messages, warn), я заметил, что мой сайт уже неоднократно пытались хакать! Были попытки подобрать пароль и имя пользователя при логине по SSH, были попытки произвести взлом через дыру в веб-сервере ("client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23)") - дыры не было, но я узнал про такой способ атаки.
В результате тепеь у меня на сервере работает fail2ban с несколькими "тюрьмами", которые ловят и сажают в тюрьму злоумышленников, атакующих SSH, SIP, HTTP. Это уже лучше, чем быть совсем беззащитным перед атаками.

UPD

Атака, как оказалось, закончилась только на пару часов и продолжилась с новой силой в мае. Сегодня, 11-го мая, атака, по-видимому, окончательно прекратилась:


Суммарно хакеры нагнали мне траффика 21,1 Гб (!).

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

Сегодня моя защита на основе fail2ban поймала еще одну попытку взломать телефонный сервер - эта попытка была сразу же пресечена. Думаю подействует и очередной brute force атаки не будет, поскольку мой сервер перестал существовать в сети для атакующих и нет смысла делать атаку :)

Ну вот и первый хак

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



За 10 часов атаки суммарно получается 670Мб входящего траффика и 1 Гб исходящего.

Смотрим логи:
/usr/local/freeswitch/log # ll freeswitch.log.*
-rw----r-- 1 root root 815562 Apr 2 03:07 freeswitch.log.2011-04-02-03-07-07.1
-rw----r-- 1 root root 190 Apr 2 03:07 freeswitch.log.2011-04-02-03-07-07.2
-rw----r-- 1 root root 10485904 Apr 29 15:13 freeswitch.log.2011-04-29-15-13-18.1
-rw----r-- 1 root root 10485899 Apr 29 15:44 freeswitch.log.2011-04-29-15-44-41.1
-rw----r-- 1 root root 10485899 Apr 29 16:12 freeswitch.log.2011-04-29-16-12-55.1
-rw----r-- 1 root root 10485899 Apr 29 16:33 freeswitch.log.2011-04-29-16-33-08.1
-rw----r-- 1 root root 10485899 Apr 29 16:53 freeswitch.log.2011-04-29-16-53-30.1
-rw----r-- 1 root root 10485899 Apr 29 17:16 freeswitch.log.2011-04-29-17-16-00.1
-rw----r-- 1 root root 10485835 Apr 29 17:39 freeswitch.log.2011-04-29-17-39-05.1
-rw----r-- 1 root root 10485835 Apr 29 18:00 freeswitch.log.2011-04-29-18-00-45.1
-rw----r-- 1 root root 10485899 Apr 29 18:21 freeswitch.log.2011-04-29-18-21-57.1
-rw----r-- 1 root root 10485899 Apr 29 18:42 freeswitch.log.2011-04-29-18-42-27.1
-rw----r-- 1 root root 10485899 Apr 29 19:03 freeswitch.log.2011-04-29-19-03-20.1
-rw----r-- 1 root root 10485899 Apr 29 19:23 freeswitch.log.2011-04-29-19-23-07.1
-rw----r-- 1 root root 10485899 Apr 29 19:41 freeswitch.log.2011-04-29-19-41-55.1
-rw----r-- 1 root root 10485899 Apr 29 20:01 freeswitch.log.2011-04-29-20-01-10.1
-rw----r-- 1 root root 10485899 Apr 29 20:19 freeswitch.log.2011-04-29-20-19-27.1
-rw----r-- 1 root root 10485899 Apr 29 20:37 freeswitch.log.2011-04-29-20-37-57.1
-rw----r-- 1 root root 10485899 Apr 29 20:57 freeswitch.log.2011-04-29-20-57-18.1
-rw----r-- 1 root root 10485899 Apr 29 21:21 freeswitch.log.2011-04-29-21-21-10.1
-rw----r-- 1 root root 10485899 Apr 29 21:39 freeswitch.log.2011-04-29-21-39-17.1
-rw----r-- 1 root root 6906631 Apr 29 22:58 freeswitch.log.2011-04-29-22-58-56.1
-rw----r-- 1 root root 71 Apr 29 22:58 freeswitch.log.2011-04-29-22-58-56.2
/usr/local/freeswitch/log #

Вот как началась атака:
2011-04-29 06:41:38.351078 [WARNING] sofia_reg.c:1246 SIP auth challenge (REGISTER) on sofia profile 'internal' for [1610258589@myserverip] from ip 66.199.232.98
2011-04-29 06:46:09.164120 [WARNING] sofia_reg.c:1246 SIP auth challenge (REGISTER) on sofia profile 'internal' for [3623987258@myserverip] from ip 66.199.232.98
2011-04-29 14:39:42.604125 [WARNING] sofia_reg.c:1246 SIP auth challenge (REGISTER) on sofia profile 'internal' for [2917801763@myserverip] from ip 91.220.62.140
2011-04-29 14:39:42.616121 [WARNING] sofia_reg.c:1246 SIP auth challenge (REGISTER) on sofia profile 'internal' for [1882527475@myserverip] from ip 91.220.62.140
2011-04-29 14:39:43.139079 [WARNING] sofia_reg.c:1246 SIP auth challenge (REGISTER) on sofia profile 'internal' for [china@myserverip] from ip 91.220.62.140
2011-04-29 14:39:43.159069 [WARNING] sofia_reg.c:1246 SIP auth challenge (REGISTER) on sofia profile 'internal' for [koreea@myserverip] from ip 91.220.62.140
2011-04-29 14:39:43.170114 [WARNING] sofia_reg.c:1246 SIP auth challenge (REGISTER) on sofia profile 'internal' for [korea@myserverip] from ip 91.220.62.140
2011-04-29 14:39:43.179114 [WARNING] sofia_reg.c:1246 SIP auth challenge (REGISTER) on sofia profile 'internal' for [japan@myserverip] from ip 91.220.62.140
2011-04-29 14:39:43.343117 [WARNING] sofia_reg.c:1246 SIP auth challenge (REGISTER) on sofia profile 'internal' for [taiwan@myserverip] from ip 91.220.62.140
2011-04-29 14:39:43.350107 [WARNING] sofia_reg.c:1246 SIP auth challenge (REGISTER) on sofia profile 'internal' for [000000@myserverip] from ip 91.220.62.140
2011-04-29 14:39:43.363118 [WARNING] sofia_reg.c:1246 SIP auth challenge (REGISTER) on sofia profile 'internal' for [00000000@myserverip] from ip 91.220.62.140

и дальше пошел перебор всех возможных цифровых и буквенных номеров SIP телефонов. На момент обнаружения мной этой атаки хакеры перебрали 1,3 млн. комбинаций!

Пришлось в срочном порядке добавлять правило в iptables:

iptables -I INPUT -s 91.220.62.140 -j DROP

Это спасло.

Похоже, это DOS атака. Детали атаки такие (здесь IP адрес моего сервера замнен на myserverip на всякий случай):

FreeSWITCH получает пакет:

REGISTER sip:myserverip SIP/2.0
Via: SIP/2.0/UDP 91.220.62.36:5137;branch=z9hG4bK-1132046786;rport
Content-Length: 0
From: "5988"
Accept: application/sdp
User-Agent: friendly-scanner
To: "5988"
Contact: sip:123@1.1.1.1
CSeq: 1 REGISTER
Call-ID: 1008625951
Max-Forwards: 70

FreeSWITCH ругается:

2011-04-30 01:28:44.511139 [WARNING] sofia_reg.c:1246 SIP auth challenge (REGISTER) on sofia profile 'internal' for [5988@myserverip] from ip 91.220.62.140

FreeSWITCH отправляет ответ на хакерский сайт:

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 91.220.62.36:5137;branch=z9hG4bK-1132046786;rport=5137;received=91.220.62.140
From: "5988"
To: "5988" ;tag=g0BXD9pv6mjBe
Call-ID: 1008625951
CSeq: 1 REGISTER
User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-e52e44e 2011-03-31 13-44-24 -0500
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
WWW-Authenticate: Digest realm="myserverip", nonce="a9360d6c-72a7-11e0-b622-f7c8239c6915", algorithm=MD5, qop="auth"
Content-Length: 0

Нашел замечательную утилиту fail2ban, чтобы в будущем рубить хакеров на корню.

Настройка простая:

zypper in fail2ban

Создаем файл /etc/fail2ban/filter.d/freeswitch.conf

# Fail2Ban configuration file
[Definition]
failregex = .* SIP auth challenge .* from ip <HOST>
ignoreregex =

Дописываем вот этот кусок в конец файла /etc/fail2ban/jail.conf

[freeswitch]
enabled = true
port = 5060,5061,5080,5081
protocol = udp
filter = freeswitch
logpath = /usr/local/freeswitch/log/freeswitch.log
action = iptables-allports[name=freeswitch, protocol=all]
maxretry = 3
findtime = 600
bantime = 18000

Запускаем

/etc/init.d/fail2ban restart

И наслаждаемся результатом:
Сюда будут добавляться заблокированные хосты:

/usr/local/freeswitch/conf # iptables -L fail2ban-freeswitch
Chain fail2ban-freeswitch (1 references)
target prot opt source destination
DROP all -- 91.220.62.140 anywhere
RETURN all -- anywhere anywhere

/usr/local/freeswitch/conf # cat /var/log/fail2ban.log
2011-04-30 02:27:19,580 fail2ban.filter : DEBUG Found 91.220.62.140
2011-04-30 02:27:19,581 fail2ban.filter : DEBUG Found 91.220.62.140
2011-04-30 02:27:19,581 fail2ban.filter.datedetector: DEBUG Sorting the template list
2011-04-30 02:27:19,583 fail2ban.actions.action: DEBUG iptables -N fail2ban-freeswitch
iptables -A fail2ban-freeswitch -j RETURN
iptables -I INPUT -p all -j fail2ban-freeswitch returned successfully
2011-04-30 02:27:19,583 fail2ban.actions.action: DEBUG iptables -n -L INPUT | grep -q fail2ban-freeswitch
2011-04-30 02:27:19,587 fail2ban.actions.action: DEBUG iptables -n -L INPUT | grep -q fail2ban-freeswitch returned successfully
2011-04-30 02:27:19,587 fail2ban.actions.action: DEBUG iptables -I fail2ban-freeswitch 1 -s 91.220.62.140 -j DROP
2011-04-30 02:27:19,590 fail2ban.actions.action: DEBUG iptables -I fail2ban-freeswitch 1 -s 91.220.62.140 -j DROP returned successfully
2011-04-30 02:27:19,590 fail2ban.actions: WARNING [freeswitch] 91.220.62.140 already banned

Ура :)

Оффлайн бизнес должен идти в онлайн

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

В онлайне сейчас находится достаточно большое число ваших потенциальных клиентов, в связи с широким распространением интернета в домах и на телефонах обывателей. В то же время, рынок традиционных средств продвижения продукта или услуги сокращается. Скажите, вы когда-либо слышали по телевизору, читали в газете или видели на дорожном биллборде информацию о том, что ИП Пупкин на Сормовском шоссе предлагает скидку 50% на шиномонтаж? Или то, что в подвальчике на Нартова открылось новое ателье по пошиву брюк на заказ? Названия выдуманные, но смысл нет: малому бизнесу зачастую не под силу организовать для себя хорошую оффлайновую рекламную кампанию, и в результате эти начинающие предприниматели ограничиваются простым: распечатыванием объявления "скидка 50%" на листе А4 на входной двери в предприятие, и публикацией рекламного сообщения в бесплатной рекламной газетенке, которую все равно никто не читает.

Трудности перехода
Трудности, на мой взгляд, связвны с тем, что начинающие предприниматели, по натуре своей, находятся далеко от высоких интерент-технологий. Они этому нигде не учились, среди их знакомых - таких же ИПшников - никто так не делает, поэтому они ориентируются исключительно на "проходимость" места - т.е. на пассивную роль: авось кто-нибудь, проходя мимо нашего ателье/шиномонтажа, разглядит на нашей двери листочек с объявлением что "мы открылись" и с графиком работы. Авось ему как раз нужно будет пошить брюки или совершенно случайно потенциальный клиент будет на машине на зимней резине в апреле, и заедет к нам на шиномонтаж.

Пути решения проблемы
Выход состоит в более тесной интеграции бизнеса с онлайн технологиями. Этот процесс начинается. Хотя Россия, как всегда, сильно отстает от запада, я уверен, будет и на нашей улице праздник, придет время, когда все будут онлайн.
Я наблюдаю начало этой тенденции на примере фотографов, которые не только, как по старинке, публикуют свои фотографии на специализированных фото-сайтах, но и начинают пользоваться livejournal и вконтакте для раскрутки своего бренда, для привлечения на свою страничку в интернете потенциальных клиентов через распространение ссылки на ресурс довольными клиентами. Такие потуги кажутся наивными, поскольку технология "блог" известна уже лет эдак 10, а фотографы еще не научились писать правильные тексты в своем блоге, для повышения своего рейтинга в поисковых системах, не говоря уж о подключении к блоку аналитики.

Технологии, за которыми будущее
Что нас ожидает в ближайшие пару лет? Более тесная "социализация", т.е. проникновение социальных сетей во все сферы жизни. Уход от персональных компьютеров, замена их сотовыми телефонами и коммуникаторами со встроенным веб-браузером. Компьютеры, и ноутбуки - это прошлый век, и нужны они только программистам. Все компьютеры опять превратятся в гигантских супермощных монстров и перетекут в дата-центры (облака), оставив у обывателей только "остатки" компьютерных технологий вроде телевизора с браузером, медиаплеера с торрент-клиентом, читалки книг с mp3-плеером, фотоаппарата со встроенной функцией редактирования фото/видео.

Этим постом я открываю цикл статей на эту тему.

Репликация базы данных PostgreSQL на основе SymmetricDS

+ В этой статье я расскажу, как настроить репликацию баз данных PostgreSQL. Что такое репликация? По сути, это механизм автоматической синхронизации содержимого баз данных, работающих на разных серверах.

В результате репликации эти базы данных содержат абсолютно идентичные данные. Это нужно например для того, чтобы обеспечить отказоустойчивость системы (в случае падения первого сервера баз данных в работу вступает второй), или чтобы осуществить балансировку нагрузки - разных клиентов могут обслуживать разные сервера.
Для экспериментов будем использовать дистрибутив линукса CentOS 5.3, хотя это не принципиально. Версия PostgreSQL, используемая в статье: 8.4.7. Она еще не умеет сама реплицироваться - это фича 9-й версии постгреса.

Для репликации нужно как минимум два сервера баз данных, поэтому готовим два одинаковых сервера с базой данных PostgreSQL на каждом. У первого будет IP адрес 10.0.2.20, у второго - 10.0.2.21, у обоих гейтвей 10.0.2.2.
Можно обойтись виртуальной машиной, например VirtualBox, создать в ней два виртуальных сервера и запустить их на своем собственном компе.

В приведенных командах первым символом будет стоять знак # либо $, эти знаки означают, что команда запускается из-под root или из-под обычного пользователя, соответственно.
Итак, какие действия нужно предпринять:

Распознавание голоса с помощью технологий Google

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

Что нам потребуется:
- Perl с модулями JSON::XS и LWP,
- утилита flac для работы со звуком,
- исходный звуковой файл test.wav, 11025Hz mono 16 bit, для распознавания.

Вкратце, что надо делать: отправить flac в POST-запросе на адрес гугловского сервиса, а как результат получить JSON с распознанным текстом.

Код очень прост. Вот такой:

#!/usr/bin/perl

use Encode;
use JSON::XS;
use LWP::UserAgent;
$ua = LWP::UserAgent->new;

$file = "test.wav";
$res = `flac $file >/dev/null 2>&1`;
$flacfile = "$file";
$flacfile =~ s/\.wav$/\.flac/;
$filesize = -s "$flacfile";

open(flac, "$flacfile");
binmode flac;
read(flac, $data, $filesize);
close(flac);
unlink("$flacfile");

$url = 'http://www.google.com/speech-api/v1/recognize?xjerr=1&client=chromium&lang=ru-RU';
my $req = HTTP::Request->new(POST=>$url);
$req->content_type('audio/x-flac; rate=11025');
$req->content_length($filesize);
$req->content($data);

$res = $ua->request($req);
$jstxt = JSON::XS->new->utf8->decode($res->content);
$decoded = $jstxt->{hypotheses}[0]->{utterance};

use utf8;
print "\nDecoded:\n$decoded\n";
no utf8;

Вот и всё :) Как видим, всё достаточно просто. Мы только что заюзали фичу гугла, которая, якобы, существует только в хроме для мобильных телефонов ("голосовой поиск"), причем мы ее заюзали нестандартным образом: нам не нужен поиск как таковой, нам нужен всего лишь промежуточный результат: распознанный голос.

На вход гугловскому сервису подается звук в формате FLAC, который мы предварительно кодируем из исходного файла WAV. Потребуется указать частоту дискретизации звука: в моем случае это 11кГц (11025).

Из проблем этого гугловского сервиса, которые стоит отметить:
-он, похоже, еще очень сырой. Постоянно, вместо ответа с распознанным текстом приходят HTTP 500 Server Error.

Я провел простой эксперимент: запустил распознавание звука 20 раз подряд.
Для длинных звуковых файлов, размер которых больше 300.000 байт (11кГц моно 16 бит звук), сервис Гугла ни разу (!) не вернул результат, все 20 раз было Internal Server Error 500.
При ограничении отправляемого звукового файла размером 200.000 байт (до кодирования его во flac) расклад стал такой: 6 из 20 запусков - Internal Error 500; при повторном запуске этого теста результаты лучше: 2 из 20 запусков вернули Error 500.
Видимо, этот сервис заточен исключительно на поиск, когда юзер говорит поисковую фразу из 2-3 слов (типа, "пицца Нижний Новгород") и получает результаты поиска.

VDS защищается от неопытных пользователей

Похоже, системные администраторы в немецких дата-центрах сделали всё возможное, чтобы не дать неопытному человеку самостоятельно поднять сервер на VDS (скорее всего они пойдут в платную техподдержку).
Вот пример: провайдер interserver.ru. Чтобы поднять обычный LAMP сервер на SUSE11.3, пришлось столкнуться со следующим:
1) "Контейнер" (операционная система) содержит крайне урезанный набор пакетов. Практически ничего нет. это конечно хорошо, ничего лишнего, поскольку каждый мегабайт на счету, но... YaST2 не работает:


Это связано с тем, что не установлен пакет yast2-ncurses-pkg и в графическом интерфейсе yast его никак не установить.

2) Делаем попытку каким-то образом установить недостающий пакет, не используя установщиков с интерфейсом пользователя. На счастье в SuSE есть такая утилита командной строки, как zypper.
Но для начала надо его настроить, добавив репозитории. Тоже не всякий виндовый юзер сообразит как это делается. Вот так:
zypper ar -n suse11.3 http://ftp.gwdg.de/pub/linux/misc/packman/suse/11.3/ suse11.3
zypper ar -n opensuse11.3 http://download.opensuse.org/distribution/11.3/repo/oss/suse/ opensuse11.3

3) Далее, нас, как оказывается, не спасает даже команда zypper in yast2-ncurses-pkg.
Понимаем, что это было зря, поскольку теперь yast выдает ошибку "Error while creating client module sw_single"... Забиваем окончательно на yast, эту команду не вводим, чтобы не устанавливались лишние пакеты. Переходим на командную строку zypper. Все-таки командная строка - сила!

4) Ура. Мы на втором уровне :) и теперь снова можем ставить недостающий софт на VDS! делаем это:
zypper in mysql php php5-mysql mcrypt apache2-mod_php5

Далее оказывается, что установить mysql на автозапуск командой chkconfig mysql 3 невозможно, поскольку есть бага в самом скрипте крона!

# chkconfig mysql 3
insserv: warning: script 'S10vzquota' missing LSB tags and overrides
insserv: warning: script is corrupt or invalid: /etc/init.d/rc6.d/S00vzreboot
insserv: warning: script 'vzquota' missing LSB tags and overrides
insserv: warning: script 'S10vzquota' missing LSB tags and overrides
insserv: warning: script is corrupt or invalid: /etc/init.d/rc6.d/S00vzreboot
insserv: warning: script 'vzquota' missing LSB tags and overrides
insserv: FATAL: service boot.shm has to exists for service boot.rootfsck
insserv: exiting now!
/sbin/insserv failed, exit code 1

Вставляем в начало скрипта /etc/init.d/rc6.d/S00vzreboot комменты так, как написано тут:
http://serverfault.com/questions/248325/debian-squeeze-vzquota
Это избавит нас от части ошибок.

Далее, делаем такие две команды:
# mv /etc/init.d/rc6.d/S00vzreboot /etc/init.d/vzreboot
# ln -s /etc/init.d/vzreboot /etc/init.d/rc6.d/S00vzreboot
(спасибо http://accessdlab.blogspot.com/2010/06/s00vzreboot-trouble.html за решение)

Это приведет нас к такому сообщению об ошибке. Уже лучше:

# chkconfig mysql 3
insserv: FATAL: service boot.shm has to exists for service boot.rootfsck
insserv: exiting now!
/sbin/insserv failed, exit code 1

Эта ошибка из-за того, что в файле /etc/init.d/boot.rootfsck написано:

# Required-Start: boot.shm

А сервиса boot.shm в контейнере suse-11.3 нет. Поэтому просто удаляем слово boot.shm оттуда.

Всё, после этого установить mysql как сервис получается, ура!

перезапускаем апач:
service apache2 restart

И всё, LAMP работает, т.е. скрипты на PHP можно писать и тестировать.

Виртуализация приложений. Обзор технологии. Часть 2. Ericom PowerTerm WebConnect

Теперь пришла очередь рассказать о чудном продукте, таком как Ericom PowerTerm WebConnect. Он тоже умеет присылать с сервера картинки работающих там приложений.

Сразу скажу: продукт ужасен по своему пользовательскому интерфейсу (черт ногу сломит в настройках), а также у него просто ужасная документация. Замечательный пример по поводу того, как НЕ надо писать документацию. Я потратил 2 дня, чтобы разобраться, что там к чему, и вот пошаговая инструкция.

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

(1) Скачиваем дистрибутив, предварительно ответив на вопросы дурацкой анкеты. В нее можно вводить всё, что угодно, никакие поля не проверяются, email можно вводить в виде абракадабры, но с обязательной собачкой посередине :) В результате заполнения этой анкеты дается прямая ссылка на дистрибутив, 251 Мб.

(2) Устанавливаем, выбирая режим Evaluate - нам дастся 30 дней на изучение продукта.
Установщик состоит из кучи продуктов, некоторые из которых взаимодействуют друг с другом, некоторые нет, есть даже такие продукты, которые устанавливаются в виде файла установщика.... И их надо потом еще раз устанавливать из каталога с продуктом... Понять, какие компоненты нужны для целей Application Streaming, а какие лишние, не представляется возможным, поэтому ставим всё, и на сервер, и на клиентские компьютеры.



В конце установки нажимаем Finish.

(3) Запуск и настройка на серверном компьютере.

Для сервера установленного программного обеспечения не достаточно, несмотря на то, что мы при установке выбрали опцию "установить всё". Нужно обязательно поставить еще вот этот компонент, который установился в виде инсталляшки:
C:\Program Files\Ericom Software\WebConnect 5.6\AddOns\TerminalServerAgent\PowerTermTerminalServerAgent.exe

Также на серверном компьютере нужно остановить (задизэблить) сервис Windows Firewall, потому что он не даст нам работать.

Запускаем Пуск - Программы - Ericom Software - PowerTerm WebConnect 5.6 - PowerTerm WebConnect Administration Tool. Появится окошко:

Нажимаем Cancel, потому что сервер еще не запущен. В главном окне запускаем сервер:

А уже потом выходим в меню Server-Connect, видим опять окошко авторизации, ничего там не меняем. Пароль пустой. Нажимаем Connect. Должно получиться зайти в админскую консоль, которая выглядит так:

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

Потом нажимаем на иконку с человеком и задаем пароль для юзера user. Также ставим галочку Free User.


Также редактируем пользователя Administrator, нужно поставить галочку Allow Concurrent Machines, иначе не получится сконфигурировать клиентов. Как только все клиенты настроены, эту галочку надо обратно снять, чтобы администратор не смог залогиниться в утилиту с другого компа (сможет только с сервера через соединение к localhost).

Теперь публикуем приложения, которые можно будет запускать через Remote Desktop с клиентских компьютеров:
Должно открыться вот такое окошко:
в нем ничего не меняем, нажимаем ОК, и дальше должно появиться окошко с выбором приложений для публикации, в котором выбираем приложения, которые будут использоваться удаленно юзерами.
Если это окошко не появилось, а вместо него появился MessageBox, который просит запустить Desktop View Service, то тут надо сделать так, как описано ниже. Вообще, интерфейс программы довольно поганый - она говорит, что надо запустить какой-то сервис, при этом абсолютно не понятно, как его запустить, где его взять, и почему она сама его не запустила, если он нужен... Есть подозрения, что он запускается сам при каких-то определенных условиях, например при вот этом.

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

Потом пробегаемся по мастеру:


Второй шаг. Многоточие около первого Edit Box может по странным причинам не работать, поэтому текст надо вбить от руки.


Далее несколько шагов интуитивны; на 7 шаге надо поставить галочку у Disk Drives - тогда жесткие диски клиента примонтируются к серверу.

Вот на этом шаге нельзя писать localhost в поле address, потому что тогда RemoteDesktop не сможет работать. Поэтому пишем IP адрес нашего сервера, все остальное не меняем:


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

Доходим до последнего, 12-го шага. и тут обязательно надо нажать на кнопку Advanced, и прописать виндусовый логин и пароль для соединения с сервером.

Итак, все готово!
Вот что получилось после опубликования двух приложений на сервере:

(4) теперь настраиваем клиентские компьютеры.

Тривиального способа запустить Application Zone, по-видимому, нет, делать всё придется через {censored}.
Чтобы запустить Application Zone, нужно:
- Залогиниться с клиентсокго компа как администратор на сервере
- Запустить Application Zone
- В этом приложении включить галочку "запускать при старте Windows" и помесить иконку на рабочий стол
- потом можно запускать AppZone под непривилегированным пользователем.

Делаем. Логинимся на наш сервер под администратором. Не забываем указать правильный IP адрес сервера.
После логина нажимаем на этот пункт меню:
В трее запустится Application Zone, надо будет нажать на значок в трее и выбрать пункт Open Application Zone. Вот что получилось:
В меню Options надо выбрать Create a Shortcut on the Desktop, и собственно это всё. Теперь можно закрыть Administration Tool и на сервере запрещать администратору логиниться с удаленного компьютера.

Иконка, кстати, создалась на десктопе с нетривиальными параметрами (даже с буквами ю):
"C:\Program Files\Ericom Software\WebConnect 5.6\bin\PtAgent.exe" /CREDFILE=WebConnect_ю_192.168.5.43_4001ю.dat -efdю

(5) Запуск удаленных приложений с компьютеров клиентов

Разлогиниваемся с сервера!

Запускаем Application Zone по иконке и логинимся как user, т.е. непривилегированным пользователем, потом нажимаем на значок в трее и выбираем пункт Open Application Zone.

Нажимаем на иконку для запуска приложения и случается магия. Смотрите как красиво:


Звук передается тоже, правда прерывистый... занимаемый траффик 3 мегабита в секунду.