Упс...

Главные вкладки

Аватар пользователя axel axel 15 июля 2009 в 11:48

Ну вот, как всегда, стоило только на пару дней уехать из Москвы как всё порушилось. Стандартный админский кошмар - сервер падает именно тогда, когда к нему нет доступа. Хотя в данном случае авария получилась плановой. Хотя хостинг на VPS бесплатно предоставляется нам компанией Мастерхост счёт там заведён официальный и на счету лежат некие виртуальные деньги, которые исправно списываются системой биллинга. Вчера днём биллинг досчитал до нуля и отключил площадку за "неуплату". Вот так всегда и бывает, сошлось что приходящие уже давно от Мастерхоста предупреждения были проигнорированы, так как я их отнёс на счёт другой тестовой площадки, сотрудница Мастерхоста, которая нас курирует сейчас в отпуске, у меня была связь с только по мобиле (и как водится в нужный момент не завёлся gprs!), поэтому пришлось использовать голосовое управление сетью посредством друзей Smile Однако СПАСИБО за быструю помощь Акжану Абдулину, за разруливание контактов с Мастерхостом, Роме Архарову за оплату площадки (иначе сайт бы сейчас был всё ещё в дауне), Андрею Постникову и Егору Марценюку за оживление перезагрузившийся VPS (Егору отдельное спасибо за найденное решение с сетевым интерфейсом, без которого система бы не заработала) и Павлу Смирнову за работу в качестве ping ;). Однако жаль, у нас был такой шикарный аптайм - нонстоп уже больше года, шли на рекорд Wink

До утрясания всех оргвопросов drupal.ru будет пока переведён на другой сервер.
Собственно, уже утряслось. Мастерхостовцы продлили действие VPS. Во избежание подобных проблем в будущем уведомления с площадки будут настроены на почтовые адреса ещё нескольких участников сообщества, чтобы не только я смог на них среагировать.

Комментарии

Аватар пользователя axel axel 15 июля 2009 в 12:07

Химический Али wrote:
Ну вроде бы все штатно прошло, никто не потерялся. Долгая аптайм!

Не потеряется в любом случае, даже если vps исчезнет со всеми данными - бэкапы дублируются на внешний сервер на другой площадке (и планируется дублировать ещё на один на другом континенте - это на случай прямого попадания атомной бомбы в г.Москву).

Аватар пользователя Akzhan Akzhan 15 июля 2009 в 12:19

Нон-стоп больше года - просто великолепный показатель Smile

Учитывая, что нынешний даунтайм оказался чисто организационным Smile

Аватар пользователя axel axel 15 июля 2009 в 12:39

Akzhan wrote:
Нон-стоп больше года - просто великолепный показатель Smile

Учитывая, что нынешний даунтайм оказался чисто организационным :)

Это да. При том что был сделан апгрейд с дефолтного CentOS 5 который был на VPS на последнюю стабильную версию этого дистрибутива - перегружать после апгрейда не стали. Правда без косяков не обошлось, част настроек была без проверки и перезагрузка показала, что они были ошибочны - это собственно почему сайт лежал сегодня, когда сервер уже был доступен и nginx выдавал 500 ошибку - не работал mysql.

Акжан, ещё раз спасибо за помощь! Smile

Аватар пользователя Demimurych Demimurych 15 июля 2009 в 16:25

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

критических обновлений было с десяток.

Аватар пользователя gor gor 15 июля 2009 в 18:08

Demimurych wrote:
Ап тайм на цент ос в один год говорит о том что у Вас никто не накатывал обновления, что говорит о том что Вы жили на вулкане.

критических обновлений было с десяток.


В общем вы правы, в частности - нет.
Начнем с того, что линукс это система которая требует перезагрузки ТОЛЬКО в случае обновления ядра. Если обновляются другие пакеты - то в перезагрузке нет смысла. Тоесть все верно говорите - было много обновлений по ядру, были рут эксплоиты.. да вот только для веток 2.6.2*.
ВДС работают на платформе virtuozzo и иже с ними openvz. Данная схема предполагает что для всего сервера единое ядро, обновить которое из ВДС невозможно.
Получается что перезагрузка для ВДС нужна только когда владельцы хостинга обновляют ядро.
Базовое ядро на сейчас из серии 2.6.18 а оно то какраз критических уязвимостей не содержало.

Посему подведу черту. вы правы в общем, но в этой частной ситуайции - неправы,в силу не понимания спицифики работы ВДС.

Аватар пользователя Demimurych Demimurych 15 июля 2009 в 22:43

