The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Анализ проблем безопасности и оценка времени поддержки Red Hat Enterprise Linux

08.09.2009 12:29

Опубликован отчет с анализом рисков, которым подвергаются пользователи необновленной версии RHEL 5.3. В отчете представлены обобщенные данные по уязвимостям, исправленным в промежутке между выходом релизов RHEL 5.3 и 5.4. За 7 месяцев было устранено 9 проблем, имеющих статус критических, семь из которых связаны с ошибками в Firefox и по одной проблеме в kdelibs и библиотеке NSS. Благодаря использованию в дистрибутиве технологии ExecShield, защищенных вариантов malloc/free и активации FORTIFY_SOURCE опции glibc (дополнительная внутренняя проверка выхода за пределы буфера для функций, таких как strcpy), три проблемы (dhclient, NTP и kerberos5) были защищены от выполнения кода злоумышленника и из разряда критических сведены к вызову отказа в обслуживании.

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

Всего для пакетов, поставляемых в базовой системе, за отчетный период было выпущено 51 уведомление о проблемах безопасности с информацией о 166 уязвимостях, из которых 8 критических, 18 важных и 25 средней и низкой степени опасности. Что касается всех пакетов, доступных через официальные репозитории, то выпущено 78 уведомлений (251 уязвимость), из которых 9 критических, 28 важных и 41 средней и низкой степени опасности.

