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

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

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

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

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

Прежде чем  начинать реализовывать политику безопасности, необходимо знать, что именно вы защищаете. Здесь вам потребуется детальный анализ. При наличии нескольких бизнес-партнеров или заказчиков следует изолировать их друг от друга таким образом, чтобы клиент X не мог добраться до конфиденциальной информации клиента Y.

При исследовании систем, закономерности функционирования кото­рых сложны или практически не поддаются описанию, целесообразно ис­пользовать элементы теории вероятностей. К числу таких систем можно отнести глобальные вычислительные сети, например Internet, платежные банковские системы и системы электронной коммерции. Наиболее подробно и полно такие системы описываются с помощью модели безопасности информационных потоков систем ИТ.[1,2]

Рассмотрим систему защиты Σ, реализующую мандатное (полномоч­ное) разграничение доступа. Без ограничения общности можно считать, что:

-  в системе используются только два уровня секретности: высокий и низкий;

- все объекты системы делятся на две непересекающиеся группы: высо­коуровневые объекты (Н), имеющие право обрабатывать информацию высокого уровня секретности, и низкоуровневые (L); все взаимодействие между Н и L осуществляется через систему защи­ты Σ.

Рис. 1. Схема взаимодействия объектов через систему защиты.

Задача системы защиты - не допустить возникновение информаци­онного потока от высокоуровневых объектов к низкоуровневым.

Пусть на множестве значений объектов системы задано вероятност­ное распределение, т.е. Н и L являются случайными величинами. Для описания и анализа информационных потоков между ними воспользуемся понятиями теории вероятностей: независимости и условного распределе­ния. С их помощью по [1,2] рассмотрим два подхода к определению безо­пасности информационных потоков, основанных на понятиях:

• информационной невыводимости;
• информационного невмешательства.

Поясним подробнее два этих понятия:

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

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

Определение 1. В системе присутствует информационный поток от высокоуровневых объектов Н к низкоуровневым L, если некое возможное значение переменной в некотором состоянии низкоуровневого объекта невозможно одновременно с возможными значениями переменных со­стояний высокоуровневых объектов.

Определение 2. Система безопасна в смысле информационной не­выводимости, если в ней отсутствуют информационные потоки вида, опи­санного в определении 1.

Более формально это определение можно дать следующим образом: нет информационного потока от Н к L тогда и только тогда, когда выпол­няется условие:

если p(H)>0, p(L)>0, то р(Н|L)>0.  (1)

Так как при p(H)>0, p(L)>0 выполняется p(L|H) =  р(Н, L)/p(H) = p(H|L)p (L)/p (H), (2)

то в условиях определения 1 из истинности неравенства р(Н|L)>0 следу­ет истинность p(L|H)>0, что предполагает отсутствие информационных потоков от низкоуровневых объектов к высокоуровневым. Таким образом, требования информационной невыводимости являются строгими и фактически предполагают изоляцию друг от друга высокоуровневых и низкоуровневых объектов системы.

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

p(L|H)=p(L), что при р(Н)>0, p(L)>0 равносильно равенству

p(H|L)=p(H). (3)

Однако если ввести параметр времени, то ограничение, данное вы­ше, слишком строгое. Если L_t описывает состояния всех низкоуровневых объектов, a H_t всех высокоуровневых объектов в момент времени t = 0,1,2,..., то нет необходимости требовать выполнения

p(H_t|L_t-1)=p(H_t), (4)

т.е. текущее значение низкоуровневых объектов может содержать ин­формацию о последующих значениях высокоуровневых объектов. Например, если низкоуровневым является некий несекретный файл, обрабатываемый пользователем с низким допуском, а высокоуровневым объектом является журнал аудита, то значение файла и операции, со­вершаемые над ним пользователем на шаге t, могут отображаться в жур­нале аудита на шаге t+1.

Казалось бы, необходимо потребовать, чтобы текущие значения низ­коуровневых объектов не зависели бы от значений высокоуровневых объ­ектов на предыдущих тактах работы системы, т.е. выполнялось для t=1,2,...

p(L_t|H _t-1) =  p(L_t) или p(H _t-1| L_t) = p(H_t-1). (5)

Здесь учитывается тот факт, что состояние системы влияет на по­следующие только через информацию, хранимую в объектах системы.

Следует отметить, что данный вариант определения соотношения L_t и H_t-1 является слишком строгим, так как предполагает независимость L_t и H_t-1. Однако значения высокоуровневых объектов на текущем шаге часто оказывает влияние на значения низкоуровневых объектов на последую­щих шагах работы системы. Рассмотрим два примера.

Пример 1. Система резервного копирования.

Для защиты низкоуровневых пользователей от сбоев системы все данные, записываемые ими в низкоуровневые файлы, предварительно копируются систе­мой в высокоуровневый аудиторский файл. В результате, если в момент времени t значение низкоуровневого файла было X, то это означает, что в момент времени t-1 высокоуровневый файл аудита содержал значение X. Налицо зависимость значе­ний L_t, и H_t-1. Однако, никакой угрозой безопасности это не является.

Пример 2. Монитор ссылок.

Монитор ссылок в реальных системах защиты является высокоуровневым субъектом, принимающим решения по запросам на доступ к объектам, полученным от других субъектов системы. Очевидно, что такое решение, полученное низко­уровневым субъектом на шаге t работы системы, содержит информацию о значении высокоуровневого монитора ссылок на предыдущем шаге.

Для платежных банковских систем, использующих кредитные карты и систем электронной коммерции более целесообразным представляется подход, обеспечивающий невозможность накопления низкоуровневыми объектами новой информа­ции о значениях высокоуровневых объектов. Более формально, необхо­димо потребовать, чтобы знание значений L_t-1 и L_t, не давало бы новой информации о Н_t-1, т.е. должно выполняться равенство

p(L_t|H_t-1, L_t-1) = p(L_t|L_t-1) для t=1,2…..  (6)

p(H_t-1|L_t ,L_t-1) = p(H_t-1|L_t-1),         (7)

т. е. тем самым запрещается обратный информационный поток из L_t в H_t-1, но не запрещается поток из L_t в H_t+1. Кроме этого, следует отметить, что решая проблемы, обозначенные в рассмотренных выше примерах, по­следнее правило запрещает временные каналы утечки информации. С учетом того, что состояние системы влияет на последующие со­стояния только через информацию, хранимую в объектах системы, дадим определение модели безопасности информационных потоков.

Определение 3. Система безопасна в смысле информационного не­вмешательства, если выполняется равенство

p(L_t|H_s,L_s) =  p(L_t| L_s), где s,t = 0,1,2, и s<t. (8)

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

Интерпретируя полученные результаты к системам электронной коммерции, можно сформулировать следующие функциональные требования безопасности данных систем ИТ:

1) любые транзакции в системе не должны приводить к нарушению конфиденциальности, целостности и аутентичности передаваемых данных;

2) транзакции и порождаемые ими информационные потоки не должны вызывать накопления низкоуровневыми объектами (личные базы данных продавцов/покупателей, архивные файлы, системные журналы и др.) информации о высокоуровневых объектах (номера платежных карт, их PIN-коды, количество денежных средств на счетах покупателя, продавца и др.);

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

Теперь рассмотрим основные положения модели безопасности информационных потоков систем ИТ для отдельных объектов информатизации (например, сайтов, построенных на основе CMS). В настоящее время любой разработчик может применить как написанные им самим управляющие серверные программы на языках Интернет-программирования (PHP, Perl, CGI и др.), так и применить для управления своим сайтом готовые «движки», созданные другими программистами. На данные момент существует много неплохих как коммерческих, так и некоммерческих систем управления сайтами (CMS).

Для исследования уязвимостей и методов атак злоумышленников  возьмем для примера «открытые» некоммерческие проекты (под лицензией GNU/GPL, т.е. с открытым исходным кодом). Одним из наиболее распространненых таких проектов является «движок» для сайта PHP-Nuke (в качестве рабочей версии возьмем версию 7.3. данного пакета, хотя она и не является самой свежей версией). Для работы с данным пакетом нам необходимо иметь следующее программное обеспечение: Apache Web Server, PHP версии 4.2.x и выше, MySQL сервер. Особенности разработки сайтов на данном «движке» мы рассматривать здесь не будем. Допустим сайт с применением данной CMS уже создан и размещен в сети Интернет на сервере хостинг-провайдера. Какие же уязвимости можно обнаружить и каким атакам может подвергнуться такой сайт?

