Защита сетевых сервисов с помощью stunnel::Журнал СА 12.2004
www.samag.ru
Льготная подписка для студентов      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 1943
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 1973
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 1530
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 1117
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1693
Комментарии: 1
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

Электронка - 2020!

 Защита сетевых сервисов с помощью stunnel

Архив номеров / 2004 / Выпуск №12 (25) / Защита сетевых сервисов с помощью stunnel

Рубрика: Безопасность /  Сетевая безопасность

АНДРЕЙ БЕШКОВ

Защита сетевых сервисов с помощью stunnel

Инциденты с безопасностью были и, видимо, будут всегда. Не последнюю роль в этом играет изначально ошибочный дизайн многих сетевых протоколов. Большинство из них передают и принимают данные либо в открытом виде, либо с минимальным шифрованием. Криптография не стоит на месте, и постепенно некоторые протоколы обзаводятся функциями, реализующими стойкое шифрование, но, к сожалению, процесс этот идет не слишком быстро. Для подавляющего большинства разработчиков программного обеспечения вопросы безопасности создаваемого продукта стоят далеко не на первом месте. Обычно все делается по принципу «лишь бы приложение хоть как-то заработало», а потом мы уже исправим все недочеты. Обычно это «потом» растягивается на годы. И чаще всего для внедрения в уже работающий программный комплекс механизмов безопасности необходимо достаточно сильно менять не только код, но и многие идеи, лежащие в основе всего дизайна. Не каждый производитель программного обеспечения с радостью пойдет на дополнительные трудозатраты.

Благодаря инициативе компании Netscape стандартом де факто для задач шифрования веб-коммуникаций стал SSL (Security Socket Layer). Первоначально он применялся для защиты данных, передаваемых с помощью HTTP. Годы активного использования в сфере веб-коммерции доказали стабильность и надежность этого решения. Таким образом, возникла защищенная версия протокола HTTP, в дальнейшем получившая название HTTPS. Вслед за этим появились протоколы IMAPS, POP3S, SMTPS, NNTPS, LDAPS. Они призваны со временем заменить своих небезопасных предков.

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

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

Таким образом, мы незаметно подошли к предмету нашей сегодняшней беседы. Говорить мы будем о программе Stunnel, которая позволяет защитить небезопасные сервисы. Механика действия довольно проста. Stunnel позволяет шифровать любое TCP-соединение с помощью SSL. При этом ни отправитель, ни получатель не подозревают о том, что трафик в процессе передачи по сети шифруется с помощью внешней программы.

Программа работает на следующих операционных системах:

  • FreeBSD
  • NetBSD
  • OpenBSD
  • GNU/Linux
  • AmigaOS
  • BeOS
  • IBM AIX
  • Mac OS X
  • OpenVMS
  • HP NonStop™ Kernel
  • HP-UX
  • Plan 9
  • QNX
  • SCO OpenServer
  • SGI IRIX
  • Solaris
  • Tru64, он же Digital Unix, он же DEC OSF/1
  • Windows 95/98/ME/NT/2000/XP

Итак, рассмотрим пример превращения небезопасных сервисов pop3, imap, smtp в их безопасные аналоги IMAPS, POP3S, SMTPS. Представим, что у нас есть сервер, функционирующий под управлением FreeBSD 4.10. Он называется freebsd410.unreal.net и доступен нашему клиенту по адресу 10.10.21.134. Кроме всего прочего, на нем работают программы dkimap, postfix, cucipop, которые и реализуют ту самую «святую троицу» протоколов. Все они принимают входящие соединения на любом сетевом интерфейсе. Postfix работает как резидентный демон, а остальные демоны запускаются с помощью inetd, как только кто-нибудь попытается присоединиться к нужным портам. Соответственно, в /etc/inetdd.conf присутствуют следующие строки:

pop3    stream  tcp     nowait  root    /usr/local/libexec/cucipop cucipop -Y

imap    stream  tcp     nowait  root    /usr/local/libexec/dkimap4 dkimap

Таким образом, картина, показываемая командой:

# netstat -na | grep LISTEN

выглядит следующим образом:

