Смена IP адресов



В связи с недобросовестным исполнением обязательств наших поставщиков, прекращают свою работу подсети IP адресов:
  • 179.60.146.0/24
  • 179.60.147.0/24
  • 179.60.148.0/24
  • 179.60.149.0/24

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

Предлагаем 2 варианта решения проблемы:
  1. Вы создаете тикет или другим способом обращаетесь в нашу службу поддержки. Мы сообщаем вам новый адрес. Вы самостоятельно его меняете.
  2. Вы создаете тикет и указываете логин и пароль от своего сервера, чтобы мы могли заменить ваши адреса на новые.

Мы приносим искренние извинения за предоставленные неудобства.

Хостинг IPv6

IPv6 быстрее, чем IPv4. При подключении через IPv6 скорость загрузки LinkedIn в Европе увеличилась на 40%, а Facebook — примерно на 10-15%. Примерно 15% пользователей пользуются Google через IPv6, в свою очередь лишь у 10% сайтов включен IPv6. График перехода на IPv6 по всему миру, подготовленным Google. По данным Cloudflare сайты, которые работают через IPv6, загружаются на 27% быстрее, чем те, которые используют IPv4.



Хостинг с поддержкой IPv6 доступен для всех наших пользователей на всех тарифах.

hostink.ru

Выделенный сервер 2xX5675 с защитой от DDoS атак за 7000р в месяц

Представляем Вам новый тарифный план:
  • DS-06 (2xXeon X5675/64Gb/2x1Tb SATA) + защита от DDoS атак всего за 7000р в месяц. Сервера уже в стойке и ждут своих владельцев.
При оформлении заказа можно заказать другие диски.
artplanet.ru/rent

Все сервера с данным тарифным планом установлены в новом ДатаЦентре SDN/Xelent

Посмотреть информацию о датацентре

переезд в новый ДатаЦентр Xelent/SDN

Доброго времени суток, уважаемый клиент!

Обращаем Ваше внимание:
  • В связи с апгрейдом и модернизацией ДЦ было принято решение о смене места расположения нашего ДЦ.
  • Новым местом размещения был выбран крупнейший ДЦ в Северо-Западном регионе уровня Tier III — ДЦ Xelent/SDN.
Почем мы выбрали именно Xelent/SDN
-Автономность:
Дата-центр подключен к сетям Ленэнерго мощностью 14 МВт и использует динамические источники бесперебойного питания Hitec Power Protection BV.
Каждая серверная стойка обладает дублированным распределением питания — схема резервирования N+1, установки ДИБП организованы группами 3+1 с динамическим распределением мощности между 3 установками.
Благодаря данной схеме Xelent/SDN за 3 года своего существования ни разу падал по питанию.

— Охлаждение:
Система охлаждения дата-центра разработана с учетом климатических особенностей Северо-Западного региона.
Технология FreeCooling: за счет кратковременного использования тепловых насосов происходит экономия электроэнергии, что позволяет отдавать большую мощность серверам, размещенным в дата-центре.
Данная технология построена на промышленном оборудовании KyotoCooling.
Благодаря этой технологии энергоэффективность функционирования ЦОД, PUE=1,2

— Безопасность:
Безопасность ДЦ Xelent/SDN подтверждена сертификатом PCI DSS, лицензиями ФСБ и Федеральной службой по техническому и экспортному контролю, а инфраструктура ЦОД соответствует международным стандартам Tier III.
Для каждого клиента создаются отдельные зоны с индивидуальным режимом безопасности.
Двери всех помещений оборудованы электронными замками и считывателями карт, а двери помещений и стоек – металлоконтактными извещателями.
Помимо этого у Xelent/SDN 5 периметров безопасности, более 200 видеокамер постоянного наблюдения.

— Специализированность:
Здание Xelent/SDN, в отличие от многих других дата-центров, адаптировавших неспециализированные строения, построено «с нуля» специально для размещения серверов с учетом всех требований, предъявляемых к ЦОД.
За счет оборудования последнего поколения, позволяющего использовать все климатические преимущества — низкая цена за электричество, предсказуемое ценообразование, целый ряд решений, которые сконфигурированы для бизнесов различного масштаба.
Циркуляцию внутреннего и наружного воздуха обеспечивают по два вентилятора промышленного класса. Тепловые насосы также выполнены в виде двух параллельных контуров, так что при выходе из строя одного из них сохраняется половина охлаждающей способности.

Все нижеперечисленные вопросы-ответы относятся только к выделенным серверам. Перенос виртуальных серверов будет прозрачен и незаметен клиентам.

— Как и когда планируется переезд серверов в новый ЦОД ?
Перемещение серверов клиентов мы начнем с 1 сентября.
Каждому клиенту за 2 недели до начала работ с его сервером\серверами будет написано письмо уведомлеение, где будет указана дата и время перемещения сервера в новый ЦОД.
Если Вам будет не удобна дата или время указанные в письме — просьба связаться с нами до момента перевоза Вашего сервера — чтобы мы скорректировали дату перевоза серверов в новый ЦОД.

— Как будет происходить переезд серверов ?
Заранее в новом ЦОД для серверов готовится витая пара, провода питания и подготавливается место для установки
В назначенное время сервер клиента будет отключаться (максимум будет перевозиться 2-4 сервера за раз)
После чего сервер демонтируется из текущего ЦОД, грузиться в легковой АВТО и аккуратно перевозиться в новый ЦОД
в новом ЦОД сервер устанавливается в заранее подготовленное место и включается.

— Что будет с моими IP адресами?
Ваши IP адреса остануться без изменений и будут работать в новом ЦОД

— Будет ли изменена стоимость услуг?
Нет — стоимость услуг остается без изменения.

— Как долго будет идти процесс перевоза сервера?
Ваш сервер будет недоступен около 4-5 часов.

— Возможна ли перевозка сервера в ночное время?
Да, просьба сообщить об этом после того как к Вам придет уведомление о перевозе Вашего сервера.

— Можно ли ускорить процесс перевоза моего сервера?
Нет — мы подготавливаем стойки последовательно к разным типам серверов. Выбор времени будет возможен только после того как Вы получите письмо с уведомлением о перевозе Вашего сервера.

— У нас очень важный проект и простой на 5 минут очень критичен, как нам быть?
В этом случае после получения письма с уведомлением сообщите нам об этом, мы выделим Вам отдельный новый сервер на который Вы сможете перенести Ваш проект на время перевоза Вашего основного сервера.

Надеемся на Ваше понимание и приносим свои извинения за доставленные неудобства.

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

Разделение проекта на два направления (лежит с пятницы 19/08)



Уважаемые пользователи, наш проект разделился на две части:
виртуальный хостинг
панель управления: my.hostink.ru
e-mail: support@hostink.ru

виртуальные сервера
панель управления: account.nt-vps.ru/
e-mail: support@nt-vps.ru

Наши специалисты выполняют перенос данных в новые панели управления. До окончания работ ресурсы клиентов будут работать без финансовых блокировок, даже при минусе на балансе.

Мы планируем завершить все работы до 25 августа 2017 года.

Приносим свои извинения за доставленные неудобства.

OVH Deals: Cloud VPS, domains и многое другое



OVH, как обычно готовит распродажу. По этому объявляем старт предзаказов любых услуг с страницы www.ovh.ie/ovh-deals

Можете заказать Cloud VPS (1 vCore 2.4 GHz, 6 GB RAM, 25 GB — 5 евро), .com за 100 рублей (по курсу, продление 840 рублей), SP-32-S dedicated server по низким ценам.

Старт продаж в Пятницу. Заказать можете тут через тикет — billing.dedic.org/billmgr

Автоматическая SSH-аутентификация по ключу



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

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

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

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

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

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

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

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

Генерация ключей на клиентской машине под управлением ОС Windows
Для создания файла ключа нам понадобится программа PuTTYgen. Скачать её можно на официальном сайте в составе пакета PuTTY. С её помощью мы сгенерируем ключ, который будет использоваться для авторизации и аутентификации пользователя на сервере. Если вам необходимо только сгенерировать ключ, утилиту PuTTYgen можно скачать отдельно. При запуске утилиты вы увидите окно с входными параметрами:


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


После того, как ключ будет сгенерирован, программа отобразит окно с публичным ключом и отпечатком приватного.



В поле Public key прописана публичная часть ключа, которая будет храниться на сервере. В поле Key comment можно добавить пояснение к ключу. Если у клиента имеются несколько ключей для авторизации на разных сервисах, там можно прописать название сервера, для которого используется ключ. Отпечаток ключа (fingerprint) необходим для повышения безопасности соединения и точной идентификации хоста. При первом подключении пользователь получит сообщение о том, что данный ключ ранее не использовался для аутентификации пользователя. Если же сообщение выдается повторно, это значит, что на сервере сменились публичные ключи, либо кто-то выдает себя за хост.

В поле Key passphrase можно задать пароль к ключу. В таком случае, при аутентификации пользователя по ключу, сервер будет дополнительно запрашивать пароль. Для сохранения сгенерированного ключа нажмите кнопку Save private key. Если пароль в поле Key passphrase не был задан, прежде, чем сохранить ключ, программа выдаст соотвествующее уведомление.

Ключ будет сохранен в файле с расширением .ppk (PuTTY private key). Данный файл необходимо сохранить в безопасном месте, защищенном от доступа третьих лиц.

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

Откройте настройки программы и выберите пункт Session. В поле Host name необходимо прописать адрес сервера, к которому мы будем подключаться. При необходимости также нужно указать порт подключения. После указания всех параметров нажимаем Open.


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

Будьте внимательны при наборе пароля: символы не отображаются во время ввода!
Ключи на сервере хранятся в папке ~/.ssh и прописаны в файле authorized_keys. Для того, чтоб добавить туда наш публичный ключ, необходимо отредактировать файл, например, в консольном текстовом редакторе nano. Открыть файл можно командой:
nano ~/.ssh/authorized_keys


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


Во время генерации ключа в PuTTYgen публичная часть отображалась в поле Public key. Если вы не сохранили ключ, откройте файл приватного ключа в PuTTYgen — программа выделит публичный ключ из приватного. Скопируйте его и вставьте в строку терминала в программе nano. Сделать это можно щелчком правой кнопки мыши.

Нажатием Ctrl+X мы выйдем из редактора. Программа ещё раз спросит, сохранять ли изменения в файле. Нажимаем Y и выходим из редактора.

Теперь наш публичный ключ сохранен в файле ключей сервера. Для того, чтобы мы могли использовать наш приватный ключ для подключения, на клиентской машине потребуется утилита Pageant, входящая в состав пакета PuTTY. После запуска значок утилиты появится в трее. Необходимо либо дважды щёлкнуть по нему и открыть окно агента, либо открыть контекстное меню. Выберите пункт Add key и укажите путь к приватному ключу.



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