Дело в том, что такой сайт, в отличие от  статичного HTML проекта имеет более сложную структуру:

Во-первых, это базы данных (с использованием СУБД MySQL), где хранится вся содержательная информация (контент) сайта, в том числе и конфиденциальная, а именно  пароли администраторов сайта, аутентификационные параметры зарегистрированных пользователей, счета Интернет-магазина, данные кредитных карт и т.д.

Во-вторых, это служебные файлы, типа config.php, admin.php и др., доступ к которым должен иметь только администратор сайта с самым высоким приоритетом.

В–третьих,  это структурные элементы самого «движка», т.е. программы, написанные на языке PHP для обновления и разработки базовых элементов сайта (блоков, модулей, форумов, досок объявлений, гостевых книг и т.д.).

И все эти, выше перечисленные нами структуры имеют уязвимости, а именно, базы данных могут быть подвержены SQL инъекциям. Т.е. удаленный пользователь (злоумышленник) может внедрить SQL команды и выполнить XSS нападение, раскрыть инсталляционный путь.

Рассмотрим  схематично действия злоумышленника при реальном нападении на реальный сайт, написанный на языке PHP (подробные действия  злоумышленника, реальные названия хакерских утилит и настоящий адрес сайта мы здесь не приводим по морально-этическим соображениям):

1. Злоумышленник находит уязвимость в нашем сайте, например, в базе данных MySQL. О наличии уязвимостей в определенных системах можно узнать как из открытых источников (форумов по безопасности в сети Интернет, специализированных книг, отчетов и журналов), так и определить их самостоятельно опытным путем.
2. Затем он выполняет SQL команду (прямо из строки своего браузера) с целью атаки на базу данных MySQL. Цель злоумышленника  - получить доступ к базе данных и узнать имя и пароль администратора сайта.
3. Злоумышленник получает доступ к базе данных с помощью SQL-запроса и узнает аутентификационные данные администратора сайта (login, password), но правда, в хэшированном виде (данные зашифрованы). Таким образом, происходит недопустимая утечка информации от высокоуровневых объектов к низкоуровневым объектам (см. выше описание «Модели безопасности информационных потоков систем ИТ»).
4. С помощью специального хакерского программного обеспечения злоумышленник получает пароль администратора в явном виде.
5. Потом злоумышленник    заходит в административную панель управления сайтом (через обычный веб-браузер, например, через Internet Explorer), т.е. набирает адрес: http://www.site.com/admin.php (по соображениям конфиденциальности реальный адрес атакованного сайта не приводится). В появившейся панели атакующий вводит полученные им путем взлома базы данных «имя» и «пароль» администратора. Т.е. бывший ранее «низкоуровневым объектом» хакер, становится высокоуровневым объектом с самым высоким приоритетом в данной системе, т.е. администратором сайта.
6. В следующий момент времени в высокоуровневом системном журнале (log-файле), доступном веб-мастеру сайта отображается следующая информация об атаке:

200.31.23.195 - - [14/Feb/2005:15:46:05 +0000] "GET /admin.php HTTP/1.0" 200 17789 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5"

200.31.23.195 - - [14/Feb/2005:15:46:45 +0000] "POST /admin.php HTTP/1.0" 200 37049 "http://www.site.com/admin.php" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5"

200.31.23.195 - - [14/Feb/2005:15:46:56 +0000] 404 237 "http://www.site.com/admin.php" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5"

200.31.23.195 - - [14/Feb/2005:15:47:07 +0000] "GET /images/admin/stories.gif HTTP/1.0" 200 2359 "http://www.site.com/admin.php" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5"

200.31.23.195 - - [14/Feb/2005:15:47:46 +0000] "GET /admin.php?op=topicsmanager HTTP/1.0" 200 33816 "http://www.site.com/admin.php" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5"