В заключение, можно отметить публикацию в блоге Дага Вирса (Dag Wieers), активно участвующем в жизни проекта CentOS. Даг рассуждает, достаточно ли 7 лет поддержки (из которых 4 года добавляются новшества и еще год выходят обновления с поддержкой нового оборудования) для дистрибутивов линейки RHEL и предлагает для версий RHEL 5 и 6 увеличить время поддержки до 9 лет. В свете увеличения интервала между значительными релизами RHEL (между 3.x и 4.x - 1.5 года, между 4.x и 5.x - 2 года, между 5.x и 6.x - уже 3 года), при среднем четырехлетнем времени жизни оборудования, - семь лет выглядят недостаточно и поддержка может быть прекращена, когда пользователи еще не готовы к этому, а оборудование не успело морально устареть. Иными словами, новая ветка RHEL 6 выходит спустя три года с момента RHEL 5, еще примерно год переход будет невозможен в силу недостаточной поддержки новой ветки сторонними поставщиками, поэтому клиент будет вынужден установить RHEL 5 для которого остается всего 3-4 года полноценной поддержки, что недостаточно для покрытия времени устаревания оборудования.

  1. Главная ссылка к новости (http://www.awe.com/mark/blog/2...)
  2. OpenNews: Анализ рисков, связанных с проблемами безопасности в Red Hat Enterprise Linux
  3. OpenNews: Red Hat назвала 10 самых опасных программ за последний год
  4. OpenNews: Целесообразность перехода проектов на 6-месячный цикл разработки
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/23333-redat
Ключевые слова: redat, rhel, support, security
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (16) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, zerot (ok), 13:57, 08/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    да, это добрая тема
    большее время поддержки на типовых юниксовых сервисах, способных работать годами, это гуд
     
  • 1.2, sHaggY_caT (ok), 14:28, 08/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >семь из которых связаны с ошибками в Firefox

    В соседней теме всерьез предлагают ставить на каждый сервер, обязательно в бандл (что бы обновить было тяжело) именно FireFox :))

     
     
  • 2.12, User294 (ok), 15:37, 09/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так то ж крутые админы \m/ \m/. Хотя это еще что, я вот на виндовом доменном контроллере видел сильверлайт и апдейт меняющий мажорную версию IE, так что местные админы еще не самые крутые. Некоторые пошли чуть дальше и допускают мысль не только о ходьбе в интернет браузером с боевого сервака но и мысль о том что можно ходить в интернет браузером с стремными довесками прямо с сервака который не просто "боевой" а, пардон, авторизует всех юзеров домена и потому является довольно интересной мишенью хацкеров.
     
  • 2.16, Pilat (ok), 03:47, 10/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >В соседней теме всерьез предлагают ставить на каждый сервер, обязательно в бандл (что бы обновить было тяжело) именно FireFox :))

    Так как это речь о моём посте, поясняю. Некая sHaggY_caT продолжает врать, не знаю уж почему. Оригинальное сообщение выглядит так: "Или FireFox - нужен на сервере очень редко, но тянет за собой пол-дистрибутива зависимостей.". "Очень редко" трансформировалось в "каждый сервер".

     

  • 1.3, DJester (?), 14:59, 08/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вообще не понятно, зачем на сервере гуя и в частности гуевый браузер. Чтобы скачать что либо есть wget, а лазить по вебу с сервака совсем не православно ;).
     
  • 1.4, al (??), 15:27, 08/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Вообще не понятно, куда им время?
    Пиво пить?
    Вон фря работает годами, умелый админ в три движения поставит/выправит ее в/из любую позу. И простой измеряется еденицами часов в год.

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

     
     
  • 2.5, sHaggY_caT (ok), 15:38, 08/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Вон фря работает годами, умелый админ в три движения поставит/выправит ее в/из любую позу.

    Это приемлимо только в маленьких сетях. У нас несколько тысяч серверов на FreeBSD, мы никогда не обновляем систему 6.3 >> 6.4, 6.3 >> 7.2 и т д.

    Простой из-за того,что что-то все-таки не срастется, и из-за того, что такое обновление это всегда ручная работа, неприемлим.
    Мы и фревые и линуксовые серверы всегда заливаем по стандартному шаблону через PXE.
    В случае необходимости обновления системы, сервисы поднимаются на временном сервере, перезаливается система(тестируется, и т д), а потом сервисы переезжают назад.

    Когда серверов 5-10, да, можно и на линуксе делать apt-get dist-upgrade, yum upgrade, и т д, и все будет работать, если повезет, и руки не очень кривые :)

     
  • 2.8, konwin (?), 20:55, 08/09/2009 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вы мне в сертификационных таблицах всякого промышленного софта, аля Оракл, найдите фрю, я подумаю - может она действительно так хороша....
     

  • 1.6, аноним (?), 16:25, 08/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У нас в компании тоже на FreeBSD серверов предостаточно, все обновляются нормально, на паре серверов всё собирается, потмо маунтится по nfs и обновляется, пачками всё обновляется, машинки бегают на webserver сообщают свой uname и если приказанно то лезет обновляться. Скрипт причём примитивный.
     
     
  • 2.7, sHaggY_caT (ok), 16:35, 08/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Мы так делать не рискуем... Ставим только единичные пакеты(тоже собранные на специальном сервере, если фря, или с локального зеркала, если Linux), если какая-то дырка, а так, стараемся переписать шаблон под сервис, если нужно в него что-то добавить.

    А как вы узнаете, на каком именно сервере какую версию пакета нужно обновить, и как тестируете на предмет багов?

     
     
  • 3.9, ТТТ (?), 11:21, 09/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > и как тестируете на предмет багов?

    сколько раз я слышал от "опытных" программистов: "какие баги? в моем коде нет багов. зачем мне QA?". наверное в среде системных администраторов тоже полно таких "опытных" :-)

     
     
  • 4.14, User294 (ok), 15:43, 09/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >сколько раз я слышал от "опытных" программистов: "какие баги? в моем коде
    >нет багов. зачем мне QA?".

    Это стандартно для программистов. Хотя нет, это стандартно вообще для людей - ну кто же захочет видеть огрехи в своей работе?!Правильно - очень немногие.Свои результаты труда по определению кажутся человеку хорощими.Как же так - ведь он старался. А значит результат не может быть плохим. Правда баги - это не "плохо", это просто жизненно.Они - были, есть и будут есть, даже если некоторые и предпочитают их не замечать :P.

     

  • 1.10, Sw00p aka Jerom (?), 11:54, 09/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    я не пойму одного нах в серверном дистре иксы ???? плюс гном по дефолту

    а бедный ЭМСИ немогут по дефолту врубить

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

    приходится переправлять файлик чтобы он не тянул всю херню

    убираешь галочку сендмейл он поставит вам постфикс ))) какая радость

    пс: я выбираю RHEL

     
     
  • 2.11, Dimez (??), 12:46, 09/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Я пока леньсь кикстартом пользоваться - накатал скриптец, который после установки Base удаляет всё ненужное, ставит всё нужное и меняет настройки (типа, заведение пользователей, правка sudoers, правка ssd_config, чтобы рутом не пущало и прочее)
     
     
  • 3.13, sHaggY_caT (ok), 15:40, 09/09/2009 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кикстарт это очень просто :) правда:)) разобраться и настроить можно за один вечер, написать его под сервис можно за время установки Вашего типового сервера + 10 минут.

    Технология экономит просто потрясающее количество времени :)

     

  • 1.15, Romik (??), 19:39, 09/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Для серверов Fujitsu срок поддержки RHEL уже продлён:
    https://www.redhat.com/about/news/prarchive/2008/fujitsu-mc-alliance.html
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру