После того, как из дата-центра пришло сообщение о том, что ваш сервер готов и онлайн, необходимо внести настройки безопасности на сервер.

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

Для работ на сервере вам понадобится программа Putty. Затем после установки редактора командной Pico переходим к работе с командной строкой, которая не имеет графического интерфейса.

1. Необходимо оставить подключение только по протоколу SSH2, как самое безопасное, и отключить прямой логин для root. Для этого вводим в командную строку:
pico -w /etc/ssh/sshd_config

Далее ищем в открывшемся файле строку
#Port 22
И убираем из нее знак #

Ищем строку: #Protocol 2, 1
И изменяем ее на: Protocol 2

Так вы сможете запретить подключение к серверу по протоколу SSH1, ведь такое соединение недостаточно защищено.

В WHM создаем аккаунт админа с нестандартным логином и паролем, как можно боле сложным. Для админа разрешите соединение SSH, после чего зайдите в WHM:

Server Setup, затем в:
Manage Wheel Group Users

Назначьте админа как члена Wheel Group.

Для этого введите

pico -w /etc/ssh/sshd_config

строку: #PermitRootLogin yes
Измените на: PermitRootLogin no

С помощью команды: /etc/rc.d/init.d/sshd restart перезагрузите демон SSH

Такие манипуляции приведут к тому, что злоумышленнику, который захочет взломать ваш сервер, придется взламывать подряд двойной пароль. Это позволит значительно уменьшить риск проникновений на сервер.

Для соединения с сервером вы будете использовать логин и пароль, назначенный вами для админа, после чего вводить «su -» root пароль.

Для отключения от сервера достаточно будет ввести «exit» и нажать ENTER.

2. Настраиваем сообщения по электронке в ROOТ логине на вашем сервере

Для этого необходимо отредактировать файл
.bash_profile
в директории пользователей /root

для редактирования файла используем команды:
cd
su -
pico .bash_profile

В конце файла нужно ввести строку:
echo ‘ALERT - Root Shell Access on:’ `date` `who` | mail -s “Alert: Root Access on Server #1″ admin@XXXXXXX.com

Строка admin@XXXXXXX.com будет означать ваш адрес на другом сервере. Такое ухищрение необходимо для того, чтобы вторгнувшийся на ваш сервер не смог уничтожить сообщение о своем вторжении.

Сохраняем изменения в файле при помощи комбинации клавиш
CTRL+X
Y
И ENTER.

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

Многие из нас наслышаны о технологиях WEB 2.0, но каким на самом деле будет хостинг для WEB 2.0, мало кто думал.

Новшества будут заметны невооруженным взглядом в наполнении контентом, который будет более четкий и однозначный. Будет осуществляться реальная поддержка клиентов, аптайм максимально приблизится к 100%, гео-кластеризация, а также суперповышенная защита от DDOS атак.

Суть WEB 2.0 заключается в том, что пользователи сайта являются главными его авторами, формируя контент сайта непосредственно из окна браузера. О такой фишке как FTP забудут, а загрузка информации будет осуществляться из окна браузера. Сайт можно будет полностью изменять в визуальном редакторе. А HTML 5 даст еще больше возможностей в этом плане.

Обычный хостинг предлагает своим клиентам самые обыкновенные технологии, не дающие каких-либо гарантий. Из-за некоторых настроек безопасности хостинга может не работать совсем или работать некорректно СМS вашего сайта.

С этой точки зрения хостинг WEB 2.0 предложит своим клиентам новые сервисы. Под него будут модифицированы самые популярные CMS, движки блогов и форумов. Такие инструменты предложат клиентам уже готовый и предустановленный сервис, настроить который можно сразу же из браузера.

Хостинг WEB 2.0 будет предлагать не список технологий, а список сервисов, хорошо и четко работающих.

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

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

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

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

Разделив классическую файловую систему, вы получите повышенную отказоустойчивость и сократите избыточность дублированной информации на одном сервере. Для классической CMS не требуется модификация ее ядра, а изменяются всего лишь 1-2 дирректории, в том числе и БД.

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

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

Применение обычной MySQL в режиме master-slave повысит надежность хранения БД и уменьшить нагрузки. В такой MySQL все запросы на модификацию будут направляться на master сервер, а на множестве slave-серверов будут выполняться запросы на выборку.

Давайте представим себе классический сервер хостинга WEB 2.0:
• Прежде всего, на нем стоит nginx, который отдает статический контент
• Далее классический apache
• Для исполнения скриптов используют fastcgi php
• MySQL сервер, работающий в режиме slave, который в любой момент может стать master
• Репозиторий сервисов хранится на разделе диска, размеченного под классической ФС. Файловый сервер в любой момент может измениться и синхронизироваться с остальными серверами через rsync
• Между остальными серверами коммуникации WEB 2.0 стоит демон.
• Отказоустойчивая файловая система расположена на оставшейся части диска Одновременное использование большого числа серверов направляют их ресурсы на борьбу с DDOS атаками.
• При атаке одного из серверов демон комуникации сообщает IP сети атаки на остальные сервера, после чего постепенно блокируются все IP ботнеты.