200.31.23.195 - - [14/Feb/2005:15:48:57 +0000] "GET /admin.php?op=Configure HTTP/1.0" 200 54273 "http://www.site.com/admin.php?op=topicsmanager" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5"

200.31.23.195 - - [14/Feb/2005:15:51:04 +0000] "GET /admin.php?op=editmsg&mid=2 HTTP/1.0" 200 33546 "http://www.site.com/index.php" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5"

200.31.23.195 - - [14/Feb/2005:15:55:10 +0000] "GET /admin.php?op=messages HTTP/1.0" 200 33947 "http://www.site.com/admin.php?op=editmsg&mid=2" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5"

Выше приведен фрагмент системного журнала (log-файла) реально атакованного сайта. Из этих системных записей ясна логика действий хакера. Он входит в систему как администратор, заменяет текст на главной странице сайта на свой собственный, чтобы показать владельцам сайта, что сайт взломан. А затем регистрирует нового администратора (с новым именем и паролем). Таким образом, злоумышленник получает высокоуровневый доступ к данному сайту, т.е. исходя из определений 1 и 2 «Модели безопасности информационных потоков систем ИТ» наш сайт является атакованным. Злоумышленник получил полный контроль над сайтом.

Дальнейшие действия хакера:

1)      Модификация сайта (замена главной страницы и другой важной информации).

2)      Получение конфиденциальной информации (аутентификационных данных других пользователей сайта и др. информации).

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

4)      Дискредитация владельца сайта (путем выкладывания на сайте компрометирующей его информации).

5)      Попытки мошенничества (создание ложных неоплаченных заказов, если взломан Интернет-магазин).

6)      Передача конфиденциальной информации конкурентам (если атаке подвергся корпоративный сайт).

7)      Внедрение вредоносных программ и превращение взломанного веб-сервера в спам-сервер.

8)      Полное уничтожение сайта.

9)      Другие деструктивные действия.

После взлома владелец (администратор или веб-мастер сайта) обязательно должны принять следующие меры безопасности.

Из log-файла известен IP-адресс нападающего, допустим, что это адрес - 200.31.23.195. С помощью специальных утилит системного администрирования  выясняем:

-          Traceroute - 200.31.23.195

-          SmartWhois - 200.31.23.195

-          NsLookup - 200.31.23.195

-          Ping - 200.31.23.195

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

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

В дальнейшем надо обязательно сменить пароль администратора сайта и обязательно удалить из системы созданных злоумышленником «ложных администраторов». Также нужно обязательно произвести обновление (update) базы данных (из ранее сохраненного архива резервного копирования), в случае, если они повреждены злоумышленником.

Для построения системы защиты сайта (написанного на языке PHP, для примера берем сайт на «движке» PHP-Nuke) надо предпринять следующие действия:

1. Постоянно получать свежую информацию об обнаруженных новых уязвимостях, «дырах» и др. «слабых» местах используемых систем. Для этого нужно читать специальную литературу, посещать сайты, порталы и форумы в сети, посвященные проблемам безопасности информации.

2.  Если используются уже готовые коммерческие или «открытые» некоммерческие CMS, то стараться использовать самые свежие версии программ, а также регулярно скачивать с сайтов разработчика патчи, «заплатки», специальные программы, которые «закрывают» уязвимости в системах.

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

4.  При выборе паролей никогда не выбирать одинаковые пароли для FTP-доступа к сайту и панели администратора. В качестве пароля никогда не выбирайте осмысленные имена, даты рождения и т.д. (например: Irina, 20051979). Пароль должен быть длинным и сложным набором случайных символов (числа и буквы), желательно набранным в другой раскладке клавиатуры (например, набрать в русской раскладке клавиатуры пароль: tyKn574hjd1hfjoGw).  Также надо регулярно менять пароли.

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

6.  Файл config.php необходимо положить в какую-нибудь закрытую директорию (не в корневую), т.е. «спрятать». Вместо него оставьте дубликат файла с таким содержанием:

<?php include("путь к файлу/config.php"); ?>

