kolchakA: У меня есть приложение, которое использует базу данных mysql (именно mysql, а не maria db или прочие форки). Хочу, чтобы база находилась в интернете. Соответственно мне нужен к ней удаленный доступ. Замечу, мне нужна ТОЛЬКО БАЗА, никаких сайтов я ставить не собираюсь. Подскажите решение вопроса до 7$ в месяц. Понимаю, что можно купить VPS, но зачем он мне, если мне нужна только база?
p.s. насколько знаю у shared хостов в основном запрещен удаленный доступ к базе.
Если нужна только база, то давайте говорить только о базе:
1. Сколько места занимает ваша база?
2. Какие данные хранятся в базе?
3. Сколько запросов в минуту или в час или в день попадает в вашу базу?
4. MyISAM или InnoDB
А то решение до 7$ может в принципе предоставить каждый, однако ваша база может иметь сколько подключений и создавать такие проблемы на сервере что и за 70$ никому не будет нужна....
Если укажете все о чем я пишу выше - будет о чем поговорить, а пока что все предложения - пальцем в небо.
Minorov: Цены жесть.
Особенно порадовал "анлим":
"Все арендуемые серверы подключаются к порту 100 Мбит/с. Входящий/исходящий трафик и соотношение входяещего к исходящему не учитываются. Но мы, все же, расчитываем, что Ваш средний трафик не будет сильно превышать 2-3 Тб в месяц."
То есть надеются, что из 30-33 ТБ клиент не будет тратить более 10% :)
Обычный оверселлинг, только не завуалированный.
---------- Добавлено 07.07.2014 в 16:23 ----------
Minorov: Зачем тогда писать про неограниченный трафик, а ниже намекать, что мы хотим чтобы клиенты тратили не более 10%?
Это еще и считается лучшим вариантом, обычно это указано в оферте в подпункте 100500 мелким шрифтом. Так что у вас есть право - выбирать. Куда интересней осознать что вы предполагали безлимит а через 3 ТРБ закончился трафик ?:D
Alexandr Smolin: То, что это "компания" из одного человека, вроде нигде и никогда не скрывалось (могу и ошибаться, это личное впечатление). Но у подобных мелких хостеров размещаться гораздо приятнее, чем в крупных компаниях со штатом наемных случайных людей с ротацией, т.к. мотивация следить за собственным детищем у них ощутимо выше.
Я за 10 лет многих крупных и не очень отечественных хостеров перепробовал (некоторое количество позакрывалось/продалось, когда директор одного из них эмигрировал, продав компанию, через несколько месяцев качество услуг накрылось медным тазом), в итоге имею аккаунт у onyx.net.ua (притом не очень понимаю, как столько лет удается при столь низких ценах еще и уведомление о просрочке оплаты в аську кидать успевать, мелочь, а ощущение домашней душевности дает; тяжелые проекты (за которые пинали другие хостеры) не вызывают регулярные уведомления о нагрузках, что тоже слегка удивляет) и нескольких других с серверами зарубежом и деятельностью по принципу "человек-компания".
Спасибо за приятный отзыв в нашу сторону, из компании с одним человеком мы давно выросли, я конечно не буду "загибать пальцы" и говорить что нас тут как в гугле ))) но 4 человека которые работают над проектом onyx.net.ua в полной мере обеспечивают выполнение взятых на себя обязательств перед нашими заказчиками, при этом вполне хватает времени на то, что бы уведомлять клиентов и по ICQ в том числе. Пожалуй ответы на удивляющие вас вопросы могут содержаться в принципе нашей работы - мы всегда ведем борьбу за качество, чего бы это не стоило, а цены и красота - уже потом, если можно не повышать цены - не повышаем :)
Natikana, очень похоже на взлом вашего сайта, возможно стоит обратиться к специалистам по этому вопросу, если вы никого не назначали в администраторы, а они там появились - это явно плохо.
Вся соль аналогичных вопросов заключается в том, что далеко не всегда есть возможность выяснить где находится дыра, сейчас попытаюсь пояснить почему:
Выяснить конечно можно но представьте себе путь которым придется это сделать, ведь что получается по сути, вы видите только конечный результат, вам залили какие-то страницы, и вот они лежат, стало быть уязвимость может находится например в одной из функций одного из ваших сайтов, а так же может находится в демоне apache или mysql а еще например может находится в ядре (kernel) вашей системы, каким методом или алгоритмом вы собираетесь проверить все эти точки? Ведь проблемы бывают на столько разные.... К примеру помню баг в драйвере реалтек сетевых карт, при отправке определенного запроса сервер просто отключал сетевую карту.... а может сейчас уже новый баг в одном из драйверов который дает доступ к системе? В общем подход нужен обратно пропорциональный, искать дыры после того как взлом случился.... задача очень сложная и практически не реальная, куда проще искать взломы в момент самих взломов, а именно подготовится к проникновению в вашу систему заранее, что это значит:
1. Ни в коем случае не экономить место под логи, причем любые логи, это могут быть логи веб сервера (причем как access так и error) это могут быть логи mysql query (да их может быть много, однако они отражают все SQL запросы в базу и легко могут быть подвержены ротации). Так же могут быть включены логи PHP.
2. Отдельно стоит поговорить об окружениях в которых работают ваши сайты, если у вас есть возможность!! каждый сайт должен быть изолирован от других, основная проблема виртуальных хостингов заключается в том, что злоумышленники взломав всего 1 сайт получают доступ ко ВСЕМ остальным сайтам на акаунте... базам, настройкам и.т.п По этому если вы владелец VPS или Выделенного Сервера не исключайте изоляцию из настроек, выдавайте каждому сайту свое окружение, создавайте своего пользователя как системного так и для доступа к базам данных.
3. По моему личному наблюдению + небольшому 10 летнему опыту работы в хостинг индустрии, 90% всех взломов происходит с использованием известных уязвимостей в известных движках, ведь согласитесь если вы создали движок сами , поставили его себе на сайт и пользуетесь им исключительно ВЫ, каким бы крутым атакующим не был наш злоумышленник у него нет ни малейшего представления какие функции вы используете, как они построены и какие из них содержат погрешности программирования, это значительно усложняет методики поиска уязвимостей, другое дело когда можно скачать свежую Joomla или WP с оф. сайта и командным орбазом придать жесткому анализу все её функции... найдя уязвимость - под атакуемые машины сразу попадают тысячи, сотни тысяч пользователей сети..... и утекают гигабайты персональных данных и.т.п По этому если у вас есть материальная возможность разработки своего движка для своих сайтов - это огромный бонус!!!
4. Аналитика или с чего начинать: Если вы хотя бы раз смотрели в лог веб сервера , вас должен заинтересовать вопрос, чем же нам помогает этот самый лог, ведь там кроме обращения к конкретному файлу и наверняка подмененному ИП атакующего ничего нет, и от части вы совершенно правы, одним из важных на мой взгляд принципов изучения атак, заключается полное хранение развернутых POST запросов к вашему ресурсу, сделать такой механизм очень не сложно, я покажу самый простой пример, но можно наколдовать и куда поинтересней:
После чего в php.ini для вашего окружения можно прописать следующее:
auto_prepend_file="/path/to/our/file/trace.php"
Данная конструкция будет записывать в указанный лог файл ВСЕ данные всех POST запросов которые прийдут на ваш виртуальный хост, как правило этот файл дает около 90% результативной информации при выявлении уязвимости, к примеру если через кривой редактор в вашем движке был залит файл то скорее всего в POST логе вы обнаружите содержимое того самого файла, а так же сможете понять куда было произведено обращение и какие параметры передавались в этот момент в POST запросе. Следом эти данные может будет сравнить с данными из sql query log , если были модификации в базе данных - то аналогично будет ясно какие запросы были инициаторами этих самых изменений...
На самом деле это только начало, но без него и говорить не о чем, когда у вас нет логов, когда у вас нет информации по запросам к вашей системе, по переданным в неё данным - искать уязвимость это тыканье пальцем в небо.... Увы, и ах, но это именно так. Обычно в таких случаях "умники" сразу смотрят версии продуктов и если они не актуальны то все лечение заключается в установке последней версии вашего движка, однако по прежнему нет никакой ясности в том, являлось ли это причиной проблемы....
С радостью проконсультирую или отвечу на доп. вопросы лично.
Уважаемые клиенты, в связи с техническими проблемами сегодня около 23:00 по Киеву вышел из строя сервер Core16 на котором так же расположен и наш основной сайт. Наши специалисты уже направили все силы на решение данной проблемы, в настоящий момент идет восстановление данных с raid массива, а так же восстановление самого массива, ситуация нашими специалистами не оценена как критическая и пока что нет угрозы потери данных, однако ситуация требует не малого времени и терпения.
Полная реконструкция массива с данными займет по предварительным расчетам от 5 до 10 часов. Остальные сегменты проекта данная проблема не затрагивает. Мы будем держать вас в курсе по основным аспектам данной проблемы. Состоянием на момент поста реконструкция идет без ошибок и пройдена на 3.5%.
Приносим свои извинения за причиненные неудобства.
Проблема еще ночью устранена, сервер введен в эксплуатацию в полном объеме.
У меня есть приложение, которое использует базу данных mysql (именно mysql, а не maria db или прочие форки). Хочу, чтобы база находилась в интернете. Соответственно мне нужен к ней удаленный доступ. Замечу, мне нужна ТОЛЬКО БАЗА, никаких сайтов я ставить не собираюсь. Подскажите решение вопроса до 7$ в месяц. Понимаю, что можно купить VPS, но зачем он мне, если мне нужна только база?
p.s. насколько знаю у shared хостов в основном запрещен удаленный доступ к базе.
Если нужна только база, то давайте говорить только о базе:
1. Сколько места занимает ваша база?
2. Какие данные хранятся в базе?
3. Сколько запросов в минуту или в час или в день попадает в вашу базу?
4. MyISAM или InnoDB
А то решение до 7$ может в принципе предоставить каждый, однако ваша база может иметь сколько подключений и создавать такие проблемы на сервере что и за 70$ никому не будет нужна....
Если укажете все о чем я пишу выше - будет о чем поговорить, а пока что все предложения - пальцем в небо.
Цены жесть.
Особенно порадовал "анлим":
"Все арендуемые серверы подключаются к порту 100 Мбит/с. Входящий/исходящий трафик и соотношение входяещего к исходящему не учитываются. Но мы, все же, расчитываем, что Ваш средний трафик не будет сильно превышать 2-3 Тб в месяц."
То есть надеются, что из 30-33 ТБ клиент не будет тратить более 10% :)
Обычный оверселлинг, только не завуалированный.
---------- Добавлено 07.07.2014 в 16:23 ----------
Зачем тогда писать про неограниченный трафик, а ниже намекать, что мы хотим чтобы клиенты тратили не более 10%?
Это еще и считается лучшим вариантом, обычно это указано в оферте в подпункте 100500 мелким шрифтом. Так что у вас есть право - выбирать. Куда интересней осознать что вы предполагали безлимит а через 3 ТРБ закончился трафик ?:D
То, что это "компания" из одного человека, вроде нигде и никогда не скрывалось (могу и ошибаться, это личное впечатление). Но у подобных мелких хостеров размещаться гораздо приятнее, чем в крупных компаниях со штатом наемных случайных людей с ротацией, т.к. мотивация следить за собственным детищем у них ощутимо выше.
Я за 10 лет многих крупных и не очень отечественных хостеров перепробовал (некоторое количество позакрывалось/продалось, когда директор одного из них эмигрировал, продав компанию, через несколько месяцев качество услуг накрылось медным тазом), в итоге имею аккаунт у onyx.net.ua (притом не очень понимаю, как столько лет удается при столь низких ценах еще и уведомление о просрочке оплаты в аську кидать успевать, мелочь, а ощущение домашней душевности дает; тяжелые проекты (за которые пинали другие хостеры) не вызывают регулярные уведомления о нагрузках, что тоже слегка удивляет) и нескольких других с серверами зарубежом и деятельностью по принципу "человек-компания".
Спасибо за приятный отзыв в нашу сторону, из компании с одним человеком мы давно выросли, я конечно не буду "загибать пальцы" и говорить что нас тут как в гугле ))) но 4 человека которые работают над проектом onyx.net.ua в полной мере обеспечивают выполнение взятых на себя обязательств перед нашими заказчиками, при этом вполне хватает времени на то, что бы уведомлять клиентов и по ICQ в том числе. Пожалуй ответы на удивляющие вас вопросы могут содержаться в принципе нашей работы - мы всегда ведем борьбу за качество, чего бы это не стоило, а цены и красота - уже потом, если можно не повышать цены - не повышаем :)
Ищем надежный абузоустойчивый хостинг.
На сайт только ссылки.
Бюджет 40-50уе
Тест 2-3 дня перед покупкой обязательно.
В случае удаления контента в течении 24х часов сможем разместить вас в Канадe.
Janik, а что за тип контента на вашем будущем абузоустойчивом сайте?
Natikana, очень похоже на взлом вашего сайта, возможно стоит обратиться к специалистам по этому вопросу, если вы никого не назначали в администраторы, а они там появились - это явно плохо.
удалил весь public_html с сервера и закачал public_html уже с компьютера без вирусов.
А с чего вы взяли что залитое обратно без вирусов?
Надо смотреть что у вас там за код вставлен и что там качается.. Дайте свой сайт (можно в приват) постараемся помочь недорого.
ТС,
Можете ознакомиться со статьей "Методики борьбы с простейшими атаками" а так же будет полезна статья "Многофункциональность и гибкость fail2ban"
Вся соль аналогичных вопросов заключается в том, что далеко не всегда есть возможность выяснить где находится дыра, сейчас попытаюсь пояснить почему:
Выяснить конечно можно но представьте себе путь которым придется это сделать, ведь что получается по сути, вы видите только конечный результат, вам залили какие-то страницы, и вот они лежат, стало быть уязвимость может находится например в одной из функций одного из ваших сайтов, а так же может находится в демоне apache или mysql а еще например может находится в ядре (kernel) вашей системы, каким методом или алгоритмом вы собираетесь проверить все эти точки? Ведь проблемы бывают на столько разные.... К примеру помню баг в драйвере реалтек сетевых карт, при отправке определенного запроса сервер просто отключал сетевую карту.... а может сейчас уже новый баг в одном из драйверов который дает доступ к системе? В общем подход нужен обратно пропорциональный, искать дыры после того как взлом случился.... задача очень сложная и практически не реальная, куда проще искать взломы в момент самих взломов, а именно подготовится к проникновению в вашу систему заранее, что это значит:
1. Ни в коем случае не экономить место под логи, причем любые логи, это могут быть логи веб сервера (причем как access так и error) это могут быть логи mysql query (да их может быть много, однако они отражают все SQL запросы в базу и легко могут быть подвержены ротации). Так же могут быть включены логи PHP.
2. Отдельно стоит поговорить об окружениях в которых работают ваши сайты, если у вас есть возможность!! каждый сайт должен быть изолирован от других, основная проблема виртуальных хостингов заключается в том, что злоумышленники взломав всего 1 сайт получают доступ ко ВСЕМ остальным сайтам на акаунте... базам, настройкам и.т.п По этому если вы владелец VPS или Выделенного Сервера не исключайте изоляцию из настроек, выдавайте каждому сайту свое окружение, создавайте своего пользователя как системного так и для доступа к базам данных.
3. По моему личному наблюдению + небольшому 10 летнему опыту работы в хостинг индустрии, 90% всех взломов происходит с использованием известных уязвимостей в известных движках, ведь согласитесь если вы создали движок сами , поставили его себе на сайт и пользуетесь им исключительно ВЫ, каким бы крутым атакующим не был наш злоумышленник у него нет ни малейшего представления какие функции вы используете, как они построены и какие из них содержат погрешности программирования, это значительно усложняет методики поиска уязвимостей, другое дело когда можно скачать свежую Joomla или WP с оф. сайта и командным орбазом придать жесткому анализу все её функции... найдя уязвимость - под атакуемые машины сразу попадают тысячи, сотни тысяч пользователей сети..... и утекают гигабайты персональных данных и.т.п По этому если у вас есть материальная возможность разработки своего движка для своих сайтов - это огромный бонус!!!
4. Аналитика или с чего начинать: Если вы хотя бы раз смотрели в лог веб сервера , вас должен заинтересовать вопрос, чем же нам помогает этот самый лог, ведь там кроме обращения к конкретному файлу и наверняка подмененному ИП атакующего ничего нет, и от части вы совершенно правы, одним из важных на мой взгляд принципов изучения атак, заключается полное хранение развернутых POST запросов к вашему ресурсу, сделать такой механизм очень не сложно, я покажу самый простой пример, но можно наколдовать и куда поинтересней:
file trace.php:
После чего в php.ini для вашего окружения можно прописать следующее:
auto_prepend_file="/path/to/our/file/trace.php"
Данная конструкция будет записывать в указанный лог файл ВСЕ данные всех POST запросов которые прийдут на ваш виртуальный хост, как правило этот файл дает около 90% результативной информации при выявлении уязвимости, к примеру если через кривой редактор в вашем движке был залит файл то скорее всего в POST логе вы обнаружите содержимое того самого файла, а так же сможете понять куда было произведено обращение и какие параметры передавались в этот момент в POST запросе. Следом эти данные может будет сравнить с данными из sql query log , если были модификации в базе данных - то аналогично будет ясно какие запросы были инициаторами этих самых изменений...
На самом деле это только начало, но без него и говорить не о чем, когда у вас нет логов, когда у вас нет информации по запросам к вашей системе, по переданным в неё данным - искать уязвимость это тыканье пальцем в небо.... Увы, и ах, но это именно так. Обычно в таких случаях "умники" сразу смотрят версии продуктов и если они не актуальны то все лечение заключается в установке последней версии вашего движка, однако по прежнему нет никакой ясности в том, являлось ли это причиной проблемы....
С радостью проконсультирую или отвечу на доп. вопросы лично.
[ Срочное сообщение ]
Уважаемые клиенты, в связи с техническими проблемами сегодня около 23:00 по Киеву вышел из строя сервер Core16 на котором так же расположен и наш основной сайт. Наши специалисты уже направили все силы на решение данной проблемы, в настоящий момент идет восстановление данных с raid массива, а так же восстановление самого массива, ситуация нашими специалистами не оценена как критическая и пока что нет угрозы потери данных, однако ситуация требует не малого времени и терпения.
Полная реконструкция массива с данными займет по предварительным расчетам от 5 до 10 часов. Остальные сегменты проекта данная проблема не затрагивает. Мы будем держать вас в курсе по основным аспектам данной проблемы. Состоянием на момент поста реконструкция идет без ошибок и пройдена на 3.5%.
Приносим свои извинения за причиненные неудобства.
Проблема еще ночью устранена, сервер введен в эксплуатацию в полном объеме.
Приносим свои извинения за неудобства.
🙅🙅🙅