Сейчас распределенной файловой системы с открытым исходным кодом, полностью подходящей для системы хостинга WEB 2.0 пока не существует. Ближе всего к истине находится Hadoop HDFS с Namenode.

В чем особенность и главные отличия выделенного сервера? Прежде всего, в том, что выделенный сервер - это все ресурсы, а также нестандартные возможности. К примеру, для того, чтобы получить высокоскоростной доступ к сайтам, построенным на движках вида phpnuke, необходимо использовать 2 веб-сервера, которые не обязательно могут быть размещены на одном веб-сервере.

Один сервер - backend будет предоставлять обычный апач, с php, mysql и т.п. А другой - frontend, будет являться обычным кешируюшим веб-сервером, способным выдержать нагрузку в очень большое количество посещений одновременно.

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

Такой нюанс, как возможность докупить дополнительные IP из другой подсети, необходим только для NS доменов в зоне RU. А вот возможность увеличить объем памяти, подключить дополнительный жесткий диск и список панелей, имеющихся в наличии, их стоимость и перечень подходящих ОС очень важные критерии выбора дедика.

Dedicated Server, в переводе с английского выделенный сервер, а на жаргоне просто «Дедик». В отличие от виртуального dedicated хостинг представляет собой выделенный сервер, место на котором не делится между несколькими сайтами, обслуживающихся хостером. Выделенный сервер расположен в специальном дата-центре, где для его бесперебойной работы обеспечены необходимые условия. Это и подача энергии, и охлаждение, а также канал и место в стойке.

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

По обслуживанию выделенные серверы делятся на две категории: unmanaged (необслуживаемые) и managed (обслуживаемые). Техподдержка необслуживаемых серверов обычно сводится к перезагрузке сервера и переустановке ОС, если она вышла из строя из-за неграмотного обращения с ней.

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

Техподдержка или support также подразделяется на уровни (levels).

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

Второй уровень техподдержки решает традиционные проблемы. Например, пополнение баз данных для support level 1и установка и настройка штатного ПО. Но в некоторых ситуациях и support level 2 не может справиться с поставленной перед ним проблемой, выполняет эскалацию тикета.

Решение глобальных проблем или траблшутинг – это специализация support level 3. Этот уровень техподдержки способен найти решение таким проблемам как некорректная работа ПО, медленная загрузка сервера, аппаратные проблемы, настройка и корректировка работы ПО.

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

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

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

Есть и другой вариант – дата-центр предлагает оплачивать услуг по числу тикетов. То есть хозяином сервера предоставляется определенное количество тикетов в месяц – от 20 до 100. Это количество тикетов будет обслуживаться бесплатно, но если вы его превысите, за остальные тикеты придется платить отдельно. Могут быть и такие условия, что бесплатные тикеты предоставляются хостером только для первого уровня техподдержки, а все остальные уже платные.

SLA – еще один важный момент. Это уровень сетевой доступности, который означает, что отправленный вами запрос будет прочитан немедленно, даже ночью в воскресенье, и обработан в указанные в договоре сроки. Но стоит помнить о том, что даже обещанный SLA в 99% на деле может сильно до этого уровня не дотягивать.

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

Панель организации веб-хостинга для Windows InsPanel работает как и большинство других панелей сразу после установки, не требуя настроек конфигурации. Как свидетельствуют разработчики данной панели в InsPanel уделено большое внимание безопасности. InsPanel поддерживает почтовые решения на базе MDaemon, XMail, Merak и MailEnable, а также работает с технологиями ASP, PERL, CGI, PHP, MySQL, COLDFUSION MX, DNS, MS SQL.

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

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

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

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

Но для реализации данной технологии есть одно «но»: нужно предварительно разобрать и заново собрать с разными патчами ядро. Эта операция вызывает определенный риск, ведь заново собранное ядро может не позволить загрузиться серверу.

Чтобы решить подобную проблему и избавиться себя от подобных рисков, можно использовать qemu – открытую систему эмуляции как на уровне “железа”, так и на UML, работающую только на Linux.

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

Но при работе с qemu есть серьезные недостатки: прежде всего это слишком большое потребление ресурсов при эмуляции на базе целой системы. Данный минус не позволяет qemu конкурировать с такой технологией как OpenVZ. Вторым серьезным минусов при использовании qemu является то, что данный эмулятор использует GUI и довольно не удобен в работе, особенно, если канал сервера недостаточно мощный.