7. Не оставляйте стандартный префикс таблиц в базе данных MySQL (замените на свой).

8.  Действительно ценные документы, например, данные кредитных карт клиентов Интернет-магазина, (если Вам их необходимо хранить на сервере) защищайте средствами самого сервера, к примеру при помощи .htpasswd.

9. При помощи файла .htaccess или просто изменив настройки сервера, запретите вывод любых ошибок на экран (ниже приведем фрагмент кода).

php_flag display_errors off

php_flag log_errors on

php_value error_log /home/ваш_путь/web/php_error.log

php_value error_reporting 15

10. Определите файлы к которым не запрещен прямой доступ (это можно сделать, написав небольшую программку на языке PHP). Затем, когда Вы нашли несколько таких файлов, надо написать файл .htaccess (код для него см. ниже) и положить такие файлы в каждую папку сайта.

<filesmatch "\.php$">

deny from all

</filesmatch>

11. Защитите панель администратора, для этого нужно грамотно составить файл .htaccess. Это файл гибкой настройки веб-сервера Apache. "Гибкий" обозначает, что как только Вы поменяли что-то в этом файле, изменения тут же вступают в силу. С помощью него можно переопределить многие директивы из файла httpd.conf (этот файл является главным конфигурационным файлом сервера Apache и его действия распространяются полностью на всех пользователей данной копии Apache). В случаях, когда у Вас нет доступа к файлу настройки Apache (тот же виртуальный хостинг), Вам поможет именно этот файл. Этот файл не доступен веб-пользователю из браузера. Если файл .htaccess расположен в корневой директории сервера, то его действия распространяется на весь сервер, кроме тех папок, где находится другой файл .htaccess (и кроме всех папок "ниже" этой папки со вторым .htaccess). Файл имеет название именно "точка" htaccess, должен быть записан в UNIX-формате.

Теперь приведем главные моменты, которые нужно отразить в данном файле:

-          создаем файл со следующим кодом:

<Files ~ "\admin.php$">

AuthName "Administration Zone"

AuthType Basic

AuthUserFile /pub/home/htdocs/files/.htpasswd

require valid-user

</Files>

и кладем его в корневую директорию сайта. Обратите внимание на строку в которой указан путь (полный путь от корня сервера) до файла .htpasswd. Его можно размещать в любом месте Вашего сервера, желательно если он будет размещен вне директории для публичных файлов; затем нам нужно создать файл .htpasswd, в котором будут храниться имя  и пароль для входа в админ-панель (рекомендации по выбору паролей см. выше в п.4.);

-          если у Вас постоянный IP-адрес, то можно устроить проверку на IP  изменив .htaccess таким образом:

<Files ~ "\admin.php$">

order allow deny

deny from all

allow from 192.168.0.199

</Files>

-  на всякий случай создадим еще в каталоге /admin свой .htaccess, который запретит прямой доступ к файлам:

<filesmatch "\.php$">

deny from all

</filesmatch>

-  также в файле .htaccess можно отразить те IP-адреса, которым вообще будет закрыт доступ к Вашему сайту (например, Вам известна маска IP-адресов с которой регулярно производятся атаки на сайт или приходят подозрительные посетители). [3]

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

Вышеприведенные меры безопасности пригодятся (с небольшими коррективами) и для пользователей других некоммерческих или коммерческих CMS (необязательно PHP-Nuke), а также для программистов, самостоятельно разрабатывающих системы управления собственными сайтами на языке PHP.

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

Литература:

1. Девянин П.Н., Михальский О.О., Правиков Д.И., Щербаков А.Ю. Теоретические основы компьютерной безопасности: Учебное  пособие для вузов. М.: Радио и связь, 2000.-192 с.
2. McLean J., John D. A Comment on the “Basic Securite Theorem” of Bell and LaPadula //Information Processing Letters.- 1985. – Vol.20 N2, Feb.
3. Портал «PHP Nuke по-русски» http://rus-phpnuke.com/index.php. Материалы форумов.

В. А. АРТАМОНОВ,  Е. В. АРТАМОНОВА

Отправить статью в социальные сети, на печать, e-mail и в другие сервисы: