Мне не нравится Ваш сарказм, хотя я отчасти понимаю Вашу логику, но вот опыт говорит об обратном - DDoS скриптов/спам скриптов на Питоне я за свою практику не видел (хотя вру, один раз поймали клиента, но там был самописный DDoS бот на urllib), на руби тоже самое. Интересное - почему? А вот фиг знает, сложилось уж так, что всякую ересь пишут на Перле - будь то координаторы ботнета, будь то-то флудеры, будь-то сканеры портов. Кроме этого, изредка используется С (да и то, почти всегда лишь для эксплуатации уязвимости и взятия рута) и все.
P.S. даркмейлер был лишь примером, кроме него существуют всякие веселы udp.pl и прочие сканеры/флудеры, которых фаерволлом даже при желании отсечь крайне сложно.
Ролик прекрасен! Пять баллов!---------- Добавлено в 11:18 ---------- Предыдущее сообщение было в 11:15 ----------К слову о CGI, после того как отключили его в принципе для всех клиентов шареда, в десятки раз стало меньше рассылок спама/сканов портов и прочего. А когда отключали (выборочно, чтобы никому не поломать лишнего), в среднем среди 10 клиентов из 100 в папке CGI обнаружили darkmailer.cgi, вот так-то. Ну и 1-2 клиента правда использовали CGI.
Добрый день!
Нет, не правильно, к VDS эти образы не имеют отношения, это определенным образом подготовленная файловая иерархия + конфиг файлы.
Добрый вечер!
В образах, к сожалению, есть немного проблем, но очень скоро они будут заменены на обновленные :)
Друзья!
Я вижу, что кто-то против нас, кто-то поддерживает. Я благодарен всем, без этого нельзя сформировать комплексное видение ситуации. Да и спор уже скатился не к тому, что мы были не правы, когда забыли предупредить о том, что бэкап старый, а к тому, что мы не выполнили свои обязанности, вот с этим как раз я хочу поспорить.
Cитуация такова, что для выполнения резервного копирования в панели ISPManager не нужны навыки системного администрирования - она имеет очень понятный и интуитивный веб-интерфейс (а также отличную документацию и даже видео-уроки), для просмотра имеющихся в наличии локальных бэкапов - тоже (там, к слову, как раз отображается, когда был сделан последний бэкап). Для просмотра содержимого FTP, предоставленного нами для бэкапа, также не требуется никаких спец средств - только FTP клиент. Кроме этого, всегда есть возможность запустить бэкап вручную и посмотреть его результаты.
Кроме этого, я вот только сейчас вошел в панель управления Вашим хостингом (ISPManager Lite) и меня встретила яркая желтая надпись "Во время резервного копирования произошли ошибки. Для просмотра отчета нажмите "подробнее"", этой надписи пара месяцев. Да и на заданиях бэкапа светятся синие лампочки (это не сакральное знание, это написано во всплывающей подсказке), что говорит о том, что они вообще отключены.
Таким образом, если бы было желание или поверхностное беспокойство о своей работе, то возможностей проверить наличие резервных копий - было множество, я перечислил лишь 4, в том числе просто вход в панель, которая сообщала о проблемах на странце логина.
Разумеется, мы компенсируем недочет Григория компенсацией в виде года бесплатного обслуживания, а также внесем необходимые коррективы в регламенты работы при восстановлении бэкапов, но не стоит ставить нам в вину, что мы не сделали то, чего не было обещано согласно договору. Тем более, каких-либо иносказаний или неясностей в описании услуги бэкапа лично я не вижу: http://fastvps.ru/mesto-na-backup-servere/ там нет ни слова про то, что обеспечиваем бэкап мы.
Ситуация, безусловно, неприятная, но мы получили от Вас подтверждение всех деструктивных действий перед их выполнением. То, что мы не предупредили, что бэкап старый - наша ошибка, безусловно - в будущем мы это обязательно учтем - но нами было сообщено, что бэкап последний имеющийся (к слову, он же единственный) и мы не имели возможности вдаваться, почему резервирование происходит так редко.
По поводу того, что было с файлами изначально - мы подозреваем удаление определенных файлов СУБД либо явный DROP таблиц, так как сообщений о повреждении таблиц в логах не было, поэтому и был предложен вариант починки не СУБД, а непосредственно восстановление данных, что мы и выполнили.
По поводу нашей отвественности за работу системы резервирования в ISPManager - если кратко, то мы не можем отвечать за работу совершенно сторонней нам системы. Мы предоставили платно Вам доступ на FTP для резервирования, помогли единожды настроить бэкап средствами панели, проверили его работу, когда это выполнялось - он работал. Почему он перестал работать потом - я Вам сказать не могу, какой-то сбой панели, за который, опять же, мы не несем никакой отвественности по той причине, что мы не обеспечиваем и не заявляли постоянное администрирование сервера, мы выполнили лишь отдельную операцию. Если бы Вы попросили нас через неделю проверить как работает бэкап и разобраться, что с ним - мы бы безусловно помогли (впрочем, мы поможем и сейчас, лишь попросите), но самостоятльно обнаружить отказ системы резервирования на машине, к которой у нас в принципе нет доступа - невозможно, сожалею.
Варианты решения я уже предложил - во-первых, починить систему бэкапа, во-вторых, попробовать восстановить содержимое форума из кэша поисковиков, так как на наших мощностях бэкапов не осталось, мы проверили все, что могли.---------- Добавлено в 19:40 ---------- Предыдущее сообщение было в 19:38 ----------
Обазаны-то обязаны, но мы предоставляем лишь место для хранения бэкапов, а все остальное выполняет клиент самостоятельно. На FTP, который был предоставлен нами, бэкап был, но ровно тот же самый, очень старый, доступ к нему мы предоставим в любой момент, тольок смысла в нем нет.---------- Добавлено в 19:44 ---------- Предыдущее сообщение было в 19:40 ----------
Благодарю за поддержку в техническом контексте! Именно так, в среднем на ноде 10-15 миллионов файлов и сотни ГБ мелких данных, мы раньше пытались их резервировать, но полный бэкап, во-первых, выполняется около 3х суток, а, во-вторых, почти полностью перегружает дисковую систему, сводя качество услуги на нет, поэтому комплекс мер по защите данных клиентов сводится к использованию RAID массивов, обеспечивающих целостность данных при физическом отказе дискаов, а также мониторингу состояния файловой системы на серверах.
Данный бэкап был не наш, с уровня ноды, а из панели ISPManager.---------- Добавлено в 19:46 ---------- Предыдущее сообщение было в 19:44 ----------
Таблицы не были повреждены, СУБД работала без сбоев, просто данных в таблице не было и все. Впрочем, вины Григория я не отрицаю, она есть.
У меня нет информации по подобным инцидентам за последние дни, сообщите номер тикета.
У нас нет администрируемых машинок. Просто ребята не заметили, что PhpMyAdmin старый, полагали, что баг в CMS, коих куча на машинке, но вероятность взлома PhpMyAdmin при прочих равных явно выше.
Приношу извинения за проблему, нашли источник, через который попадала зараза и закрыли. Теперь все должно быть ок, небольшие компенсации за косяк сообщил в тикете.
Меня одного смущает название картинки (shedevry-narkomanov-foto_56834_s__35.jpg) ? :)