tcp4       0      0  *.25                   *.*                    LISTEN

tcp4       0      0  *.143                  *.*                    LISTEN

tcp4       0      0  *.110                  *.*                    LISTEN

Демоны ждут входящих соединений на портах 25, 110, 143. Что означают эти номера, можно узнать, пролистав файл /etc/services. Кстати, стоит убедиться, что в этом же файле есть записи, описывающие наши будущие защищенные сервисы:

imaps      993/tcp             # imap4 protocol over TLS/SSL

imaps      993/udp

pop3s      95/tcp  spop3       # pop3 protocol over TLS/SSL

pop3s      995/udp spop3

smtps      465/tcp             # smtp protocol over TLS/SSL (was ssmtp)

smtps      465/udp   

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

Рисунок 1

При отправке сообщений почтовый клиент, умеющий работать с SSL, шифрует пакеты и передает их демону stunnel. Тот в свою очередь расшифровывает их и отдает демонам imap, pop3, smtp. А почтовые демоны в ответ на запросы отдают данные в открытом виде stunnel, который шифрует их и передает клиенту. При этом ни клиент, ни демоны не догадываются о том, что общаются друг с другом через посредника.

Итак, приступаем к установке stunnel на сервер.

Предварительно в систему должен быть проинсталлирован OpenSSL, так как для правильного функционирования stunnel требуются криптоалгоритмы, реализуемые именно этой библиотекой. Для FreeBSD проводить инсталляцию удобнее всего из портов.

# cd /usr/ports/security/stunnel

# make all install

По окончании сборки будет автоматически создан поль-зователь stunnel, входящий в одноименную группу. Затем произойдет установка, и нам будет доступен stunnel версии 4.04. Сразу же после этого система начнет создавать секретный ключ и сертификат. Вы можете воспользоваться этим способом и начать отвечать на задаваемые вопросы или просто нажимать Enter и впоследствии самостоятельно создать нужные файлы. Я предпочитаю второй способ. Создаем директорию, где у нас будут храниться сертификаты и ключи.

# mkdir /usr/local/etc/stunnel/certs

# cd /usr/local/etc/stunnel/certs

Самостоятельно создаем ключи и сертификаты со сроком действия 1 год. В связи с тем, что stunnel не умеет работать с ключами, защищенными паролями, используем опцию -nodes.

# openssl req -new -x509 -days 365 -nodes -out mailserver.cert -keyout mailserver.key

Generating a 1024 bit RSA private key

................++++++

......................++++++

writing new private key to "mailserver.key"

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter ".", the field will be left blank.

-----

Country Name (2 letter code) [AU]:RU

State or Province Name (full name) [Some-State]:Rostov region

Locality Name (eg, city) []:Rostov-on-Don

Organization Name (eg, company) [Internet Widgits Pty Ltd]:Tigrisha home

Organizational Unit Name (eg, section) []:Test Lab

Common Name (eg, YOUR name) []:freebsd410.unreal.net

Email Address []:tigrisha@freebsd410.unreal.net

Обратите внимание, что для заполнения поля Common Name или CN было использовано DNS-имя сервера. Это обязательно нужно делать, иначе почтовый клиент будет постоянно возмущаться несовпадением фактического имени сервера и того, что записано в недрах сертификата. Также необходимо убедиться, что на клиентском компьютере правильно работает разрешение имени freebsd410. unreal.net.

Покончив с предыдущим пунктом, устанавливаем правильные права доступа к файлам.

# chmod 600 ./mailserver.cert ./mailserver.key

Создаем директорию, куда демон перейдет в chroot:

# mkdir /var/tmp/stunnel

# chown stunnel:stunnel /var/tmp/stunnel

# chmod 700 /var/tmp/stunnel

При запуске без параметров stunnel будет использовать файл конфигурации /usr/local/etc/stunnel/stunnel.conf. Записываем в него следующие строки:

# Ключи и сертификаты

cert = /usr/local/etc/stunnel/certs/mailserver.cert

key = /usr/local/etc/stunnel/certs/mailserver.key

# Директория, внутри которой будет работать демон

