Развернуть сервер на виртуальной машине
Удобный веб сервер на Virtualbox
Когда делаешь простые сайты на WordPress, то с вебсервером все просто, поставил себе Xampp и спокойно работаешь.
Но приходит момент когда начинаешь заниматься серьезными проектами, а там уже конфигурация на сервере не совсем обычная и пользоваться Xampp не совсем удобно, к тому же у меня аллергия на Apache.
Захотелось хороший, живой вебсервер по типу выделеного сервера, но на своем компе, при этом чтобы пользоваться было удобно, локально.
Есть еще вариант — просто у себя поднять все, но есть загвоздка, если что нибудь сломается, упадет жесткий диск, или еще что нибудь, то потом опять все собирать будет лень, а так просто можно сделать бэкап файла виртуальной машины, так же получаем независимое окружение.
Поэтому я поднял дебиан на виртуальной машине (virtualbox) и настроил nginx+phpfpm за пару часов, но это не очередное хау ту по связке nginx+phpfpm, мы делаем готовое решение по типу xampp.
Подготовка
Итак, мы имеем свежеустановленный Debian 7 (wheezy). Виртуальная машина имеет имя webserver. На локальной машине установлен так же Debian wheezy.
Первым делом хотелось бы избавиться от диалогового окна и использовать ssh.
Выключаем виртуальную машину и пишем:
Заодно пробросим 80 порт для вебсервера.
Порты меньше 1024 может открывать только root (Спасибо or10n), поэтому я просто пробросил 8888 порт и перенаправил с 80 порта на 8888.
Вставляем до exit 0
Тут вместо 10.0.2.15 может быть другой ip, смотрите вывод команды ifconfig на eth0.
Запускаем виртуальную машину в фоне, это очень удобно, прошу заметить, что запускаем под обычным пользователем, у которого находится виртуальная машина webserver.
Все, мы пробросили 2222 порт на 22 внутренний, 80 порт будет работать, позже увидим. Пробуем коннектиться:
Настраиваем php-fpm.
Поскольку тут нам париться с безопасностью не надо, поэтому все будет работать от одного юзера www-data.
Так же мы будем обращаться через сокет. Предлагаю готовый конфиг, на самом деле я там особо своего ничего не добавлял, не забываем делать бэкапы.
Здесь опять же дефолт, можете вообще этого не делать, т.к. это тот же конфиг только без комментариев, но мне так проще ореинтироваться в конфиге.
Теперь надо подготовить пулл, который будет обрабатывать наши php запросы. Приводим конфиг к следующему виду.
Параметры pm хорошо описаны на других ресурсах, поэтому тут я ничего не буду объяснять, просто держите готовое.
Осталось поправить php.ini. На самом деле кого то может устроить и дефолтный, он неплохой. Но я все же приведу свой.
Конфиг большой и необязательный, поэтому выкладываю сюда pastebin.com/AAudu4sh
Настраиваем nginx.
В общем остается проблема с конфигами, лень каждый раз лезть на сервер, добавлять конфиг, перезагружать nginx. Поэтому собрал универсальный конфиг.
После можно будет просто создать папку, залить файлы и работать. Сказано, сделано. Вот Вам готовый конфиг nginx:
Вставляем вышеприведеный конфиг
Я не претендую на то что конфиг хорош и идеален, но он у меня работает и проблем пока не возникало. Я буду очень рад если тут найдутся люди которым есть что сюда добавить.
Ну все, осталось только настроить дериктории. Немного поясню как у нас будет все происходить.
Так же будут логи, access и error.
Осталось поставить phpmyadmin.
На сервере выполняем
Все, phpmyadmin готов к труду и обороне. можно его теперь найти по адресу phpmyadmin.l
Итак, вебсервер у нас готов, осталось сделать так чтобы он стартовал при загрузке, сохранялся при выключении и перезагрузке, и при этом не было окна состояния.
Немного опишу стратегию, после того как виртуальная машина загрузится, мы при помощи sshfs маунтим директорию с сайтами, и я сделал это автоматом.
Так же мне лень каждый раз редактировать файл /etc/hosts при добавлении очередного сайта, поэтому мы все это автоматизируем.
Автоматизация
Делаем авторизацию по ключу
Остановить демоны nginx и php5-fpm, и установить домашнюю дерикторию для юзера www-data.
Сгенерировать ключ от рута, и после поместить публичный в файл /home/www-data/.ssh/authorized_keys
На клиенте проверяем:
Если зашли без пароля, то все хорошо, если нет, то что-то Вы сделали не так с ключами.
Теперь осталось создать 2 скрипта.
1) Скрипт проверки доступности виртуальной машины и автоматический маунтинг, так же генерация файла /etc/hosts.
Вставляем следующий код
На правильность кода я не претендую, и буду рад тому кто найдет там баги. Но у меня он работает исправно.
Удобство скрипта в том что даже если перезагрузите виртуальную машину, ничего не поломается и все будет хорошо.
Теперь делаем его исполняемым
2) Небольшой скрипт который будет запускать и останавливать вебсервер.
Вставляем следующий код
darkrain — заменить на вашего юзера, т.к. созданая машина находится в подчинении у него, а не у рута.
Опять же я тут не профи, буду признателен если меня поправят, но это работает.
Выставляем права, и добавляем в список сервисов
Осталось создать каталог где будут видны наши сайты
Рестартуем наш сервер
Все, теперь все счастливы и довольны, создаем для теста:
Ждмем 60 секунд, и идем в браузер по адресу testsite.ru.l
Ну все, мы закончили! Можно забыть про то что у нас есть вообще виртуальная машина, пока конечно не понадобиться поставить какую нибудь либу или еще что-то может понадобиться.
Теперь чтобы работать с новым сайтом я просто создам папку с именем домена в /mnt/webserver, и просто буду работать не отвлекаясь.
Здесь более менее понятно описано про php-fpm, про пулы и прочее manualpages.pro/node/31
Остальная информация была взята по крупицам из Google.
Спасибо огромное тому кто мне дал инвайт! Да, к сожалению я так и не понял кто это.
Спасибо НЛО за инвайт!
Создание сервера в Windows 7 с помощью Virtualbox
Привет, всем!
Хочу рассказать о том как я создавал веб-сервер для разработки и тестирования PHP приложений на локальной машине и как потом я его «вывел в свет».
Предыстория
В качестве собственного и профессионального развития я решил более тесно познакомится с Linux системой и, в частности, с настройкой веб-сервисов. До этого для разработки и тестирования PHP приложений я пользовался пакетом Denwer для Windows (apache+php+mysql), который вообщем-то со своей задачей справлялся, но не отражал (и не отражает) современной действительности — все-таки хостинг с Windows не так популярен.
Желание иметь полный доступ к серверу и нежелание платить за это удовольствие исключили из рассмотрения вариант покупки VPS. А потому я решил организовать Linux сервер на своем локальном компьютере.
Задача
Инвентарь
Windows 7 Home Basic
VirtualBox 4.0.8
Образ ubuntu-11.04-server-i386.iso
Приступим
Первый пункт, наверное самый простой. Virtualbox обладает простым интерфейсом и процесс создания виртуальной машины не вызывает трудностей. Для своего сервера я выбрал минимальные настройки производительности — (128Мб оперативной памяти, usb устройства отключены, никаких графических ускорений и прочих изысков — для сервера должно быть ок ), чтобы не слишком загружать основную систему.
Параметры сети
В меню Virtualbox в настройках сети для виртуальной машины в качестве типа подключения для первого сетевого адаптера указываем NAT. Тогда сеть в системе поднимется сама и машина будет иметь доступ к внешнему сетевому соединению Windows. Проблема в том, что при таких настройках, Linux система остается недоступной из основной системы.
Но решение есть! Указываем для второго сетевого адаптера значение «Виртуальный адаптер хоста». При установке Virtualbox в системе автоматически дополнительно создается сетевое подключение «VirtualBox Host-Only Network», которое нам пригодится в этом случае. Заходим в «Центр управления сетями и общим доступом» Windows. В настройках этого соединения указываем стандартные для данной задачи параметры: ip — 192.168.0.1, netmask — 255.255.255.0.
Осталось указать нужные параметры в виртуальной системе. Дописываем нужные строки в файл «/etc/network/interfaces»
iface eth1 inet static
address 192.168.0.2
netmask 255.255.255.0
auto eth1
перезапускаем сеть и можно попробовать пинговать Linux.
Таким образом: а) Linux имеет доступ в интернет через сетевое соединение Windows
б) Windows видит сервер и может к нему обращаться по ip — 192.168.0.2 (для удобства можно дописать в файл hosts какое-нибудь удобоваримое имя для этого ip, например «webserver»)
Конфигурация Linux
Что я хочу от своего сервера?
Во-первых, мне нужен веб-сервер с поддержкой PHP — возможность разрабатывать и тестировать приложения на локальной машине меня весьма радует
Во-вторых, мне нужна база данных — MySQL и/или PostgreSQL
В-третьих, мне очень удобно когда сохранив файл в IDE, можно тут же запустив скрипт в консоли или обновив страницу в браузере увидеть изменения. Таким образом, используемая мной IDE также должна иметь доступ к www каталогу на сервере. (чтобы не нужно было дополнительно копировать что-либо куда-нибудь)
В-четвертых, мой сервер должен быть доступен из внешней среды.
Поскольку моя статья не о настройке apache, тонкостях php.ini или бэкапе mysql, то первые три пункта я пропущу и описывать не буду. Скажу лишь, что все что сделал я (что не заработало сразу после установки) — это поправил вывод ошибок в php.ini (по умолчанию был полностью отключен вывод вообще всех ошибок), а также установил xdebug. Третий пункт решается установкой samba и небольшой модификацией файла конфигурации «etc/samba/smb.conf» в разделе Share Definitions, с целью разрешить пользователям доступ к своей директории в home (именно в эту папку помещен DocumentRoot сервера apache).
На данный момент уже можно получить доступ к серверу не только по ssh (open ssh server ставится по умолчанию) через putty, но и по samba — подключив пользовательскую директорию как сетевой диск в Windows.
А вот на последнем пункте я остановлюсь подробнее.
Доступ к серверу из внешнего мира
По сути, задача стоит в том, чтобы все запросы на 80 порт к моему компьютеру перенаправлять на 80 порт моего локального сервера. Такой вот небольшой прокси. Здесь на помощь приходит утилита netsh встроенная в Windows 7.
c:\>netsh
netsh>interface portproxy
netsh interface portproxy>add v4tov4 listenport=80 connectaddress=192.168.0.2 connectport=80 protocol=tcp
Теперь виртуальный веб-сервер доступен при обращении к моему компьютеру по внешнему ip-адресу.
Если для вас, как и для меня, белый внешний ip адрес является роскошью и проще говоря, его нет, то еще одна часть истории для вас!
Установка сервера Linux + (Nginx + Apache) + PostgreSQL + PHP на VirtualBox (Ubuntu Server 16.04.3 LTS)
На просторах интернета не нашел единого рецепта по установке и настройке такого, довольно нестандартного сервера. Решил написать свой рецепт.
Принцип работы следующий:
Статические данные (файлы) отдает Nginx, а динамикой занимается Apache.
Начнем.
Установим VirtualBox
Подготовим VirtualBox к установке Ubuntu Server 16.04.3 LTS
Важно: У меня 8 ГБ оперативной памяти, и в моем случае, двух гигабайт будет достаточно. У вас может быть иначе.
Размер жесткого диска: 15 ГБ
Другие параметры оставим по умолчанию.
Сменим тип подключения с NAT на Сетевой мост.
Установка Ubuntu Server 16.04.3 LTS
Важно: Читайте подсказку внизу экрана.
Продолжаем.
Выбираем полное клонирование.
Жмем клонировать. У меня клонирование длилось две минуты.
Установим PuTTY, для доступа через SSH
Подключение через SSH к серверу
Мы должны наблюдать следующее:
Вводим логин, после пароль.
SSH соединение успешно настроено, теперь можно приступать к настройке (Nginx + Apache) + PostgreSQL + PHP.
Установка и настройка (Nginx + Apache) + PostgreSQL + PHP
make install
Теперь, на сервер PostgreSQL, в нужную базу данных, где хотим использовать беззнаковые и однобайтовые числа, отправим:
Вернемся в корневой каталог
cd /
Установим Nginx, но перед этим остановим Apache, дабы он не занимал порт 80, иначе Nginx не установится.
service apache2 stop
Установка Nginx
apt-get install nginx
Отлично, теперь остановим и Nginx
service nginx stop
Настройка Apache
a2dismod mpm_event
a2enconf php7.2-fpm
Сменим порт Apache
nano /etc/apache2/ports.conf
Заменить
127.0.0.1 — означает то, что к Apache можно обратиться только по локальному адресу.
8080 — можете поставить любой свободный порт.
Перейдем в папку с доступными сайтами
cd /etc/apache2/sites-available
Создадим конфигурационный файл нашего сайда
nano domain-name.local.conf
И привести его к такому виду:
Посмотрим, что у нас лежит в /var/www
cd /var/www/
tar xvf rpaf_v0.8.4.tar
cd mod_rpaf-0.8.4/
Теперь скомпилируем
make
make install
Выходим в корневой каталог
cd /
Хорошо, продолжим настройку Apache.
nano /etc/apache2/apache2.conf
Заменить
Приведем в порядок rpaf.conf
nano /etc/apache2/mods-available/rpaf.conf
Приведем его к такому виду:
Включим наш сайт в Apache.
a2ensite domain-name.local.conf
И запустим наш Apache.
service apache2 start
C Apache закончили.
Настроим Nginx
nano /etc/nginx/sites-available/domain-name.local
Привести к такому виду:
И сразу перейдем в нее
\c test_db
Подключим расширение pguint
И создадим тестовую таблицу
Заполним таблицу тестовыми данными
Посмотрим содержимое таблицы test_tb
Теперь проверим, и убедимся, что это работает
Отлично, мы настроили (Nginx + Apache) + PostgreSQL + PHP и он исправно работает.
Настроим FTP доступ к сайту
Все хорошо, попробуем создать каталог.
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:
Властелин виртуальных машин: практические советы по развертыванию виртуальной инфраструктуры
Содержание статьи
Современные процессоры настолько мощны, что позволяют эмулировать самих себя
практически без тормозов. В области системного администрирования это находит
большое практическое применение. Но не все так просто, и прежде, чем возводить
виртуальную систему, следует взвесить все аргументы за и против.
Двери в виртуальный мир
За последние годы на рынке появилось множество виртуальных машин — от
узкоспециализированных (Bochs, eEye) до эмуляторов общего
назначения (VMware, VirtualBox, QEMU, XEN,
Virtual PC). Интерес к виртуализации растет, а сами эмуляторы по ходу дела
осваивают новые профессии, становясь все более и более привлекательными
игрушками в глазах системных администраторов. Именно «игрушками» – потому что к
введению в промышленную эксплуатацию существующие эмуляторы еще не готовы. Ущерб
от их использования намного превышает стоимость живого железа, которое они
призваны заменять (не говоря уже о том, что большинство эмуляторов
распространяются на коммерческой основе или, попросту, стоят денег).
Тем не менее, играться с виртуальными машинами можно и нужно! Есть все
основания ожидать, что в ближайшие несколько лет разработчики вылижут баги и
доведут эмуляторы до ума, а потому осваивать их надо прямо сейчас, чтобы потом
не разворачивать виртуальную инфраструктуру впопыхах.
Существует, по меньшей мере, три типа виртуальных машин (не считая
гибридов). К самым первым (и самым древним) относятся машины с полной
эмуляцией. Классический пример — Bochs. Тормозит ужасно, зато позволяет
эмулировать «чужеродные» архитектуры, например, x86 на Мотороллере или x86-64 на
x86. Возвести многопроцессорную машину на однопроцессорной? Без проблем. Причем,
основная операционная система надежно изолирована от гостевых виртуальных машин
и причинить ей ущерб невероятно трудно. Bochs очень хорошо подходит для
экспериментов с вирусами, червями и прочим зловредным ПО. Также его можно
использовать для того, чтобы опробовать 64-разрядные операционные системы,
прежде чем решиться покупать x86-64 – но высокие накладные расходы на эмуляцию
(даже с учетом оптимизации и кэширования инструкций) предъявляют жесткие
требования к аппаратной оснастке базовой машины. И проблема здесь даже не в том,
что WinXP на P-4 под «Борщем» стартует около суток. Она вообще не стартует!
Поскольку куча операций отваливается по тайм-ауту, в частности, если процедура
инициализации драйвера выполняется свыше 10 секунд, система автоматически
выгружает драйвер со всеми вытекающими отсюда последствиями.
Динамические виртуальные машины (QEMU, VMware, VirtualBox) эмулируют
лишь привилегированные инструкции (равно, как и непривилегированные инструкции,
имеющие доступ к системным данным). За счет этого скорость эмуляции возрастает
на несколько порядков, и на P-III 733 уже можно комфортно работать в среде
виртуального Win2k3, а на P-4 все просто летает. Расплатой за скорость
становится принципиальная невозможность эмуляции «чужеродных» архитектур, плюс
потенциальный риск атаки на основную операционную систему из гостевой.
Теоретически, создать надежный динамический эмулятор вполне возможно, но
практически… это же тысячи строк на Си/Си++ и мегабайты кода! К тому же,
разработчики QEMU и VMware даже не пытались защитить основную систему от атаки
со стороны гостевых виртуальных машин, чем с успехом пользуются вирусы и черви.
Аппаратная виртуализация (поддерживаемая последними моделями
процессоров Intel и AMD) устраняет ляпы в x86-архитектуре, где системные данные
надежно защищены только от записи, но могут быть прочитаны с прикладного уровня
легальными непривилегированными командами. Это вынуждает эмулятор просматривать
блок кода перед его выполнением, на что расходуется время. В процессорах фирмы
Motorola таких дефектов нет, и потому динамическая эмуляция на них работает
намного быстрее (и без всякой новомодной аппаратной поддержки!). Но рынок
захватила x86-архитектура, вытеснив Motorol’у, и потому аппаратную виртуализацию
встречают с очень большим энтузиазмом. Теоретически, скорость эмуляции должна
вплотную приближаться к «живому» процессору, поскольку накладные расходы на
виртуализацию близки к нулю. Однако, помимо процессора, виртуальная машина
вынуждена эмулировать еще и оборудование. Без жестких дисков ведь не обойтись, а
давать прямой доступ к физическим хардам — самоубийство. В этом причина того,
что производительность виртуальных машин (даже с поддержкой аппаратной эмуляции)
существенно отстает от живого железа, но все-таки обгоняет динамическую
эмуляцию.
Естественно, за повышение скорости приходится платить. Во-первых, необходимо
приобрести процессор с поддержкой аппаратной виртуализации (ладно, это не
проблема, приобретем в ходе очередного планового апгрейда). Во-вторых (а вот это
уже действительно серьезно) — процессоры содержат кучу дефектов, позволяющих
воздействовать на основную операционную систему из гостевых виртуальных машин.
Исправить ошибку в процессоре намного сложнее, чем в полностью программном
эмуляторе! И что самое неприятное – спонтанные падения основной системы
происходят даже без всякой атаки со стороны вредоносного кода! Словом,
аппаратная виртуализация до сих пор остается плохо отлаженной игрушкой, не
готовой к промышленному внедрению. Несмотря на это, Microsoft уже включила
эмулятор с поддержкой аппаратной виртуализации в состав Win2k8, конкурирующий с
бесплатным проектом XEN.
Виртуальные сервера
Как можно использовать виртуальную машину в корпоративной или офисной сети?
Например, поднять виртуальный сервер. А что? Допустим, нам нужен публичный WEB и
приватный SQL. По соображениям безопасности, публичный сервер должен быть
расположен в так называемой демилитаризованной (DMZ) зоне, а приватный SQL –
внутри локальной сети, обнесенной по периметру глубоким защитным рвом
(брандмауэром). Что требует двух машин. А как быть, если в наличии имеется
только одна?
Теоретически (подчеркиваю!), можно поднять VMware или Virtual PC, разместив
публичный WEB-сервер на виртуальной машине, а приватный SQL – на основной. И это
как бы будет работать. «Как бы» – потому что для достижения приемлемого уровня
производительности даже при поддержке аппаратной виртуализации нам понадобится
довольно мощное железо, способное тянуть эмулятор с разумной скоростью. Значит,
много сэкономить все равно не удастся, а если добавить к этой сумме издержки от
неизбежных атак на виртуальную машину и сбои самой виртуальной машины, в
долгосрочной перспективе мы имеем весьма внушительные убытки. Купить два
отдельных физических сервера — дешевле, да и работать они будут намного
стабильнее. А если денег на железо нет, то лучше отказаться от DMZ-зон, поселив
публичные и приватные сервисы на одной машине и запретив приватным сервисам
принимать трафик с внешних интерфейсов. А для надежности – еще и закрыть порты
на брандмауэре. Как говорится, дешево и сердито, но это все-таки лучше, чем
возня с виртуальными машинами.
Загон для вирусов
Достаточно часто виртуальные машины используются для экспериментов с
потенциально небезопасным программным обеспечением, полученным из ненадежных
источников. Антивирусная проверка — не слишком-то хорошее средство для поиска
неизвестных или модифицированных червей, вирусов и руткитов. Вредителям хорошо
известно, как «ослепить» проактивные технологии и эвристические анализаторы.
Утилиты, ориентированные на поиск руткитов, хорошо работают лишь в первые дни
своего появления, а затем хакеры находят обходной путь.
Прямое сравнение дисковых образов палит все руткиты, червей и вирусы без
исключения (конечно, при условии, что они вносят изменения в файловую систему, а
не ограничиваются заражением одной лишь оперативной памяти, умирая при
перезагрузке). Алгоритм поиска заразы выглядит так: снимаем образ стерильной
системы, сохраняя его в надежном месте, устанавливаем новое программное
обеспечение, снимаем еще один образ. Монтируем оба образа на заведомо не
зараженную систему и сравниваем их. Тривиальное пофайловое сравнение выявляет
до 90% малвари. Остальные 10% обнаруживает побайтовое сравнение,
«вытягивающее» вирусы, прячущиеся в NTFS-потоках или других местах (работая с
диском на низком уровне, мы должны знать все базовые структуры файловой системы,
подробно описанные в моей книге «Техника восстановления данных», электронную
копию которой можно бесплатно скачать здесь:
nezumi.org.ru/recover-full-rus.zip).
Естественно, проводить подобные эксперименты лучше всего под эмулятором. Так
намного проще оперировать образами виртуальных жестких дисков, да и выделять
отдельную (физическую) машину не потребуется. Удобство, простота и экономия —
налицо. Но простота хуже воровства, и экономия на выделенной машине до добра не
доводит. Если виртуальная машина соединена с основной системой виртуальной
сетью, то черви могут атаковать базовую операционную систему, используя дыры в
сетевых службах. Администратору следует либо своевременно устанавливать все
заплатки, либо отключить вирусный загон от Сети вообще – не забывая про
расшаренные ресурсы. Виртуальная машина VMware поддерживает их в обход
Ethernet-адаптера. Шары продолжают работать даже после удаления виртуальной
сетевой карты, и подвержены сразу двум типам атак — через дыры в сервисе «общих
папок» и путем засылки червей, модифицирующих шаблон папки, автоматически
«подхватываемый» Проводником. То же самое относится и ко всем остальным типам
носителей. Это существенно затрудняет обмен данными между виртуальной и основной
машинами. Самое надежное — копировать данные через CD-ROM (не обязательно
физический — подойдет и виртуальный, просто берем любую программу для создания
iso-образов и монтируем ее на основную систему и на VMware).
Важно: по умолчанию VMware автоматически распознает все подключаемые
USB-устройства и дает виртуальным машинам к ним полный доступ. Допустим, мы
подключаем FLASH, внешний жесткий диск с USB-интерфейсом или другой девайс
подобного рода, на котором тут же поселяется вирус, вырвавшийся из застенков
виртуальной машины. Чтобы предотвратить вторжение, достаточно отключить
USB-контроллер в свойствах виртуальной машины.
Однако проблемы на этом не заканчиваются. Руткиты уже давно научились
распознавать виртуальные машины, отказываясь от заражения в их присутствии,
что ломает весь концепт. Мы устанавливаем программное обеспечение с руткитом на
виртуальную машину, сравниваем образы, ничего не находим и, довольные собой,
запускаем руткита в основную систему. Выходит, гарантировано обнаружить
современных руткитов при помощи виртуальных машин невозможно! А если еще учесть
большое количество дыр в эмуляторах, то руткит имеет все шансы заразить основную
систему из гостевой машины. Выход? Либо использовать выделенную живую машину,
либо надежную виртуальную машину с полной эмуляцией (например, Bochs). Это
предотвратит вирусное вторжение, но, увы, не спасет от детекции виртуальной
машины руткитом. Bochs содержит множество мелких дефектов эмуляции (ведет себя
не как настоящий процессор), которые не препятствуют работе нормальных программ,
но могут быть использованы для детекта эмулятора. К тому же, ЛЮБОЙ эмулятор
несет на своем борту довольно специфический набор виртуального железа, по
которому его легко опознать. И хотя при наличии исходных текстов мы можем
воспрепятствовать этому — купить живой компьютер намного дешевле, чем корежить
виртуальное железо.
Резюмируя вышесказанное, делаем вывод: виртуальные машины – не слишком-то
надежный загон для вирусов, хотя если не быть параноиком, то (с учетом низкого
качества подавляющего большинства вирусов и руткитов) лучше использовать
виртуальную машину, чем всецело полагаться на антивирусы.
Инструмент выявления сетевых атак
Офисные сети обычно не испытывают необходимости в сенсорах и датчиках,
детектирующих вторжение, а если и испытывают, то дело обычно ограничивается
приобретением коммерческой IDS/IPS-системы, встраиваемой в брандмауэр и спокойно
работающей на шлюзе в интернете или на одном из узлов локальной сети.
С ростом сети появляется желание установить специализированную систему
обнаружения вторжений, например, Snort (бесплатный) или AMP (коммерческий). И
разместить ее на выделенном узле, поскольку для установки того же AMP
администратор должен предоставить его поставщикам удаленный shell на свою
машину. Причем, AMP будет не только автоматом скачивать свежие сигнатуры из
Сети, но и отправлять весь подозрительный трафик для анализа на серверы компании
Endeavor, которая и является его разработчиком.
Доверие — это прекрасно, но отдавать свой трафик в чужие руки… Нет, лучше
размесить эту штуку на отдельном узле, отключенном от основной локальной сети,
но запитанном от того же самого ISP – то есть ловящего тех же вирусов и червей,
что и основные узлы локальной сети. Можно ли использовать для этой цели
виртуальную машину? Конечно! Главное, надежно изолировать ее от корпоративной
сети.
Наибольшую проблему представляют виртуальные сетевые карты, через
которые гостевая операционная система легко доберется до основной. Все
виртуальные карты в обязательном порядке должны быть отключены! Но… если у нас
нет сети, как же тогда общаться с внешним миром и ловить трафик? Вариантов
много. Вот только один из них: ADSL-модем с USB-интерфейсом, подключенный к
виртуальной машине с выдернутой сетевой картой и заблокированными шарами.
Какую именно виртуальную машину следует использовать? VMware очень известна и
слишком дырява. Bochs невероятно медленно работает. Virtual PC – неплохой выбор,
но учитывая большое количество дыр в процессорах, его использование крайне
небезопасно. Реально остается только VirtualBox, XEN или QEMU, хотя первый из
них все еще достаточно сырой и до сих пор не отлаженный.
Зеркальный сервер
Вредоносная природа червей и вирусов вполне объяснима. Они как раз для этого
и писались. Увы, честное программное обеспечение зачастую наносит намного
больший урон. Взять хотя бы обновления безопасности или новые версии. Всем
администраторам хорошо известно, что их установка порой приводит к
трудноразрешимым конфликтам, потерям данных, а то и полному краху операционной
системы!
Аналогичным образом дела обстоят с кручением настроек, смысла которых
администратор до конца не понимает и действует методом тыка. Одно неверное
движение руки — и система отказывается загружаться, а чтобы поднять ее,
требуются знания и квалификация, вырабатываемые только в борьбе с вот такими
взлетами и падениями. По книжкам всего не выучишь… И здесь виртуальные машины –
незаменимы.
Просто устанавливаем систему со всеми приложениями и сервисными службами на
VMware/Virtual PC/VirtualBox/etc, и все новые заплатки, обновления, настройки, в
первую очередь, обкатываем на гостевой операционной системе, наблюдая за ее
реакцией. Если полет нормальный — переносим изменения на основную машину. Если
же нет — соображаем, что здесь не так, и где косяк.
Итого
Виртуальные машины открывают практически неограниченные возможности для
экспериментов. Главное — правильно ими воспользоваться, предусмотрев максимум
возможных побочных эффектов и разработав план по их устранению.
Полную версию статьи
читай в октябрьском номере
Хакера!