The OpenNET Project / Index page

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

Серверы инфраструктуры Fedora и Red Hat были взломаны

22.08.2008 22:52

Неделю назад в списке рассылки анонсов проекта Fedora был опубликован призыв не производить загрузку или обновление пакетов до специального объявления. Сегодня работа серверов была полностью восстановлена, а причины проблем раскрыты.

Сообщается, что проблемы затронули не только Fedora, но и серверы Red Hat. Злоумышленники неизвестным способом получили контроль над машинами и смогли сформировать цифровые подписи для нескольких фиктивных пакетов с OpenSSH, ключами от RHEL 4 и RHEL 5. В репозиториях Fedora и Red Hat пакетов с нарушенной целостностью отмечено не было.

Причина утечки пароля для подписывания пакетов так и не была установлена. Скрипт для выявления фиктивных openssh пакетов представлен на данной странице (риск получить фиктивное обновление openssh имеют клиенты Red Hat обновляющие систему не через Red Hat Network).

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

Разработчики проекта CentOS опубликовали информационное письмо, в котором уверили пользователей, что атака на Fedora и RedHat не затронула проект CentOS. Для проверки был проведен аудит системы сборки и подписывания пакетов, также были проанализированы исходные тексты двух последних версий пакета с openssh. Серверы инфраструктуры CentOS находятся за многоступенчатым межсетевым экраном и доступны для входа лишь для небольшого числа разработчиков с заранее оговоренного списка адресов.

  1. Главная ссылка к новости (http://www.mail-archive.com/fe...)
  2. OpenNews: Проблемы в инфраструктуре проекта Fedora
  3. OpenNews: Отчет о проблемах безопасности при работе менеджеров пакетов в Linux
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/17510-redhat
Ключевые слова: redhat, fedora, security, openssh
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (81) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, kost BebiX (?), 01:26, 23/08/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На самом деле единственное что в этой всей ситуации напрягло - я хочу обновить qt до ветки с нормальным webkit, а они приостановили обновления репозиториев и приходится сидеть на qt 4.4.1.2.fc10.
     
  • 1.3, Dmitri (??), 01:32, 23/08/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > However, based on our efforts, we have high confidence

    that the intruder was not able to capture the passphrase used to secure
    the Fedora package signing key. Based on our review to date, the
    passphrase was not used during the time of the intrusion on the system
    and the passphrase is not stored on any of the Fedora servers.

    Непонятно как ключ утек.
    Да и формулировка какая-то желтая.

     
     
  • 2.21, dry (?), 13:26, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Дело ясное,
    либо кто-то из своих же разработчиков, простите, про@бал ключ и никому не сказал,
    либо кто-то из них же слил его за вполне конкретную сумму условных единиц.
    Ни то не другое никак не радует.
    Причем первое не радует больше, если человек предпочел скрыть утерю ключа,
    вместо того, чтобы получить пендель по жопе, но защитить заказчиков своей конторы.
     
     
  • 3.45, Dmitri (??), 23:38, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Еще он мог 'потерять' ключ и не знать об этом. Например:
    Снял блондинку в баре, привел домой. Комп естественно включен и скринсейвер не требует ввода пароля. Когда он был в душе блондинка скопировала private ключи на флешку.

    Согласен, прикольная история. Но там много более реалистичных вариантов.

     
  • 2.30, Logo (ok), 17:19, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да, как признаться, что у супербезопасного RHL дыра. Это только Debian'новцам смелости хватило сказать, что они сами глюк впороли и теперь потерпите, пока мы поправим :)
     

  • 1.4, Alex (??), 03:09, 23/08/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Фигасе, чё вытворяют с основными серваками обоих проектов...
    А ведь только здесь (https://www.opennet.ru/opennews/art.shtml?num=17513) написали, что "Серверы и рабочие станции аэропорта Мюнхена переведены на использование Red Hat Linux". Ладно сам проект - не так страшно, переустановили ПО и забыли. Но вот аэропорт доверить красной шапке после этого, особенно после "Злоумышленники НЕИЗВЕСТНЫМ СПОСОБОМ получили КОНТРОЛЬ НАД МАШИНАМИ" и "ПРИЧИНА утечки пароля для подписывания пакетов так и НЕ БЫЛА УСТАНОВЛЕНА". Если уж самые первые спецы проекта не могут разобраться, мне жаль Мюнхен.
    А потом все скажут "русские идут"... :)
     
     
  • 2.5, User294 (??), 03:27, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >А потом все скажут "русские идут"... :)

    Ну, когда МИЛЛИОНЫ виндовых машин регулярно шлют спам и т.п. - почему-то никто не интересуется где они стоят.А стоят они много где.Включая и туеву хучу важных оьъектов.А тут из-за 1 инцидента страшно.На фоне миллионов :).Жить вообще страшно кстати - от этого умирают :\

     
     
  • 3.8, Щекн Итрч (?), 08:51, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    МИЛЛИОНЫ машин пусть шлют спам.
    А вот взломанный РЕПОЗИТОРИЙ RH - это нечто чуть-чуть иное :)
    Вам самому так не кажется? :)
     
     
  • 4.49, User294 (ok), 03:04, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >МИЛЛИОНЫ машин пусть шлют спам.
    >А вот взломанный РЕПОЗИТОРИЙ RH - это нечто чуть-чуть иное :)
    >Вам самому так не кажется? :)

    Мне кажется что когда одним можно срать по всей планете и все настолько к этому привыкают что бревна в их глазу не видят зато в редхатовском глазу разглядели соринку - это немного попахивает двойными стандартами.Нет, редхату конечно незачот но в конце концов они для клиентов выпустили решение и приняли меры.И при том не тянули месяц как одна всем известная контора.У меня к ним ровно 1 претензия - не вижу полной картины случившегося и описания методов хакеров(как они вообще это сделали и как отличить трояненый ssh от обычного).Что усложняет ситуацию если у вас не редхат (если например есть неизвестная дыра, врядли хакеры ограничатся только редхатом).

     
  • 3.14, alen (??), 11:53, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Смерь одного - трагедия, смерть миллионов - статистика :)  (с) И.В Сталин
    ;)
     
     
  • 4.41, Аноним (-), 23:01, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    А вот тут http://bibliotekar.ru/encSlov/17/132.htm пишут что это говорил совсем не Сталин. Оно вам нужно - врать так про бывших правителей ?


    Смерть одного человека — это смерть, а смерть двух миллионов — только статистика

    Из романа (гл. 8) «Черный обелиск» (1956) немецкого писателя Эриха Марии Ремарка (1898—1970), автора многих антивоенных романов, в которых говорится о судьбах так называемого потерянного поколения, пережившего Первую мировую войну.

    Иногда фраза встречается в форме: «Смерть одного человека — это трагедия, смерть двух миллионов человек — только статистика».

    Смысл выражения: человеку свойственно привыкать к чужой смерти, к массовым жертвам, при условии, что он имеет возможность смотреть на них со стороны.

     
     
  • 5.50, User294 (ok), 03:08, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Смысл выражения: человеку свойственно привыкать к чужой смерти, к массовым жертвам, при
    >условии, что он имеет возможность смотреть на них со стороны.

    Вот и к перманентным горам гуано лезущего с виндовых машин так вот привыкли.Да, removal tool продезинфицировал миллион машин.Повод для MS гордо растопырить пальцы - мы,типа, боремся!А если сказать менее удобно для MS то получится иначе: "то есть, миллион машин с вашей суперсекурной системой годами валил спам и вирье во все стороны?!"

     
  • 5.61, Insa88 (?), 10:08, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >А вот тут http://bibliotekar.ru/encSlov/17/132.htm пишут что это говорил совсем не Сталин. Оно
    >вам нужно - врать так про бывших правителей ?
    >
    >

    А года смерти Сталина и написания данного произведения ни о чем не говорят?

     
  • 5.63, dexter (??), 15:25, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >
    >Из романа (гл. 8) «Черный обелиск» (1956) немецкого писателя Эриха Марии Ремарка
    >(1898—1970), автора многих антивоенных романов, в которых говорится о судьбах так
    >называемого потерянного поколения, пережившего Первую мировую войну.
    >
    >Иногда фраза встречается в форме: «Смерть одного человека — это трагедия, смерть
    >двух миллионов человек — только статистика».
    >
    >Смысл выражения: человеку свойственно привыкать к чужой смерти, к массовым жертвам, при
    >условии, что он имеет возможность смотреть на них со стороны.

    Берите шире.
    Человеку просто свойственно привыкать ко всему, иначе он не выжил бы.

     
  • 2.9, Щекн Итрч (?), 08:59, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > Злоумышленники НЕИЗВЕСТНЫМ СПОСОБОМ...

    Правильно порутатое вторжение обнаружить очень сложно... :)

    Логи надо вести, и вести логи надо удаленно...
    И КС ФС наблюдать регулярно...
    И читать сообщения систем безопасности :)

    Расслабились :)
    Бразильеро залил им в ТМР, скажем штук триццать "тестов" за пару месяцев, глядит, реакции нет, ТМП чистится и все... Ну, думает, помолясь креольским богам, зарутаемся-ко и почистим за собой бекдор, благо логов админы не ведут и не хранят... :)

     
     
  • 3.13, Аноним (13), 10:51, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    любую атаку можно отследить, если есть поддежка гб на уровне стран
     
     
  • 4.23, Щекн Итрч (?), 14:20, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >любую атаку можно отследить, если есть поддежка гб на уровне стран

    ТОЛЬКО если есть поддержка логов на уровне местного админа :) :) :)

     
     
  • 5.31, Logo (ok), 17:23, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    +100
     
  • 5.33, Аноним (-), 19:33, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    самомнение губит детей...
     
     
  • 6.34, Щекн Итрч (?), 20:52, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >самомнение губит детей...

    Не совсем понимаю, за что выступаете... Но если против, скажем, моего мнения?
    Тогда что, ГБ будет пытать электроны в атоме, добиваясь от них сведений о событиях, НЕ зафиксированных в логах вашей системы? :) :) :)

     
  • 4.51, User294 (ok), 03:14, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >любую атаку можно отследить, если есть поддежка гб на уровне стран

    Угу, а хакеры по вашему клинические дебилы?Знаете сколько есть методов сделать все и вся анонимно или от лица левой персоны?Как пример: 5 минут вардрайвинга и весь хак якобы осуществил какой-то лох, забывший про использование WPA.При слове логи чувак с таким уровнем развития только похлопает глазами.И даже если вы засунете ему в зад паяльник - ему не в чем признаваться.Ну разве что в том что он - дебил.

     
  • 2.38, Аноним (-), 21:48, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    в 2002 был взломан оф сайт openbsd, как известно самой секурной ОСи по дефолту. были протроянены исходники ссша.
    (хотя вроде сам сервак(и) был наскоклько я помню на солярке.) после этого я перестал верить в информационную безопасность.
    и более того я УВЕРЕН в том что windows update тоже ломали, просто об этом никто не узнал(т.к. никто не сказал), на след день наверно просто выпустили патчик, к-ый всё это закрывал. ведь кто знает что обновляется в венде на самом деле? пишут в аннотации патча "windows media player security update" а на самом деле закрывают страшный баг в tcpip.sys.
    Безопасности нет...
     

  • 1.6, User294 (??), 04:50, 23/08/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кстати о птичках ... я тут вспомнил что видел апдейт ssh кой-где недавно, это не редхат но мне показалось странным что ssh обновился без особых анонсов.Есть ли где-то образец трояненого ssh и пример вредительских изменений или хотя-бы описание того что там, какие характерные изменения вносятся для целей троянства и прочая?А то я что-то не уверен что эти засранцы ограничатся только этими действиями.
     
     
  • 2.32, Bod (??), 17:30, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Кстати о птичках ... я тут вспомнил что видел апдейт ssh кой-где
    >недавно, это не редхат но мне показалось странным что ssh обновился
    >без особых анонсов.Есть ли где-то образец трояненого ssh и пример вредительских
    >изменений или хотя-бы описание того что там, какие характерные изменения вносятся
    >для целей троянства и прочая?А то я что-то не уверен что
    >эти засранцы ограничатся только этими действиями.

    А если скачать их скрипт http://www.redhat.com/security/data/openssh-blacklist.html и посмотреть, что он там ищет. Не поможет? Сам не качал. RH не использую.

     
     
  • 3.35, Michael Shigorin (ok), 21:28, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > А если скачать их скрипт и посмотреть, что он там ищет. Не поможет?
    > Сам не качал. RH не использую.

    Он смотрит md5 по списку известных как "левопакеты правоподписанные".

    Кстати, довольно интересная реализация хэшей на шелле, не знал такого финта :-)

    PS: качать немного, RH не использую.

     
  • 3.48, User294 (ok), 02:50, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >А если скачать их скрипт

    Качал, смотрел.Совершенно бесполезная конструкция для всех кроме пользователей конкретных версий редхата т.к. скрипт всего лишь смотрит нет ли в системе пакетов с проблемным MD5.И все.Весьма неуниверсальное решение, а вот уверенности что хаксоры ограничатся только редхатом что-то нет.

     
     
  • 4.66, Michael Shigorin (ok), 17:36, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Весьма неуниверсальное решение, а вот уверенности что хаксоры ограничатся только
    >редхатом что-то нет.

    Эт-та... а куда универсальней быть решению проблемы с конкретным неавторизованным использованием ключа?

    Не ограничатся, разумеется -- будут другие проблемы и другие решения.  C'est la vie.

     
     
  • 5.74, User294 (??), 20:51, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Эт-та... а куда универсальней быть решению проблемы с конкретным
    >неавторизованным использованием ключа?

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

     

  • 1.10, Аноним (10), 09:59, 23/08/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    миф о надежности и неломаемости линупса развенчан, причом сломан один из самых раскрученных коммерческих линупсов, причом в самое яблочко. Вам ясно дали понять, что надежность вся ваша миф, а rbac и прочие se примочки просто не работают. Ломается все и вся и нет доверия ни одному ПО, вопрос только в сложности/трудозатрах. Кому нафиг сдался скажем какнибудь инет шлюз некой компании торгующей носками? Его сломать нереально? Реально, только нафиг никому не надо. А от кул хацкеров да, ваши файрволы спасают, оттого и мнимое ощущение безопасности. Но реально путей взлома при надобности очень много. Так что перестаньте мерятся одним местом, какая из ОС самая самая. Все дырявые, вопрос в трудозатратах.
     
     
  • 2.11, k (??), 10:29, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >миф о надежности и неломаемости линупса развенчан, причом сломан один из самых
    >раскрученных коммерческих линупсов, причом в самое яблочко. Вам ясно дали понять,
    >что надежность вся ваша миф, а rbac и прочие se примочки
    >просто не работают. Ломается все и вся и нет доверия ни
    >одному ПО, вопрос только в сложности/трудозатрах. Кому нафиг сдался скажем какнибудь
    >инет шлюз некой компании торгующей носками? Его сломать нереально? Реально, только
    >нафиг никому не надо. А от кул хацкеров да, ваши файрволы
    >спасают, оттого и мнимое ощущение безопасности. Но реально путей взлома при
    >надобности очень много. Так что перестаньте мерятся одним местом, какая из
    >ОС самая самая. Все дырявые, вопрос в трудозатратах.

    password, user i ip ne dat' tebe?

    /k

     
  • 2.18, Michael Shigorin (ok), 12:37, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >миф о надежности и неломаемости линупса развенчан

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

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

     
  • 2.22, remi (?), 14:16, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >миф о надежности и неломаемости линупса развенчан, причом сломан один из самых
    >раскрученных коммерческих линупсов, причом в самое яблочко. Вам ясно дали понять,
    >что надежность вся ваша миф, а rbac и прочие se примочки
    >просто не работают. Ломается все и вся и нет доверия ни

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

     
  • 2.24, Аноним (-), 14:23, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Ты идиот что ли Или дебил Украли КЛЮЧ от openssh, а не Red Hat взломали ... большой текст свёрнут, показать
     
     
  • 3.36, Michael Shigorin (ok), 21:31, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Украли КЛЮЧ от openssh, а не Red Hat взломали

    Вообще-то получили неавторизованный доступ к ключу gpg, которым подписываются пакеты Fedora, и другому ключу gpg, которым подписываются пакеты RHEL.

    Пакеты то ли не успели вытечь через обычные арыки, но RH выпустили critical errata с обновлением прошлогоднего minor недочёта в openssh.  Какое это имеет отношение, помимо "заведомо более свежая сборка, заодно то заткнули" -- пока не пойму, у них же всё равно ssh -X == ssh -Y из коробки?

     
  • 2.55, User294 (ok), 05:11, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >миф о надежности и неломаемости линупса развенчан

    Ой, откуда таких специалистов то повылезло с дефектами речи?Шамкают тут как старые бабушки какую-то муть, половина из которой старческий маразм а половина всем известные факты типа "трава зеленая" и "солнце светит".

     

  • 1.12, Аноним (13), 10:30, 23/08/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Может я что то не понял но там было про уязвимость OpenSSH при работе с протоколом X11, может взломали как раз через это (перехватили удаленную сессию X11 какого нибудь админа RedHat). Если так, то мораль - X11 пора заниматься своим делом - графикой, а не сетевыми протоколами.
     
     
  • 2.15, Vovanxx1 (?), 11:59, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Жалко это признавать, но статистика не врёт...Чем более популярной становится ОС, тем больше в ней находят серьёзных уязвимостей, причём дырки стали появляться в самом ядре, а некоторые вообще до конца не объяснены и не изучены. Да же судя по этому ресурсу, чуть ли на каждую неделю находится что-то не хорошее: неуспели с днсом разобраться дык терь ещё и ось менять...Кстати не факт что эта дырка относится только к тем дистрибам, что названы сдесь, на мой взгляд в ближайшее время мы увидим либо критические обновления на остальных дистрибах, либо заявления об их удачном хаке. Плохо то, что инфа об этих дырках скорее всего пока замалчивается, что бы редхетовцы вместе с публикацией инфы сразу похвастались своими патчами, мол мы пока единственные у кого они есть. А в это время злоумышленники спокойно пользуются тем что нашли + в случае такого хода будет как с днсом - сразу умолчали, а потом огребли но уже все, да же те, кто умолчал. Только тут дело посерьёзнее будет, рутовый шел, это не хухры-мухры, многие захотят что либо поправить, но уже может быть поздно...
     
     
  • 3.16, lelik (?), 12:12, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    причём здесь ОС, если "взлом" был через стыренный пароль? Точно также можно "взломать" шифрованный диск, если у тебя есть доступ к телу владельца пароля от него, дальше дело техники - водка, ломик, кусачки....
     
     
  • 4.17, Vovanxx1 (?), 12:22, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >причём здесь ОС, если "взлом" был через стыренный пароль? Точно также можно
    >"взломать" шифрованный диск, если у тебя есть доступ к телу владельца
    >пароля от него, дальше дело техники - водка, ломик, кусачки....

    Скажи чем в данном контексте отличается "стырили" от "взлом"? Почему им тогда не написать КАК они его стырили...стырили рутовые пароли от репозиториев дяди феди в красной шляпе, ась? И действительно ли были стырены пароли, или всё же имел место какой-то другой способ получения рутового шела, у??

     
     
  • 5.28, lelik (?), 15:58, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    особенно ничем. Ещё у "стырили" есть синоним "скомпрометировать" :)
     
  • 3.19, Michael Shigorin (ok), 12:46, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >неуспели с днсом разобраться дык терь ещё и ось менять...

    Помогает всё-таки оценивать происходящее адекватно, по возможности понимая суть проблемы.

    В DNS она совсем другого класса.

    >Кстати не факт что эта дырка относится только к тем дистрибам, что названы сдесь,

    Возможно, она относится к их *инфраструктуре*.  Тогда может быть уникальной -- locl misconfiguration или human error.  Возможно -- 0day, тогда *может* относиться к другим (а может и не).

    >на мой взгляд в ближайшее время мы увидим либо критические обновления на остальных
    >дистрибах, либо заявления об их удачном хаке.

    Посмотрим.

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

    Вы, похоже, совсем не представляете себе механизмы распространения информации о подобных проблемах.  Я порой получаю форварды и немного представляю...

    Вкратце -- security response team функционирует отдельно от администраторов инфраструктуры, хотя в подобных случаях явно их консультирует.  При этом если бы уже получилось идентифицировать место проблемы, то по правильным каналам она бы уже прошла.  Потому что вопрос тогда сводился бы к тому, как максимально быстро и качественно (а для этого и помогает даже ограниченный peer review) её порешить.

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

    >Только тут дело посерьёзнее будет, рутовый шел

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

     
     
  • 4.20, Vovanxx1 (?), 13:02, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Жалко это признавать, но статистика не врёт...Чем более популярной становится ОС, тем больше в ней находят серьёзных уязвимостей
     
     
  • 5.26, vitek (??), 14:54, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    чего то про уязвимость ОС я ничего пока не нашёл.
    может ни там читаю? :-D
     

  • 1.29, Logo (ok), 17:14, 23/08/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ай-яй... А сколько было "вони" по поводу OpenSSL Debian. Оказывается все мы смертные и ненужно радоваться чужой беде (я не фанат Debiana, сейча сижу на Mandriva). А вот админы у Debian оказались пошустрее, уважение им.
     
     
  • 2.37, Michael Shigorin (ok), 21:33, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Оказывается все мы смертные и ненужно радоваться чужой беде

    Дык не нужно.  Выводы вот делать стоит хотя бы на своём уровне... ну и подождём информации о том, как же всё-таки был получен доступ (что в отличие от случая с Debian -- может быть опубликовано и сильно позже, поскольку RH есть акционерная контора).

     
  • 2.39, mv (??), 22:06, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Вы разницу не видите? В случае Дебиана был факт изменения кода openssh неграмотным мантейнером, обновление всех систем и их готовность к взлому, а в случае с Федорой/RH админы заблаговременно обнаружили факт кражи ключа подписи пакетов и отключили все обновления. Никто из кастомеров RHEL вообще не пострадал. На конечных пользователей это отразилось только тем, что некоторое время были недоступно обновление. Респект редхатовцам, что они смогли оперативно обнаружить факт кражи и не допустить возможности эксплуатации краденного ключа злоумышленниками.
     
     
  • 3.42, Все тот же аноним (?), 23:02, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Поддерживаю точку зрения целиком и полностью. И еще: они (Red Hat) вполне могли придумать набор левых отмазок, но предпочли реально описать проблему и предпринятые шаги. Открытость - это дорого стоит.
     
     
  • 4.43, vitek (??), 23:11, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    согласен полностью!!!
     
  • 4.52, User294 (ok), 03:21, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > Открытость - это дорого стоит.

    Дык блин, ну и где описание метода взлома?И хотя-бы какое-либо описание что из себя представляет этот троян??? (как работает, какие подстроки характерные, etc).Открытость какая-то половинчатая: наличие проблем где либо еще кроме редхата по такой информации не проверишь нифига.

     
  • 3.44, pavel_simple (??), 23:17, 23/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Вы разницу не видите? В случае Дебиана был факт изменения кода openssh

    ну пусть будет всё-же openssl
    >неграмотным мантейнером,

    мантайнер ктати сказать всё-же очень даже грамотный -- именно это (горе от ума) и привело к таким последствиям
    > обновление всех систем и их готовность к взлому, а

    если не уверены -- то лучше прочитать в оригинале разбор полётов -- домысливать в данном случае не верный подход
    >в случае с Федорой/RH админы заблаговременно обнаружили факт кражи ключа подписи

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

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

    P.S. https://www.opennet.ru/openforum/vsluhforumID3/42416.html#12
    ...
    "Так ли вы уверенны в своём дистрибутиве чтобы говорить об отсутствии подобных ошибок в нём?"
    ...

     
     
  • 4.47, Michael Shigorin (ok), 23:52, 24/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >ну пусть будет всё-же openssl
    >>неграмотным мантейнером,
    >мантайнер ктати сказать всё-же очень даже грамотный -- именно это
    >(горе от ума) и привело к таким последствиям

    Я бы не стал смешивать "грамотность" и "активность" (в угоду линтерам и valgrind'ам).

    >"Так ли вы уверенны в своём дистрибутиве чтобы говорить об отсутствии подобных
    >ошибок в нём?"

    В нашем покамест _таких_ не замечено.  Разумеется, гарантий это никаких не даёт...

     
  • 2.53, User294 (ok), 03:25, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >А вот админы у Debian оказались пошустрее, уважение

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

     
     
  • 3.57, www2 (??), 08:50, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>А вот админы у Debian оказались пошустрее, уважение
    >
    >С**и они :) при всем уважении к дебиану.Если уж не шарите в
    >криптографии - нефиг ее своими руками лапать.Итого было дохрена геморроя и
    >наверняка по планете еще гуляет вагон уязвимых сертификатов и ключей.

    Смайлик прощает такое заявление, но на всякий случай хочу сказать вот что.

    Debian'щики делают колоссальную работу, которая доступна любому практически бесплатно. Каких гарантий вы хотели? Вы так рады увидеть соломинку в чужом глазу?

    Шарящие в криптографии, видимо плохо шарили в программинге, если в качестве источника энтропии использовали неинициализированный блок памяти. Насколько случайные там окажутся данные - не знает никто. Мэйнтэйнер пофиксил использование неинициализированного массива, отсюда и были проблемы. Если бы программисты использовали в качестве источника энтропии /dev/urandom, этого бы не произошло.

     
     
  • 4.58, pavel_simple (??), 09:11, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > Если бы программисты использовали в качестве источника энтропии /dev/urandom, этого
    >бы не произошло.

    +1

    http://www.gnu.org/software/gnutls/manual/gnutls.html#Compatibility-with-the-
    скорее-бы допилили -- а то на моей памяти openssl всё чинят и чинят

     
  • 4.59, User294 (ok), 09:36, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Смайлик прощает такое заявление,

    Да потому и стоит.Я уважаю их за проделанную работу.Но хочу все-таки сказать что не надо совать лапы в криптографический код.Особенно в такие места.Не надо пытаться быть святее папы римского.Чревато, как видим.

    >Вы так рады увидеть соломинку в чужом глазу?

    Чужом?Если бы :( за***лся ключи в пожарном порядке перегенерять.В убунтах и дебианах прежде всего.Сколько их таких хороших в других системах осело - а хрен его знает.Теперь за счет такой деятельности SSL и SSH далеко не столь иж и Secure, потому как проблемных сертификатов и ключей наверняка еще вагоны.

    >Если бы программисты использовали в качестве источника энтропии /dev/urandom, этого
    >бы не произошло.

    А, раз вы в этом шарите тогда кстати прокомментируйте - а что с этим девайсом в Дебиане за приколы? Вот тут: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350396

    Это что еще за баг такой?Упорно не вдупляю в суть предъяв aMule'у.Заголовок бага выглядит как фантастика или сказка.Или просто суровый стеб.Что за  .. ?Дескать слишком много юзают девайс.Эээ а он разве не для того сделан чтобы юзать?

     
     
  • 5.60, www2 (??), 10:01, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    С вами и с "Аноним1" я спорить не собираюсь. Вы те ещё тролли, поберегу своё время.


     
     
  • 6.72, User294 (??), 20:37, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >С вами и с "Аноним1" я спорить не собираюсь.

    А я разве тут предлагал о чем-то спорить?Я всего лишь выразил неудовольствие некоторыми действиями дебианщиков которые раздражают + спросил что за прикол с багом, title которого стабильно вгоняет меня в ступор ибо я не понимаю как это - "depletes entropy pool".Думал что раз вы советуете /dev/urandom - может в курсе в чем там проблема.А вы... :\

     
  • 5.68, Michael Shigorin (ok), 17:47, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>Если бы программисты использовали в качестве источника энтропии /dev/urandom,
    >>этого бы не произошло.

    1) насколько понимаю, это было design decision
    2) используют: http://www.openssl.org/support/faq.cgi#USER1

    >Дескать слишком много юзают девайс.Эээ а он разве не для
    >того сделан чтобы юзать?

    Почитайте urandom(4) в части сравнения с random(4) -- во-первых, эти два девайса уже созданы с разными целями и предоставляют разное качество случайности; во-вторых, оба они выюзывают enthropy pool, который потихоньку заполняется из ряда источников ядром.

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

     
     
  • 6.69, www2 (??), 18:10, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>>Если бы программисты использовали в качестве источника энтропии /dev/urandom,
    >>>этого бы не произошло.
    >
    >1) насколько понимаю, это было design decision
    >2) используют: http://www.openssl.org/support/faq.cgi#USER1

    Прочитал по ссылке - действительно используют /dev/[u]random.
    Почему тогда исключение неинициализированного массива из источников энтропии привело к резкому снижению количества генерируемых ключей? Получается массив был основным источником энтропии?

    >>Дескать слишком много юзают девайс.Эээ а он разве не для
    >>того сделан чтобы юзать?
    >
    >Почитайте urandom(4) в части сравнения с random(4) -- во-первых, эти два девайса
    >уже созданы с разными целями и предоставляют разное качество случайности; во-вторых,
    >оба они выюзывают enthropy pool, который потихоньку заполняется из ряда источников
    >ядром.

    Прочитал. random даёт столько бит, сколько есть в пуле, urandom - сколько запрошено, пусть даже энтропия будет хуже по качеству.

    >Суть предъявы -- в колодец с питьевой водой загнали грязный шланг и
    >ну в бетономешалку сосать.  Вместо того, чтоб из соседнего пруда.

    Не понял смысла предложения. Это получается у Вас: колодец - random, пруд - urandom, а грязный шланг - это неинициализированный массив, бетономешалка - это их (OpenSSLщиков) внутренний буфер энтропии?

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

     
     
  • 7.70, www2 (??), 18:13, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    *мутных без аналогий = без мутных аналогий


     
  • 7.78, Michael Shigorin (ok), 12:27, 26/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Почему тогда исключение неинициализированного массива из источников энтропии
    >привело к резкому снижению количества генерируемых ключей? Получается массив
    >был основным источником энтропии?

    Из того, что читал -- не помню уже, перечитывать сейчас неинтересно.

    >>Суть предъявы -- в колодец с питьевой водой загнали грязный шланг и
    >>ну в бетономешалку сосать.  Вместо того, чтоб из соседнего пруда.
    >Не понял смысла предложения. Это получается у Вас: колодец - random, пруд
    >- urandom, а грязный шланг - это неинициализированный массив

    Не, шланг -- это обращение :-)

    >бетономешалка - это их (OpenSSLщиков) внутренний буфер энтропии?

    Выше не про OpenSSL спрашивали, а уже про торрент-клиент.  Который вытягивал неоправданно качественную энтропию из системы вместо того, чтоб за'seed'ить свой PRNG и тянуть из него.

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

    Как ни странно, никого не защищаю и ни на кого не наезжаю. :-)

     
     
  • 8.80, www2 (??), 12:59, 26/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Уже почитал заметку в LJ Витуса Вагнера http vitus-wagner livejournal com 279... текст свёрнут, показать
     
  • 8.84, User294 (ok), 10:42, 01/09/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Про ed2k клиент, если уж говорить точнее Осел такой же вариант торента как HTTP ... текст свёрнут, показать
     
     
  • 9.85, www2 (??), 10:55, 01/09/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Ну-ну, на Вас только время тратить Я же прекрасно знаю, что Ваши вопросы неисся... текст свёрнут, показать
     
  • 6.73, User294 (??), 20:46, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Суть предъявы -- в колодец с питьевой водой загнали грязный шланг и
    >ну в бетономешалку сосать.  Вместо того, чтоб из соседнего пруда.

    Просто суть бага до меня не доходит.Нафиг нужен девайс якобы выдающий рандом если он с этой задачей не справляется если много рандома из него брать?Или я что-то не понимаю?Depletes entropy pool звучит как-то дико.Во вселенной по-моему, энтропии на всех хватит.

    Наверное я тупой и чего-то не понимаю в этой жизни но с моей точки зрения после чтения объяснений (спасибо, Michael!) все выглядит как будто это бага была не в aMule а скорее в реализации девайса, что он при активном юзании начинает качество терять? :-\

     
     
  • 7.79, Michael Shigorin (ok), 12:33, 26/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Нафиг нужен девайс якобы выдающий рандом если он с этой задачей не справляется
    >если много рандома из него брать?Или я что-то не понимаю?

    Да Вы, батенька, развращены тем, что если цифра -- так всё можно ;-)

    >Depletes entropy pool звучит как-то дико. Во вселенной по-моему, энтропии на всех хватит.

    Из вселенной ещё добыть надо.  Поинтересуйтесь расценками на аппаратные добывалки -- водятся в местах, где положена сильная криптография.  И/или погуглите linux enthropy pool, первая страница результатов вполне релевантна.

    >как будто это бага была не в aMule а скорее в реализации
    >девайса, что он при активном юзании начинает качество терять? :-\

    Диски при активном юзании (в более чем один ламинарный поток) тоже начинают терять качество (начиная с прокачки и заканчивая сроком службы)...

    Это /dev/zero и /dev/null у нас простые, если перефразировать.

     
     
  • 8.86, User294 (ok), 10:57, 01/09/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Уй А что, какой-нибудь там тепловой шум оцифровать - не прокатывает Или как всег... текст свёрнут, показать
     
     
  • 9.87, Michael Shigorin (ok), 00:44, 03/09/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Дык это ж Сертифицированная Область, соответственно тама Сертифицированные Решен... текст свёрнут, показать
     
  • 4.62, Дмитрий Ю. Карпов (?), 15:11, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > Шарящие в криптографии, видимо плохо шарили в программинге, если в качестве источника энтропии использовали неинициализированный блок памяти. Насколько случайные там окажутся данные - не знает никто.

    IMHO, использовать неинициализированные данные из необнулённых страниц можно только в качестве ДОПОЛНЕНИЯ к другим источникам энтропии. Надо взять системное время (желательно в тактах процессора - чем подробнее, тем лучше), температуру процессора (чем больше цифр после точки - тем лучше, и неважно, насколько точно число отражает реальную температуру), кусок неинициализированных данных, значения системных счётчиков; всё это слить в одну строкУ и взять от неё hash.

     
     
  • 5.64, www2 (??), 15:52, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >IMHO, использовать неинициализированные данные из необнулённых страниц можно только в качестве ДОПОЛНЕНИЯ
    >к другим источникам энтропии.

    /dev/random - быстрый источник псевдослучайных чисел,
    /dev/urandom - как раз источник случайных чисел, где все реальные источники и сваливаются в кучу и хэшируются. Поэтому я и сказал, что использовать нужно это "устройство".

    Разработчики же SSL посчитали себя параноиками, дескать "можно найти слабину в конкретной реализации /dev/urandom, и поэтому мы будем использовать неинициализированный массив".

     
     
  • 6.81, just_another_anonymous (?), 06:12, 27/08/2008 [^] [^^] [^^^] [ответить]  
  • +/

    >/dev/random - быстрый источник псевдослучайных чисел,
    >/dev/urandom - как раз источник случайных чисел, где все реальные источники и
    >сваливаются в кучу и хэшируются. Поэтому я и сказал, что использовать нужно это "устройство".

    эээ
    вообще-то всю жизнь наоборот было!

     
     
  • 7.82, www2 (??), 07:24, 27/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >
    >>/dev/random - быстрый источник псевдослучайных чисел,
    >>/dev/urandom - как раз источник случайных чисел, где все реальные источники и
    >>сваливаются в кучу и хэшируются. Поэтому я и сказал, что использовать нужно это "устройство".
    >
    >эээ
    >вообще-то всю жизнь наоборот было!

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

     
  • 4.65, Хоменко (?), 17:26, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/

    >Шарящие в криптографии, видимо плохо шарили в программинге, если в качестве источника
    >энтропии использовали неинициализированный блок памяти. Насколько случайные там окажутся данные -
    >не знает никто. Мэйнтэйнер пофиксил использование неинициализированного массива, отсюда и были
    >проблемы. Если бы программисты использовали в качестве источника энтропии /dev/urandom, этого
    >бы не произошло.

    Вот оно! Именно этого комментария я и искал!

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

    Потому как тут ящик с тройным дном может оказаться.

    Из каких соображений авторы openssh предпочли просто не проинициализировать тот массив, а не написать туда что-то на манер текущая_секунда по модулю текущая_минута (насчет доступности /dev/urandom -- а оно, кстати, есть ли на всех системах?) Ведь так же просто, издержки минимальные, и gcc ругаться не будет.

    С другой стороны, непроинициализированные переменные ловятся компиляторами с доисторических времен, и уж автор определенно знал о том массиве. Знал, но таки ж оставил!

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

    Кто действительно шарит и потрудился посмотреть в код и в дебиановский патч -- растолкуйте, действительно ли все так просто и самонадеянно там?

     
     
  • 5.67, www2 (??), 17:37, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Насколько я знаю, мэйнтейнеры Debian никогда не лезут в код своими ручками, если проект подаёт признаки жизни. Багрепорт наверняка был отправлен разработчикам OpenSSL. Есть версия, что они просто между собой посмеялись над глупостью мэйнтейнера, а ответом его не удостоили. Когда разработчики отмалчиваются, мэнтейнеры Debian стремятся фиксить баги не полагаясь на разработчиков. Примерно такая ситуация и произошла. Мэйнтейнер в меру своего понимания исправил ошибку.

    Не могу сказать со 100% уверенностью, что всё было именно так, но очень на то похоже.

     
     
  • 6.71, pavel_simple (??), 19:53, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    они (мантайнер Debian и разраб openssl) писали друг-другу письма

    потом на какой-то момент переписка (на стороне openssl) тормознулась

    мантайнер debian решил что это дествительно ошибка -- и сделал далеко идущие выводы

    разраб openssl подумал что никакой ошибки в коде нет -- но забыл сказать это мантайнеру debian

    коротко -- "Я тебя не понимать" (C) Народная Мудрось

     
  • 6.77, Michael Shigorin (ok), 12:21, 26/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Насколько я знаю, мэйнтейнеры Debian никогда не лезут в код своими ручками,
    >если проект подаёт признаки жизни.

    Ещё как лезут -- жизнь такая.

    PS: вообще этот вопрос довольно подробно разбирался тогда, когда был актуален:
    https://www.opennet.ru/opennews/art.shtml?num=15846
    https://www.opennet.ru/opennews/art.shtml?num=15862
    https://www.opennet.ru/opennews/art.shtml?num=16523

     

  • 1.46, Vulzscht (?), 01:18, 24/08/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а вы уверены что RH так вам и выложила всю правду?
    нюню...
     
     
  • 2.54, User294 (ok), 03:28, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >а вы уверены что RH так вам и выложила всю правду?
    >нюню...

    Да к парированию проблемы трудно придраться, редхат вроде грамотно парировал проблемы.А вот теперь бы понять насколько это грозит не редхатовским системам...

     

  • 1.56, Гость (?), 05:33, 25/08/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    в новости сказано, что репозиторий CentOS не пострадал, так с чего бы он мне обновления openssh предлагает?


     
     
  • 2.75, User294 (??), 21:51, 25/08/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >в новости сказано, что репозиторий CentOS не пострадал, так с чего бы
    >он мне обновления openssh предлагает?

    Вариантов я вижу 2 - или они обновили ssh с подачи редхата или хакеры решили что теперь пора всыпать вон тем :).Вот на такие случаи и хотелось бы иметь описание того что за троянец был и что делал и вообще, чем характерен и как отловить.

     

  • 1.76, Аноним (10), 12:16, 26/08/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что касается обновления OpenSSH для CentOS, то обновлении мне приходила новость из оффициального листа рассылки по апдейтам CentOS.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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