chroot = /var/tmp/stunnel

# Файл pid. pid = /stunnel.pid

# Имя пользователя и группа, с чьими правами будет работать демон

setuid = stunnel

setgid = stunnel

# Уровень подробности отладочных сообщений

debug = 7

# Имя файла протоколирования

output = /var/log/stunnel.log

# Описание наших сервисов

[pop3s]

accept  = 10.10.21.134:995

connect = 110

[imaps]

accept  = 993

connect = 143

[ssmtp]

accept  = 465

connect = 127.0.0.1:25

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

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

Запускаем stunnel и смотрим, что демон пишет в /var/log/stunnel.log. Должны увидеть что-то подобное:

2004.12.04 19:09:15 LOG5[2405:134598656]: stunnel 4.04 on i386-portbld-freebsd4.10 PTHREAD+LIBWRAP with OpenSSL 0.9.7d 17 Mar 2004

2004.12.04 19:09:15 LOG7[2405:134598656]: Snagged 64 random bytes from /root/.rnd

2004.12.04 19:09:15 LOG7[2405:134598656]: Wrote 1024 new random bytes to /root/.rnd

2004.12.04 19:09:15 LOG7[2405:134598656]: RAND_status claims sufficient entropy for the PRNG

2004.12.04 19:09:15 LOG6[2405:134598656]: PRNG seeded successfully

2004.12.04 19:09:15 LOG7[2405:134598656]: Certificate: /usr/local/etc/stunnel/certs/mailserver.cert

2004.12.04 19:09:15 LOG7[2405:134598656]: Key file: /usr/local/etc/stunnel/certs/mailserver.key

2004.12.04 19:09:15 LOG5[2405:134598656]: FD_SETSIZE=1024, file ulimit=957 -> 467 clients allowed

2004.12.04 19:09:15 LOG7[2405:134598656]: FD 6 in non-blocking mode

2004.12.04 19:09:15 LOG7[2405:134598656]: SO_REUSEADDR option set on accept socket

2004.12.04 19:09:15 LOG7[2405:134598656]: pop3s bound to 10.10.21.134:995

2004.12.04 19:09:15 LOG7[2405:134598656]: FD 7 in non-blocking mode

2004.12.04 19:09:15 LOG7[2405:134598656]: SO_REUSEADDR option set on accept socket

2004.12.04 19:09:15 LOG7[2405:134598656]: imaps bound to 0.0.0.0:993

2004.12.04 19:09:15 LOG7[2405:134598656]: FD 8 in non-blocking mode

2004.12.04 19:09:15 LOG7[2405:134598656]: SO_REUSEADDR option set on accept socket

2004.12.04 19:09:15 LOG7[2405:134598656]: ssmtp bound to 0.0.0.0:465

2004.12.04 19:09:15 LOG7[2405:134598656]: FD 9 in non-blocking mode

2004.12.04 19:09:15 LOG7[2405:134598656]: FD 10 in non-blocking mode

2004.12.04 19:09:15 LOG7[2406:134598656]: Created pid file /stunnel.pid

Теперь нужно снова посмотреть, что нам скажет команда:

# netstat -na | grep LISTEN

tcp4       0      0  *.465                  *.*                    LISTEN

tcp4       0      0  *.993                  *.*                    LISTEN

tcp4       0      0  *.995                  *.*                    LISTEN

tcp4       0      0  *.25                   *.*                    LISTEN

tcp4       0      0  *.143                  *.*                    LISTEN

tcp4       0      0  *.110                  *.*                    LISTEN

Как видите, список портов, ожидающих входящие соединения, существенно увеличился.

Самое время настроить почтовый клиент. В качестве подопытного кролика будет использоваться Microsoft Outlook Express 6. Первым делом будут не самолеты, о которых подумали поклонники советской эстрады, а копирование сертификата с почтового сервера и импортирование его в почтовый клиент. С первым заданием, я думаю, вы и сами справитесь. Подойдет любой способ, лишь бы файл mailserver.cert оказался на Windows-машине. В Outlook Express задействуем меню «Сервис –> Параметры», затем выбираем вкладку «Безопасность», незамедлительно жмем на кнопки «Сертификаты» и «Импортировать» и делаем все, как на следующих снимках.

