The OpenNET Project / Index page

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

Релиз OpenSSH 9.8 с отключением алгоритма DSA и дополнительными механизмами защиты

01.07.2024 15:03

Опубликован релиз OpenSSH 9.8, открытой реализации клиента и сервера для работы по протоколам SSH 2.0 и SFTP. Помимо устранения отдельно анонсированной критической уязвимости (CVE-2024-6387), позволяющей добиться удалённого выполнения кода с правами root на стадии до прохождения аутентификации, в новой версии исправлена ещё одна менее опасная уязвимость и предложено несколько существенных изменений, нацеленных на повышение безопасности.

Вторая уязвимость позволяет обойти добавленную в версии OpenSSH 9.5 защиту от атак по сторонним каналам, анализирующим задержки между нажатиями клавиш на клавиатуре для воссоздания ввода. Уязвимость позволяет отличить пакеты, создающие фоновую активность через симуляцию фиктивных нажатий клавиш, от пакетов, отправляемых при нажатии реальных клавиш, что снижает эффективность механизма скрытия особенностей интерактивного ввода в трафике в ssh. Данные о нажатиях позволяют использовать атаки, воссоздающие ввод на основе анализа задержек между нажатиями при наборе текста, которые зависят от расположения клавиш на клавиатуре (например, реакция при вводе буквы "F" быстрее, чем при вводе "Q" или "X", так как для нажатия требуется меньше движений пальцев).

Кроме того, выяснилось, что реализованный алгоритм отправки пакетов с реальными и фиктивными нажатиями снижал надёжность другого метода защиты от атак по сторонним каналам. Начиная с выпуска OpenSSH 2.9.9 сервер отправлял пакеты с фиктивными нажатиями для консольного ввода в режиме echo-off, используемом, например, при вводе паролей в su или sudo. Новая логика отправки фиктивных пакетов позволяла при пассивном анализе трафика выделять пакеты с реальными нажатиями в режиме echo-off для их отдельного анализа. При этом точность сведений о времени нажатий ограничивается, так как после набора пакеты отправляются не сразу, а через фиксированные промежутки времени (по умолчанию 20 мс).

Другие изменения в OpenSSH 9.8:

  • На этапе сборки отключена по умолчанию поддержка цифровых подписей на базе алгоритма DSA. В начале 2025 года реализация DSA будет удалена из кодовой базы. В качестве причины удаления называется не соответствующий современным требованиям уровень защиты в DSA. Затраты на продолжение сопровождения небезопасного алгоритма DSA не оправдывают себя и его удаление позволит стимулировать прекращение поддержки DSA в других реализациях SSH и криптографических библиотеках.
  • Для дополнительной защиты от методов эксплуатации уязвимостей, требующих установки большого числа соединений к sshd, реализован и включён по умолчанию новый режим защиты, который также помогает для блокирования автоматизированных атак по подбору паролей, в ходе которых боты пытаются угадать пароль пользователя, перебирая различные типовые комбинации. Защита реализована через блокировку IP-адресов, c которых фиксируется большое число неудачных попыток соединений - sshd отслеживает статус завершения дочерних процессов, определяя ситуации когда не прошла аутентификация или когда процесс был аварийно завершён из-за сбоя, и при превышении определённого порога начинает блокировать запросы с проблемных IP или подсетей. Для настройки порога срабатывания блокировки, маски блокируемой подсети и списка исключений предложены параметры PerSourcePenalties, PerSourceNetBlockSize и PerSourcePenaltyExemptList.
  • Осуществлено разделение sshd на несколько отдельных исполняемых файлов. Из sshd выделен процесс sshd-session, выполняющий задачи, связанные с обработкой сеансов. В процессе sshd оставлены функции, отвечающие за приём сетевых соединений, проверку конфигурации, загрузку хостовых ключей и управление запускаемыми процессами в соответствии с параметром MaxStartups. Таким образом исполняемый файл sshd теперь содержит минимальную функциональность, необходимую для приёма нового сетевого соединения и запуска sshd-session для обработки сеанса.
  • Изменился текст некоторых сообщений об ошибках, записываемых в лог. В частности, ряд сообщений теперь отправляется от имени процесса "sshd-session", а не "sshd".
  • В утилите ssh-keyscan вывод информации о версии протокола и имени хоста теперь выводится в стандартный поток, а не в STDERR. Для отключения вывода предложена опция "-q".
  • В ssh реализована возможность отключения через директиву HostkeyAlgorithms отката от использования сертификата хостового ключа к использованию простых (plain) хостовых ключей.
  • В переносимой версии sshd прекращено использование значения argv[0] для определения имени сервиса PAM. Для задания имени сервиса PAM в sshd_config добавлена новая директива "PAMServiceName", которая по умолчанию выставлена в значение "sshd".
  • В переносимой версии sshd обеспечено сохранение автоматически генерируемых файлов (скрипт configure, config.h.in и т.п.) в ветке Git с релизами (например, V_9_8), что позволило синхронизировать состав заверенных цифровой подписью tar-архивов и веток в Git.
  • В переносимой версии ssh и ssh-agent обеспечено выставление режима SSH_ASKPASS при наличии переменной окружения WAYLAND_DISPLAY, по аналогии с тем как для X11 это делалось при наличии переменной окружения DISPLAY.
  • В переносимой версии sshd добавлена поддержка отправки в systemd уведомлений при создании слушающего сетевого сокета или перезапуске, используя обособленный код, не обращающийся к библиотеке libsystemd.


  1. Главная ссылка к новости (https://lists.mindrot.org/pipe...)
  2. OpenNews: Уязвимость в OpenSSH, позволяющая удалённо выполнить код с правами root на серверах с Glibc
  3. OpenNews: В OpenSSH добавлена встроенная защита от атак по подбору паролей
  4. OpenNews: Проект OpenSSH разделяет sshd на несколько исполняемых файлов
  5. OpenNews: Релиз OpenSSH 9.7
  6. OpenNews: Проект OpenSSH опубликовал план прекращения поддержки DSA
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/61473-openssh
Ключевые слова: openssh
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (49) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Аноним (2), 19:44, 01/07/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    И как таперь к старым linux'ам подключаться?
     
     
  • 2.3, Аноним (3), 20:05, 01/07/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я, видимо, пропустил, а где пишут, что старые линуксы не будут работать? И что подразумевается под старостью?
     
  • 2.4, hshhhhh (ok), 20:39, 01/07/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    даже к старым линуксам могут подключаться одновременно несколько человек. не жадничайте!
     
  • 2.6, Аноним (6), 20:54, 01/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    По telnet
     
  • 2.7, Омнонном (?), 01:08, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А как сейчас подключаетесь?
     
  • 2.16, Соль земли (?), 09:59, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Используя SHA-1, потому что других алгосов там нет, и старые версии не отличают шифрование ключа от алгоса подписи ключа.
     
  • 2.32, Аноним (-), 06:00, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > И как таперь к старым linux'ам подключаться?

    Используя такой же старый linux :)

     

  • 1.8, Алкоголизм (?), 03:51, 02/07/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А зачем в принципе передавать именно нажатия при авторизации? Разве не проще собрать строку пароля на стороне клиента и попросту отправить её целиком? Либо, раз уж такая особенность протокола и парольной авторизации, то опять же набирать в буфер и передавать пачкой все нажатия, как какой-нибудь парольный менеждер. Разве остались ситуации, где требуется такой контроль ввода? Даже если подключить OTP, то это всё равно отправка другой такой же строки в большинстве случаев.
     
     
  • 2.11, Аноним (11), 06:47, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что помимо ввода пароля существует обычная работа с консолью. А там удобнее чтобы работало как с обычным терминалом чем присылался текст и не известно как целевая машина будет работать с этим текстом. А тут если сказали ентер значит ентер, а не текст "нажат ентер". Но злые языки конечно знают что первичной целью был конечно же фингерпринтинг.
     
     
  • 3.12, Ананим.orig (?), 08:01, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ввод пароля происходит явно ДО открытия сессии, т.е. это уж точно не "обычная" работа с консолью.
     
     
  • 4.13, ананим.orig (?), 08:05, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И это не говоря о том, что все время думал что по сети летит хэш, а не сам пароль
     
     
  • 5.14, anonistrambler.ru (?), 09:39, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Зачем хэш, это же закрытыи канал?
     
     
  • 6.20, ананим.orig (?), 12:50, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем слать пароль, если сравнивать все равно будет с хэшем из shadow/..?
    Плюс это практика проверенная десятилетиями
     
     
  • 7.21, ананим.orig (?), 13:27, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    моя неправда:
    согласно rfc https://datatracker.ietf.org/doc/html/rfc4252#section-8
    вполне может быть и plaintext
    с предварительной конвертацией и нормализацией при необходимости.
    > Note that the 'plaintext password' value is encoded in ISO-10646 UTF-8.

    в любом случае все это (логин, пароль) уходит одним пакетом, а не по нажатию каждой клавиши (с таймаутaми)
    т.е. никакого «передавать именно нажатия при авторизации» не происходит — с чего ветка обсуждения и началась

     
  • 5.22, _oleg_ (ok), 13:28, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Какой хэш? В зависимости от настроек pam на принимающей стороне может быть различный способ проверки пароля. /etc/shadow, ldap, свой велосипед и т.д.
     
     
  • 6.31, ананим.orig (?), 05:27, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    1. метод хеширования хранится вместе с хэшем в самом его начале, так называемый prefix (man 5 crypt).
    Формат примерно такой - $y$…………:
    $1$: MD5, $5$: SHA-256, $6$: SHA-512 sha512crypt, $gy$: gost-yescrypt, $y$: yescrypt

    В современных бэкэндах (/etc/shadow, ldap, samba) хэши сохраняются именно в таком формате.
    Хранение самого пароля в планарном виде считается моветоном.

    2. Так что передавать по сети сам пароль нет необходимости, достаточно договорится о методе хэширования (что обычно и происходит)
    3. И да, в ssh может(!) передаваться логин/пароль открыто , о чем я и написал выше в #21.
    Но  это не имеет отношения к тому что обсуждали, потому что все равно идет одним пакетом, а не пакет на каждое нажатие клавиши

     
     
  • 7.37, _oleg_ (ok), 11:48, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > 1. метод хеширования хранится вместе с хэшем в самом его начале, так
    > называемый prefix (man 5 crypt).
    > Формат примерно такой - $y$…………:
    > $1$: MD5, $5$: SHA-256, $6$: SHA-512 sha512crypt, $gy$: gost-yescrypt, $y$: yescrypt

      Это просто id хэша, далее там ещё salt идёт. Но это здесь не важно. Потому как это справедливо только для shadow и т.п.

    > …
    > В современных бэкэндах (/etc/shadow, ldap, samba) хэши сохраняются именно в таком формате.

    А в ldap и mysql хранится так, как захочет соответсвующая pam-либа. Там другой формат может быть.

    > Хранение самого пароля в планарном виде считается моветоном.

    Что такое "планарный вид"? Чистый вид? Никто и не говорит про хранение в таком виде. Речь идёт про передачу внутри защищённого канала во время аутентификации.

    > 2. Так что передавать по сети сам пароль нет необходимости, достаточно договорится
    > о методе хэширования (что обычно и происходит)

      Не всегда. Есть всякие сложные схемы аутентификации (читай про gssapi и kerberos). И насколько я знаю, ничего такого при передаче пароля не происходит - он идёт чистым по зашифрованному каналу. По крайне мере раньше так было. И это адекватно. Потому как, если я захочу использвать у себя какой-нибудь распоследний blake3 для хранения хэшей паролей, а на машине с ssh-клиентом этого нет, то всё что ли? Финита ля комедия. Зайти не сможем.

     
     
  • 8.40, ананим.orig (?), 16:53, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    разумеется вы можете использовать все что угодно, хоть свой pam-модуль написать ... текст свёрнут, показать
     
     
  • 9.41, _oleg_ (ok), 17:27, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Он это давно поддерживает - Вряд ли найдётся много современных установок sshd... текст свёрнут, показать
     
     
  • 10.42, ананим.orig (?), 01:26, 04/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    нет про передачу нажатия клавиш остальное - переливание из пустого в порожнее ... текст свёрнут, показать
     
     
  • 11.43, _oleg_ (ok), 14:01, 04/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Значит показалось и это А зачем слать пароль, если сравнивать все равно будет ... текст свёрнут, показать
     
  • 2.53, solardiz (ok), 16:23, 10/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Речь о паролях, передаваемых внутри сессии, "например, при вводе паролей в su или sudo." А при парольной аутентификации в самом SSH, да, обычно (кроме редко используемого режима keyboard-interactive) пароль передается одной строкой. С этим тоже когда-то была уязвимость - можно было определить длину пароля, см. https://www.openwall.com/articles/SSH-Traffic-Analysis
     

  • 1.10, Аноним (11), 06:42, 02/07/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А чего в эту тему не написали ссылку про связи опенбзд с ФБР? https://www.opennet.dev/opennews/art.shtml?num=28998
     
     
  • 2.52, Аноним (52), 23:47, 08/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    2010? Вовремя откопали.
     

  • 1.17, Соль земли (?), 10:09, 02/07/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вынести бы ещё весь функционал в библиотеку, чтобы отпала необходимость в libssh/libssh2.
     
  • 1.23, _oleg_ (ok), 13:30, 02/07/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Вот красавцы. Как к старым коммутаторам подключаться-то? Как они задолбали уже со своей псевдозаботой о моей безопасности. Ну выводите вы предупреждение при использовании dsa, но убирать совсем - идиоты.
     
     
  • 2.25, Аноним (-), 15:46, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вот красавцы. Как к старым коммутаторам подключаться-то? Как они задолбали уже со
    > своей псевдозаботой о моей безопасности. Ну выводите вы предупреждение при использовании
    > dsa, но убирать совсем - идиоты.

    Так подключайся к старым коммутаторм старой версией либы.
    Они же не удалили предыдущие версии.
    А то тебе послушать - сидели бы до сих пор на первопне

     
     
  • 3.26, _oleg_ (ok), 17:03, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> Вот красавцы. Как к старым коммутаторам подключаться-то? Как они задолбали уже со
    >> своей псевдозаботой о моей безопасности. Ну выводите вы предупреждение при использовании
    >> dsa, но убирать совсем - идиоты.
    > Так подключайся к старым коммутаторм старой версией либы.
    > Они же не удалили предыдущие версии.
    > А то тебе послушать - сидели бы до сих пор на первопне

    Да ты ж моё золото. А где взять эту старую версию на новом дистре?

     
     
  • 4.27, Аноним (27), 20:48, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ./configure
    make
     
     
  • 5.34, _oleg_ (ok), 11:07, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > ./configure
    > make

    Ну я почему-то другого и не ожидал. Спасибо, не надо.

     
     
  • 6.38, Аноним (27), 13:00, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, я, помню, какое-то время поддерживал ppa для openssl+alpn+nginx - пока не подошел EOL для дистрибутивов, где это было актуально. Можете точно так же поддерживать пакеты для своего любимого дистрибутива.

    А если по простому, то не вижу проблем, если make install в какой-нибудь /opt.

     
     
  • 7.39, _oleg_ (ok), 13:23, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ну, я, помню, какое-то время поддерживал ppa для openssl+alpn+nginx - пока не
    > подошел EOL для дистрибутивов, где это было актуально. Можете точно так
    > же поддерживать пакеты для своего любимого дистрибутива.
    > А если по простому, то не вижу проблем, если make install в
    > какой-нибудь /opt.

    Я уже понял, что не видишь. А они есть, между тем. Буквально через пару новых версий gcc/glibc/anylib старые проекты перестают собираться и их приходится править самому и это не всегда тривиально. У меня достаточно плясок с ./configure && make install на разных машинах по различным причинам на регулярной основе и так. Ещё +1 к этому списку никакого желания получать нет.

     
  • 4.28, Роман (??), 21:19, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    у системного администратора
     
  • 4.30, Аноним (-), 21:32, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Да ты ж моё золото. А где взять эту старую версию на новом дистре?

    Возьми старый дистр. Заодно как раз разломают и тебя и коммутатор чтобы 2 раза не вставать.

     
     
  • 5.36, _oleg_ (ok), 11:13, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Возьми старый дистр. Заодно как раз разломают и тебя и коммутатор чтобы
    > 2 раза не вставать.

    Какой старый? Куда я тебе его поставлю? Как на новые тогда ходить коммутаторы? Как их сломают через ssh, когда управление через отдельный vlan?

     
     
  • 6.45, Аноним (45), 01:47, 05/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Какой старый?

    Любой, по вкусу.

    > Куда я тебе его поставлю?

    Да куда угодно. На правах кэпа: на виртуалку!

    > Как на новые тогда ходить коммутаторы?

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

    > Как их сломают через ssh, когда управление через отдельный vlan?

    Вы так железно уверены что у вас там в вашем уютном интранетикеводится? Судя по тупым вопросам это напрасная уверенность.

     
     
  • 7.46, _oleg_ (ok), 13:13, 05/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы так железно уверены что у вас там в вашем уютном интранетикеводится?
    > Судя по тупым вопросам это напрасная уверенность.

    Судя по тому, что ты пишешь, тупой здесь только ты. Уверены, не уверены - что ты за чушь пишешь? Какие нахрен ВМ? Один ./configure && make предлагает, другой тьму ВМ городить, между которыми потом бегать, что бы найти ту, которая нужна для конкретного коммутатора. Что за бред? Вы, вообще, сами хоть раз что-то подобное делали с поддержкой этого самого в несколько лет хотя бы? Ты хоть понимаешь, что это гемор? А учитывая, что о том, что ты уже не можешь попасть на коммутатор ты узнаёшь когда на него надо срочно зайти, это вообще пипец. Ты понимаешь, что ты пишешь чушь? Ты серьёзно предполагаешь, что у провайдера больше проблем/дел нет, как играться с установкой и поддержкой разных версий ssh? Откуда вы такие вылупляетесь, вообще...

     
     
  • 8.48, glad_valakas (-), 09:55, 06/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    наймите кого-нибудь кто умеет 7000 руб час норм оплата ... текст свёрнут, показать
     
  • 8.51, Sem (??), 00:41, 07/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Оставь одну старую версию Сделай тунель куда тебе надо, ходи через него С ВМ, ... текст свёрнут, показать
     
  • 8.54, Аноним (-), 17:05, 10/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А в чем проблема У нормальных админов это streamlined, вкатить нужное дистро на... большой текст свёрнут, показать
     
     
  • 9.55, _oleg_ (ok), 17:19, 10/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ох Даже не знаю смеяться или плакать Я об этом и писал, что бегать между ВМ ... текст свёрнут, показать
     
  • 9.56, _oleg_ (ok), 17:26, 10/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вот тебе это писать-то не лень было Ты так и не понял о чём речь даже Ты поним... текст свёрнут, показать
     
  • 2.44, r1 (?), 19:06, 04/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Давить вендора чтоб обновил софт коммутатора.
     
     
  • 3.47, _oleg_ (ok), 13:18, 05/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Давить вендора чтоб обновил софт коммутатора.

    Да это только в теории работает. Если баги в старых моделях фиксят, то уже спасибо. А какой-то там ssh, не влияющий на основную работу железки - забьют. Мы уже, в принципе, идём потихоньку к тому, что бы ходить на коммутаторы через telnet. Учитывая, что управлящий vlan огорожен от всего остального, это адекватный выход. Потому как ~/.ssh/config с исключениями для шифров по ip ширится от года к году.

     
  • 2.49, mausglov (?), 12:33, 06/07/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сделайте Docker контейнер со старым Линуксом для этой цели, делов-то...
     
  • 2.50, anonymous (??), 15:25, 06/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Хакеры и солонки
     

  • 1.24, Аноним (24), 14:23, 02/07/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Данные о нажатиях позволяют

    снимать биометрию пользователя.

     
  • 1.29, Роман (??), 21:21, 02/07/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Таким образом исполняемый файл sshd теперь содержит минимальную функциональность, необходимую для приёма нового сетевого соединения и запуска sshd-session для обработки сеанса.

    Выглядит как можно заменить на socket activation unit [в системд] над sshd-session, такая же минимальная функциональность. Кто специалист, подскажите, чем отличается?

     
     
  • 2.33, Аноним (-), 06:03, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Выглядит как можно заменить на socket activation unit [в системд] над sshd-session,
    > такая же минимальная функциональность. Кто специалист, подскажите, чем отличается?

    В опенбсде его нету - так что нате вам с лопаты вон те чудеса вместо этого.

     

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



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

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