"gor" wrote:
Базовое ядро на сейчас из серии 2.6.18 а оно то какраз критических уязвимостей не содержало.

поперхнулся. Добро пожаловть из анабеоза Wink :

пожалуйста пример CVE-2009-1439 удаленный дос.
А вобще смотрите сами на сайте RHEL а
http://www.redhat.com/security/data/metrics/summary-rhel5-all.html

И это не говря о наличи в паблике работающего локал рута
http://www.milw0rm.com/exploits/8369

так что на вашем месте я бы недоверял вышему хостеру. В настоящший момент большой аптайм возможен только у дистрибутивов (например убунта сервер), который умеют накатывать обновления (не все но приблизительно 70%) на ядро без перезагрузки.

Аватар пользователя gor gor 16 июля 2009 в 1:17

Demimurych wrote:
"gor" wrote:
Базовое ядро на сейчас из серии 2.6.18 а оно то какраз критических уязвимостей не содержало.

поперхнулся. Добро пожаловть из анабеоза Wink :

пожалуйста пример CVE-2009-1439 удаленный дос.
А вобще смотрите сами на сайте RHEL а
http://www.redhat.com/security/data/metrics/summary-rhel5-all.html

И это не говря о наличи в паблике работающего локал рута
http://www.milw0rm.com/exploits/8369

так что на вашем месте я бы недоверял вышему хостеру. В настоящший момент большой аптайм возможен только у дистрибутивов (например убунта сервер), который умеют накатывать обновления (не все но приблизительно 70%) на ядро без перезагрузки.

Мен, о чем говорю - знаю.
попробуй запустить этот ксплоит на ядрах 2.6.18* (Если есть где) потом обсудим эту тему, если будет что обсуждать.

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

Еще раз повторю, хочешь говорить в теме, а не в общем (в общем ты прав - надо юзать последние релизы ядер, патчится ака бешеный и прочее) - попробуй для начала на тест компе завести openvz (основной рынок ВДС, работает на нем, следуюший за ним XEN). А потом попробуй его завести на последнем доступном ядре с kernel.org.

Тупо не выйдет, ибо openvz это около 10MB патча на ядро. И стейбл ветка у них 2.6.18 а не 2.6.2*.

Если есть конкретные вопросы почему и как - отвечу в меру свободного времени, иначе (имхо) тема закрыта.

Аватар пользователя Demimurych Demimurych 16 июля 2009 в 10:54

"gor" wrote:
Мен, о чем говорю - знаю.

тоже не вчера родился.

"gor" wrote:
опробуй запустить этот ксплоит на ядрах 2.6.18* (Если есть где) потом обсудим эту тему, если будет что обсуждать.

регулярно этим занимаюсь поскольку безопасность это лично моя ответственность за что я получаю большие деньги.
конечно сейчас на вашем новом ядре оно работать не будет. На ванильном 2 6 18 работало. Естественно пока не пропатчили.

"gor" wrote:
Спорить по каждому из списка - имхо глупо, а со мною еще и бесполезно (я в хак среде уже более 6 лет)

обожаю мерятся йухами
А я свой первый вирус написал в в 1995 году, а в 97 запустил 95 винду в своей виртуальной машине и что?

"gor" wrote:
основной рынок ВДС, работает на нем, следуюший за ним XEN)

Об этом лучше бы вообще не заикаться. Потому что я сейчас кину еще список конкретно под XEN.

"gor" wrote:
Если есть конкретные вопросы почему и как - отвечу в меру свободного времени, иначе (имхо) тема закрыта

Дружище.
Я тебя поставил перед фактом дав ссылку конкретно на первоисточник, где есть минимум 6 тикетов на обязательное обновление ядра. ОФИЦИАЛЬНО ПРИЗНАНЫХ самим ред хатом.

Аватар пользователя gor gor 16 июля 2009 в 15:40

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

[root@robin ~]# uname -a
Linux robin.local 2.6.18-92.1.18.el5 #1 SMP Wed Nov 12 09:30:27 EST 2008 i686 i686 i386 GNU/Linux
[root@robin ~]# sh e8369.sh
suid_dumpable=0 - system not vulnerable!
[root@robin ~]# cat /proc/sys/fs/suid_dumpable
0
[root@robin ~]# echo 1 > /proc/sys/fs/suid_dumpable
[root@robin ~]# sh e8369.sh
logrotate installed, that's good!
Compiling the bash setuid() wrapper...
Compiling the exploit code...
Setting coredump limits and running the exploit...

The system is not vulnerable, sorry Sad