Рисунок 2

Рисунок 3

Рисунок 4

После этого в списке доверенных центров сертификации должно появиться имя нашего сервера.

Рисунок 5

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

Рисунок 6 Рисунок 7
Рисунок 8 Рисунок 9

Рисунок 10

После этого вся принимаемая и отправляемая почта будет шифроваться с помощью SSL, а в файле /var/log/stunnel.log будут появляться подобные надписи:

2004.12.04 22:40:01 LOG7[2406:134598656]: pop3s accepted FD=11 from 10.10.21.162:32872

2004.12.04 22:40:01 LOG7[2406:134598656]: FD 11 in non-blocking mode

2004.12.04 22:40:01 LOG7[2406:134600704]: pop3s started

2004.12.04 22:40:01 LOG5[2406:134600704]: pop3s connected from 10.10.21.162:32872

2004.12.04 22:40:02 LOG7[2406:134600704]: Relying on OpenSSL RSA Blinding.

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL state (accept): before/accept initialization

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL state (accept): SSLv3 read client hello A

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL state (accept): SSLv3 write server hello A

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL state (accept): SSLv3 write certificate A

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL state (accept): SSLv3 write server done A

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL state (accept): SSLv3 flush data

2004.12.04 22:40:02 LOG7[2406:134600704]: waitforsocket: FD=11, DIR=read

2004.12.04 22:40:02 LOG7[2406:134600704]: waitforsocket: ok

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL state (accept): SSLv3 read client key exchange A

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL state (accept): SSLv3 read finished A

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL state (accept): SSLv3 write change cipher spec A

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL state (accept): SSLv3 write finished A

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL state (accept): SSLv3 flush data

2004.12.04 22:40:02 LOG7[2406:134600704]:    3 items in the session cache

2004.12.04 22:40:02 LOG7[2406:134600704]:    0 client connects (SSL_connect())

2004.12.04 22:40:02 LOG7[2406:134600704]:    0 client connects that finished

2004.12.04 22:40:02 LOG7[2406:134600704]:    0 client renegotiatations requested

2004.12.04 22:40:02 LOG7[2406:134600704]:    9 server connects (SSL_accept())

2004.12.04 22:40:02 LOG7[2406:134600704]:    9 server connects that finished

2004.12.04 22:40:02 LOG7[2406:134600704]:    0 server renegotiatiations requested

2004.12.04 22:40:02 LOG7[2406:134600704]:    1 session cache hits

2004.12.04 22:40:02 LOG7[2406:134600704]:    1 session cache misses

2004.12.04 22:40:02 LOG7[2406:134600704]:    5 session cache timeouts

2004.12.04 22:40:02 LOG6[2406:134600704]: Negotiated ciphers: AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1

2004.12.04 22:40:02 LOG7[2406:134600704]: FD 12 in non-blocking mode

2004.12.04 22:40:02 LOG7[2406:134600704]: pop3s connecting 127.0.0.1:110

2004.12.04 22:40:02 LOG7[2406:134600704]: Remote FD=12 initialized

2004.12.04 22:40:02 LOG7[2406:134600704]: Socket closed on read

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL alert (write): warning: close notify

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL write shutdown (output buffer empty)

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL alert (read): warning: close notify

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL closed on SSL_read

2004.12.04 22:40:02 LOG7[2406:134600704]: Socket write shutdown (output buffer empty)

2004.12.04 22:40:02 LOG5[2406:134600704]: Connection closed: 12678 bytes sent to SSL, 10178 bytes sent to socket

2004.12.04 22:40:02 LOG7[2406:134600704]: pop3s finished (0 left)

Для того чтобы забирать письма с сервера, в данном примере использовался POP3S, но смею вас уверить, что IMAPS будет также надежно выполнять эту задачу. Вдоволь наигравшись с Outlook Express, я принялся тестировать все почтовые клиенты, что были под рукой. Поэтому могу смело заявить: как и ожидалось, Mozilla Thunderbird 0.6 и Ximian Evolution 2.0.2 работают с SSL вполне стабильно и быстро. Единственное нарекание стоит адресовать Kmail 1.7.1, который при использовании защищенных протоколов стал шевелиться в несколько раз медленнее, чем обычно. В частности, на получение тестового письма из 500 байт у него в среднем уходило примерно 45 секунд.