Чтобы избавиться от перечисленных недостатков, можно запустить qemu в режиме терминала. Для этих целей можно воспользоваться двумя образами: мини-образ Linux Debian в состоянии режима basic setup и уже предустановленную FreeBSD с предусмотрительно поднятым ssh-сервером. Скачать эти образы и скрипты можно по ftp - ftp://dedic.ru/qemu/, а можно создать их своими силами.

Для дистрибутивов Linux нужно скачать ISO-образ дистрибутива, конечно же, лучше, если это будет mini-образ. Все остальные элементы можно ставить по сети. После чего данный образ устанавливаем во временную директорию с помощью опции loop. Забираем отсюда ядро vmlinuz и initrd.img. После чего запускаем qemu с этим ядром и inird, а с помощью дополнительных опций передаем вывод на консоль. После того как qemu запущен, можно работать с виртуальным сервером через консоль. Понятно, что в этом случае использование графического инсталлятора излишне.

Если у вас FreeBSD сервер, все выглядит гораздо проще: нужно только включить в конфигурации comconsole и выполнить ее настройку, а далее перенаправить ввод-вывод в stdin/stdout.

Чтобы получить доступ с виртуального сервера в сеть на физическом сервере нужно активизировать форвардинг:
echo 1 > /proc/sys/net/ipv4/ip_forward
и включить выход с подсетки 127.20.0.2 (это IP-диапазон виртуальных серверов):
iptables -t nat -A POSTROUTING -s 172.20.0.0/24 -d 0/0 -j MASQUERADE
Чтобы получить доступ к виртуальному серверу для одного из реальных IP физического сервера, нужно задать обратный проброс:
iptables -A FORWARD -d 172.20.0.2 -i eth0 -j ACCEPT
iptables -t nat -A PREROUTING -d реальный.ip.тут -p tcp -j DNAT –to-destination 172.20.0.2

По материалам сайта dedic.ru

Давайте представим себе следующую довольно распространенную ситуацию: ваш сайт создан посредством php-скриптов и базы данных MySQL. У каждого вебмастера рано или поздно наступает такой момент, когда сервер, на котором расположен ваш сайт, перестает нормально работать из-за резкого увеличения количества запросов пользователей. Что делать в подобной ситуации? Если вы искусственного ограничите количество запросов, тем самым вы отбросите ваших посетителей. Нарастить мощность сервера – слишком дорого, а на оптимизацию скриптов попросту нет времени. В этой ситуации вам поможет тотальная конвертация всего сайта в статический HTML код, после чего отдача кода при помощи nginx.

Для того, чтобы выполнить указанные меры решения проблемы, необходимо определить дискретность, отвечающую за обновление информации и с помощью команды wget сделать зеркальную копию сайта:
wget -m -q -k http://мой.домен/
Далее зеркальную копию сайта необходимо синхронизировать с директорией, из которой файлы будет обрабатывать nginx (предположим, что это /usr/local/html):
rsync -tgu –delete –force мой.домен /usr/local/html
Синхронизируем те файлы, которые при помощи команды wget не были скопированы в зеркальную копию, например, *.js - java скрипты:
rsync -a –include ‘*/’ –include ‘*.js’ –exclude ‘*’ /путь/к/файлам/сайта/ /usr/local/html/
В принципе вы сделали все, что нужно. Теперь осталось дело за малым: нужно запускать этот код каждый час (или реже), что позволит перенести всю нагрузку на nginx.
Если вам необходим сохраненный доступ к CMS для администрирования сайта, нужно добавить любой поддомен сайта на реальный IP и при необходимости войти в админку обращаться к нему

HyperVM – это детище компании Lxlabs, предназначенное для управления виртуальными серверами (VPS/VDS), оснащенными web-интерфейсами HyperVM. С помощью этой панели управления можно управлять разными виртуальными серверами, созданными на разных платформах посредством различных технологий. Главное преимущество HyperVM заключается в исключительной простоте управления, для которой не требуются глубокие знания технологий виртуализации.

В данный момент HyperVM поддерживает технологии аппаратной виртуализации Xen и программной OpenVZ. В планах разработчиков HyperVM в ближайшее время ввести поддержку Windows и Solaris. Эти изменения позволят управлять данными системами с помощью единой консоли.

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

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

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

Вы должны это четко понимать, работая в сфере IT. В противном случае, Вы будете мучатся и менять каждые 2-3 месяца хостера при возникновении очередной проблемы. Это бессмысленно Проблемы периодически происходят у всех хостеров и во всех датацентрах в нашей стране, увы.

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

Также не попадайтесь на ловушку от хостеров, обещающих 99,99% uptime (процент времени работы сервера в сети). Гарантировать это невозможно по той простой причине, что вышестоящие операторы (канальные провайдеры, датацентры) не дают гарантий хостеру. Поэтому uptime в 99,5 считается хорошим показателем для России.

Подумайте как следует и сделайте правильный выбор. Удачи!

С уважением,
Алексей Левин
ООО “Онлайн Центр”
Размещение и продвижение сайтов