The Bat, любимый многими на постсоветских просторах, тоже отлично работает в наших условиях. Тесты, описанные ниже, проводились на версии 3.0.1.33. Впрочем, думаю, что с большинством версий The Bat это тоже будет работать. Итак, для того чтобы включить ночного вампира в нашу связку, нужно установить все так же, как изображено на следующем снимке. Удивляться тому, что вместо SSL приходится выбирать TLS, не стоит. Главное, что такой подход работает.

Рисунок 11

При первой попытке соединения с сервером получаем следующее предупреждение. За исключением опечаток все в нем выглядит неплохо.

Рисунок 12

Первым делом жмем «Просмотреть сертификат». И убеждаемся в том, что он действительно принадлежит нам.

Рисунок 13

Рисунок 14

Рисунок 15

С помощью кнопки «Добавить к доверенным» завершаем процедуру.

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

Рисунок 16

Итак, мы добились того, что данные нормально передаются по сети в защищенном виде. Теперь осталось сделать так, чтобы никто, кроме stunnel, не смог воспользоваться старыми версиями наших сервисов. Для этого нужно, чтобы стандартные демоны SMTP, POP3, IMAP принимали соединения только от 127.0.0.1. Соответственно, клиенты смогут работать с сервером только через stunnel. В случае c postfix все довольно просто: необходимо всего лишь установить переменную inet_interfaces = localhost в файле main.cf и перезапустить его. А вот с cucipop и dkimap4 есть два варианта решения проблемы. Первый – запретить входящие соединения с помощью межсетевого экрана. Второй – использовать tcp wrapper. О первом способе написано достаточно много статей, поэтому давайте посмотрим, как работать с tcp wrapper. При обнаружении нового входящего соединения inetd вызывает демона tcpd. Тот в свою очередь просматривает файл /etc/host.allow и в зависимости от адреса вызывающей стороны принимает решение о том, что делать с соединением. Если соединение проходит через этот контроль, то его передают демону, который будет в дальнейшем его обслуживать. В отличие от межсетевого экрана, который для принятия решений оперирует адресами и номерами портов, tcpd работает с адресами клиентов и именами вызываемых демонов. По умолчанию в /etc/hosts.allow описано разрешение принимать данные от любых хостов. Это нам не подходит, а значит, надо удалить или закомментировать строку ALL : ALL : allow и добавить в файл вот это:

cucipop : localhost 127.0.0.1 : allow

dkimap : localhost 127.0.0.1 : allow

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

tcp4       0      0 *.465               *.*                    LISTEN

tcp4       0      0  *.993              *.*                    LISTEN

tcp4       0      0  10.10.21.134.995   *.*                    LISTEN

tcp4       0      0  127.0.0.1.25       *.*                    LISTEN

tcp4       0      0  *.143              *.*                    LISTEN

tcp4       0      0  *.110              *.*                    LISTEN

После некоторого количества тестов можно понижать уровень подробности отладочных сообщений, описываемый переменной debug в файле /usr/local/etc/stunnel/stunnel.conf. Приемлемым значением будет цифра 3.

Кстати, если нужно, чтобы stunnel автоматически запускался после перезагрузки машины, не забудьте переименовать /usr/local/etc/rc.d/stunnel.sh.sample в /usr/local/etc/rc.d/stunnel.sh. В случае, когда у нас есть клиент, способный самостоятельно работать с SSL, все выглядит довольно просто. А вот что делать, если такового нет? Этот и многие другие вопросы мы обсудим в следующей статье.


Комментарии
 
  20.03.2010 - 06:52 |  netkent

Могу помочь с настройкой stunnel, созданием ключей и ssl сертификатов пишите ICQ UIN: 238 987 959, mail: iguzeyev@mail.ru Есть опыт в решение подобных задач

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru