The OpenNET Project / Index page

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

Root-уязвимость из-за некорректных настроек в пакете nginx для Debian и Ubuntu

17.11.2016 20:03

Опубликованы подробности и эксплоит для уязвимости (CVE-2016-1247) в пакете с nginx, в конце октября устранённой в Debian и Ubuntu. Проблема специфична для deb-пакета nginx, не касается самого nginx, и может привести к выполнению кода с правами root при наличии у атакующего прав доступа "www-data" в системе.

Проблема вызвана некорректными настройками доступа к директории с логами web-сервера. Директория с логами /var/log/nginx имеет владельца "www-data", что позволяет пользователю с данными полномочиями произвольно манипулировать файлами в данной директории. При запуске или перезапуске nginx в лог добавляются записи от процесса с правами root. Периодически скрипт ротации логов меняет владельца файлов с логами на "www-data".

Локальный пользователь с правами www-data может создать в директории /var/log/nginx символическую ссылку вместо файла с логом "error.log". Таким образом, направив символическую ссылку "/var/log/nginx/error.log" на другой файл перед перезапуском nginx, можно изменить любой файл в системе. Перезапуск nginx по сигналу USR1 осуществляется скриптом ротации логов, который по умолчанию вызывается из cron.daily каждый день в 6:25.

Для организации запуска кода с правами root в эксплоите осуществляется создание символической ссылки на файл /etc/ld.so.preload (/var/log/nginx/error.log -> /etc/ld.so.preload), который после перезапуска nginx будет создан, а после ротации лога получит владельца www-data, что позволит прописать в нём произвольную библиотеку атакующего, после чего библиотека будет активироваться при выполнении любого исполняемого файла, например, можно запустить suid root приложение /usr/bin/sudo.



  1. Главная ссылка к новости (http://openwall.com/lists/oss-...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/45515-nginx
Ключевые слова: nginx, debian
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (66) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Аноним (-), 21:12, 17/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –29 +/
    >ротация логов

    Камон, сириусли? Зачем их хранить? Линковать на /dev/null, и все дела.

     
     
  • 2.4, user455 (?), 21:13, 17/11/2016 [^] [^^] [^^^] [ответить]  
  • +55 +/
    администратор локалхоста в чяте.
     
     
  • 3.11, тоже Аноним (ok), 22:53, 17/11/2016 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Перефразируя известный афоризм: есть администраторы, которые еще не хранят логи...
     
     
  • 4.24, Аноним (-), 01:37, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    некоторые гоняют при помощи syslog
     
     
  • 5.31, Адекват (ok), 08:11, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > некоторые гоняют при помощи syslog

    syslog появился до вашего рождения и всех всем устраивал столько лет, сколько вам еще нет.

     
     
  • 6.45, Аноним (-), 17:12, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Во-первых, отучайся говорить за всех. Это плохая привычка.

    Во-вторых, если бы syslog всех всем устраивал, что не появилось бы пачка альтернатив.

    В-третьих, syslog совершенно не устраивает многих админов в хайлоаде, например Сысоева. Сам нагуглить осилишь, почему он столько времени не хотел добавлять поддержку syslog в nginx?

     
     
  • 7.65, XoRe (ok), 20:31, 21/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В-третьих, syslog совершенно не устраивает многих админов в хайлоаде, например Сысоева.
    > Сам нагуглить осилишь, почему он столько времени не хотел добавлять поддержку
    > syslog в nginx?

    Syslog - это понятие, обобщающее клиента, протокол и сервер.
    Насколько я понял, Сысоева не устраивал протокол syslog из за возможной потери пакетов и загрузка syslog сервера (syslogd): http://www.lexa.ru/nginx-ru/msg17262.html
    > Я тут имел несчастье наблюдать 130 сообщений в секунду через syslogd.
    > Машинка, конечно, не первой мододости, 2x P3-700, но отжирать при этом 12%
    > процессора только на чтение и запись сообщения - это слишком.

    Ну, во первых, с тех пор компьютеры стали чуть мощнее.
    Во вторых syslogd - не тот инструмент, которым надо ловить логи веб сервера.
    Тогда хотя бы можно было использовать syslog-ng.
    А сейчас для этого есть отличные связки вида Logstash+ElasticSearch+Kibana, или Statsd+Graphite, которые отлично обрабатывают 10k rps.
    Ну и на хайлоаде потеря пары пакетов не страшна, когда у тебя нагрузка 1к rps.

    Так что syslog на хайлоаде - вещь хорошая, только её нужно правильно приготовить.
    Отправка логов по сети помогает разгрузить сервер - ему не нужно тратиться на дисковый I/O.

     

  • 1.3, Аноним (-), 21:12, 17/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Опять дебиан отличился :) сначала OpenSSL, теперь ngnix...
     
     
  • 2.5, Crazy Alex (ok), 21:35, 17/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Тоже мне, сравнил.
     
     
  • 3.6, Аноним (-), 22:06, 17/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а что не так? и то и другое от кривых рук маинтейнера пакета. И учитывая распространенность дебиана - можно поспорить что уже ботнет поднялся..
     
     
  • 4.8, Crazy Alex (ok), 22:41, 17/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Угу, ботнет от локальной уязвимости. Которую ты от ремотной, судя по всему, не отличаешь. Хотя даже там, насколько я знаю, ботнет не поднялся. Здесь же - не ssh, который есть вообще на любом сервере, а нгинкс, который может быть, а может и не быть.
     
     
  • 5.12, тоже Аноним (ok), 22:56, 17/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну, на шаред-хостингах нгинкс обычно не может не быть - ради ускорения его непременно ставят перед тем, на чем крутятся клиентские сайты. Правда, при этом вход от имени www-data (пользователя, от имени которого работает nginx) по ssh может быть вовсе заблокирован. А что там себе наваляют в домашних папочках пользователи - будет проигнорировано.
     
     
  • 6.19, Sw00p aka Jerom (?), 23:57, 17/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    думаю не опасно, если nginx и пхп на разных вирт серверах.
     
  • 6.20, Sw00p aka Jerom (?), 23:59, 17/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > по ssh может быть вовсе заблокирован.

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


     
  • 6.21, Аноним (-), 00:09, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    По умолчанию под пользователем www-data выполняются, например, php-скрипты.
     
     
  • 7.22, тоже Аноним (ok), 00:19, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    На шаредах php-скрипты выполняются от имени юзеров.
    А nginx, как я это понимаю - от имени пользователя, которому шелл вообще не требуется.
     
     
  • 8.27, Sw00p aka Jerom (?), 03:09, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    ну и пхп не требуется, но это же не мешает выполнять system ,exec ,passthru ... текст свёрнут, показать
     
     
  • 9.32, тоже Аноним (ok), 08:16, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Удаленно зайти и выполнить описанные в статье действия - мешает ... текст свёрнут, показать
     
     
  • 10.36, Онанимус (?), 10:58, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Вам же объясняют любой локальный рут - это возможность поднятия ранее полученно... текст свёрнут, показать
     
     
  • 11.37, тоже Аноним (ok), 11:08, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Не понимаю - зачем нужна обсуждаемая уязвимость, если уже получен локальный рут ... текст свёрнут, показать
     
     
  • 12.39, Онанимус (?), 11:30, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Издеваетесь что ли Если хэккер получил удаленного www-data, то его возможности ... текст свёрнут, показать
     
     
  • 13.40, тоже Аноним (ok), 12:40, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Конкретно эта ветка и начинается с моего утверждения, что на шаредах пользовател... текст свёрнут, показать
     
  • 10.43, Sw00p aka Jerom (?), 15:45, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    на видео видно как автор через якобы багу загружает на сервер реверсивный пхп ше... текст свёрнут, показать
     
     
  • 11.44, тоже Аноним (ok), 16:26, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Еще раз если даже вы получили шелл с правами юзера шаред-хостинга - конкретно э... текст свёрнут, показать
     
     
  • 12.48, Sw00p aka Jerom (?), 23:44, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    я чёт не понял смысла вашего предложения Конкретно эксплоит выполнится, если у ... текст свёрнут, показать
     
     
  • 13.50, тоже Аноним (ok), 00:15, 19/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А юзеры на шареде - это не тот пользователь www-data, от имени которого запускае... текст свёрнут, показать
     
  • 6.56, Аноним (-), 05:54, 19/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну, на шаред-хостингах нгинкс обычно не может не быть

    Если у кого shared хостинг и логи нжинкса доступны всем подряд - как минимум это уже vuln поскольку атакующий может проводить наглейший data mining на ресурсах которые ему вообще не принадлежат, изучая чужих посетителей.

    Более того - если атакующий может что-то менять под www-data он скорее всего может раздестроить к чертям все сайты и например редиректнуть всю толпу на свой сайт, допустим с малварью или какой там еще фэйковой формой логина гмыл/втентакля/кого там еще по вкусу.

     
     
  • 7.58, тоже Аноним (ok), 12:43, 19/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Поэтому?..
     
  • 5.33, тигар (ok), 09:13, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Угу, ботнет от локальной уязвимости. Которую ты от ремотной, судя по всему,
    > не отличаешь. Хотя даже там, насколько я знаю, ботнет не поднялся.
    > Здесь же - не ssh, который есть вообще на любом сервере,
    > а нгинкс, который может быть, а может и не быть.

    а конфиг iptables/sshd нельзя поправить/заменить своим на время, используя эту дыру?

     
     
  • 6.38, Онанимус (?), 11:13, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > а конфиг iptables/sshd нельзя поправить/заменить своим на время, используя эту дыру?

    Зачем? Если есть возможность добраться до этой дыры, то надо ставить реверс шелл. Ибо, насколько я понимаю, в файл, на который Вы сделаете ссылку, nginx будет гадить логами.

    ЗЫ: напомните, что за "конфиг iptables"?

     
     
  • 7.49, Sw00p aka Jerom (?), 23:46, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > nginx будет гадить логами.

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

     
     
  • 8.51, angra (ok), 01:05, 19/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Походу, ты вообще не понял, как работает эта уязвимость Дело не в logrotate, а ... текст свёрнут, показать
     
  • 4.26, Аноним (-), 02:30, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > и то и другое от кривых рук маинтейнера пакета.

    Ну не совсем, изменение в OpenSSL одобрили сами авторы.

     
  • 2.10, Вареник (?), 22:42, 17/11/2016 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Каким боком Debian к сборке ngnix под DEB?
     
     
  • 3.17, Michael Shigorin (ok), 23:40, 17/11/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Каким боком Debian к сборке ngnix под DEB?

    Угадайте с двух, нет, с трёх попыток.  Третья -- на прочтение DSA-3701.

     

  • 1.13, odd.mean (ok), 22:59, 17/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Казалось бы, что мешает использовать
    deb http://nginx.org/packages/debian/ CODENAME nginx
    или
    deb http://nginx.org/packages/mainline/debian/ CODENAME nginx
    ?
    Хотя мэйнтэйнерам, конечно, двойка.
     
     
  • 2.59, Savely Krasovsky (?), 01:01, 20/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    В случае в дебианом там статично слинкована старая OpenSSL 1.0.1, которая не поддерживает ALPN для HTTP/2. Так что приходится собирать из исходников.
     
     
  • 3.62, odd.mean (ok), 21:16, 20/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А вы на какой ветке (ветках)?
     

  • 1.18, ALex_hha (ok), 23:52, 17/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Опять дебиан отличился :) сначала OpenSSL, теперь ngnix..

    еще стоит вспомнить exim в их исполнении ;)

     
     
  • 2.25, Аноним (-), 02:03, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    exim стоит вспомнить безотносительно дебиана. Хотя что с его конфигаме делают в дебиане - это какой-то бесконечный ужас.
     
  • 2.35, rt (??), 10:57, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это же самый стабильно-серверный дистрибутив. История с openssh туда же)
     

  • 1.23, Аноним (-), 00:34, 18/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Сила мелочей, классный эффект. Не по теме а почему черепашка а не обезьяна с гранатой :D
     
  • 1.28, Аноним (-), 07:15, 18/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    А почему проблему видят в дебиане, а не в работе nginx с файлами логов? При получении сигнала USR1 он переоткрывает логи, создавая описанную проблему с симлинками. То есть единственное, в чем виноваты некоторые(к примеру в wheezy это не так) из debian дистров, так в том, что /var/log/nginx имеет владельца www-data. Однако ведь точно такая же проблема возникнет, если админ скажет nginx класть логи для виртуалхостов непосредственно в их каталоги, что весьма удобно и никаких предупреждений на этот счет в доке nginx нет.
     
     
  • 2.46, Аноним (-), 20:21, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Проблемы debian разработчиков nginx не колышат, это только их проблемы - мы лучше будем контрибутить FreeBSD и Ubuntu с RHEL и SUSE
     
     
  • 3.52, angra (ok), 01:09, 19/11/2016 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Для танкистов повторяю, проблема не в debian, а в способе работы с логами в nginx. И проявится это может в любом другом дистре.
     
     
  • 4.54, Аноним (-), 01:48, 19/11/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Из за ваших детских болезней костыли в софт никто добавлять не собирается, если майнтейнер малолетнее ……
     

  • 1.29, Аноним (-), 07:41, 18/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Получается, другие каталоги в /var/log с не-root владельцем тоже потенциально уязвимы...
     
     
  • 2.30, angra (ok), 08:06, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Зависит от того, как программа обрабатывает симлинки. В данном случае nginx создает файл, следуя по симлинке, и меняет ему владельца на своего пользователя. Но не весь софт так делает.
    Проблема не ограничивается /var/log/*
     

  • 1.34, Loly (?), 10:53, 18/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Red Hat говорит что не проблема:

    https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-1247
    Red Hat Product Security has rated this issue as having Low security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.

     
     
  • 2.41, анонимус вульгарис (?), 13:41, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И после этого ещё катят бочку на Debian, где дыру сразу закрыли.
     
  • 2.42, Stax (ok), 14:47, 18/11/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В редхат nginx не поставку входит, если что. Только в epel. Это несколько другой уровень ответственности.

    А низкий приоритет потому, что selinux из коробки от этой уязвимости защищает.

     
     
  • 3.53, angra (ok), 01:24, 19/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Точно защищает? Проверял? А вот я взял образ centos 6 и проверил

    [root@Falcon /]# cd /var/log/nginx/
    [root@Falcon nginx]# ls -al
    total 8
    drwx------ 2 nginx nginx 4096 Nov 18 17:18 .
    drwxr-xr-x 3 root  root  4096 Nov 18 17:18 ..
    -rw-r--r-- 1 root  root     0 Nov 18 17:18 access.log
    -rw-r--r-- 1 root  root     0 Nov 18 17:18 error.log
    [root@Falcon nginx]# rm access.log
    rm: remove regular empty file 'access.log'? y
    [root@Falcon nginx]# ln -s /etc/test access.log
    [root@Falcon nginx]# kill -USR1 734
    [root@Falcon nginx]# ls -al
    total 8
    drwx------ 2 nginx nginx 4096 Nov 18 17:20 .
    drwxr-xr-x 3 root  root  4096 Nov 18 17:18 ..
    lrwxrwxrwx 1 root  root     9 Nov 18 17:20 access.log -> /etc/test
    -rw-r--r-- 1 nginx root     0 Nov 18 17:18 error.log
    [root@Falcon nginx]# ls -al /etc/test
    -rw-r--r-- 1 nginx root 0 Nov 18 17:21 /etc/test
    [root@Falcon nginx]# cat /etc/issue
    CentOS release 6.8 (Final)
    Kernel \r on an \m

     
     
  • 4.55, пет (?), 01:58, 19/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    а центось это не рэдхэт)
     
     
  • 5.61, Stax (ok), 15:29, 20/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > а центось это не рэдхэт)

    В данном контексте - они эквивалентны.

     
  • 4.57, fi (ok), 12:08, 19/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    а что с selinux?
     
  • 4.60, Stax (ok), 15:28, 20/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Эээ я прямо даже теряюсь. Вы слово "selinux" видите?

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

    От пользователя у вас получится сделать все, что угодно (ps -Z - можете убедиться, что вы в контексте unconfined_t). Из nginx'а, работающего в другом контексте у вас эти операции проделать не получится. В nginx будет ошибка, в audit-логе - событие AVC.

     
     
  • 5.63, fi (ok), 13:42, 21/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Эээ я прямо даже теряюсь. Вы слово "selinux" видите?
    > Политика selinux по умолчанию targeted - она защищает конкретные демоны, для которых
    > создана политика…

    Эээ я прямо даже теряюсь. Вы это видили?:

    Default SELinux policies on RHEL and Fedora protect against this flaw by limiting the files nginx's (uid 0) logging process can write to (httpd_log_t).

    Only systems running with 'setenforce 0' or running nginx unconfined are vulnerable to privilege escalation.

    И так вопрос - selinux был включен?

     
     
  • 6.64, Stax (ok), 14:58, 21/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Какое отношение то, что вы написали имеет к командам шелла, выполненным выше (которые предположительно что-то там должны показывать)? Если процесс nginx в тесте не фигурирует, selinux с targeted-политикой не вмешивается в процесс вообще никак.

    Запустите nginx и посмотрите на вывод команд ps auxZ|grep nginx и ps auxZ|grep $$ наконец...

     
     
  • 7.66, fi (ok), 01:14, 23/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Если процесс nginx в тесте  не фигурирует, selinux с targeted-политикой не вмешивается в процесс вообще никак.

    а какой процесс по вашему фигурирует тут?

    > [root@Falcon nginx]# kill -USR1 734

    Прямо детский сад.

    зы. "selinux с targeted-политикой" следит и за пользовательскими процессами, by ex:

    >  SELinux is preventing /usr/lib64/firefox/plugin-container from sendto access on the unix_dgram_socket @nvidia9dc15530.

     
     
  • 8.67, Stax (ok), 15:10, 23/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    bash, ls, ln, kill впрочем, тк не usr bin kill, тот же bash , cat Сделайте на... текст свёрнут, показать
     
     
  • 9.68, fi (ok), 18:08, 23/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    о боже вы не знаете что делает kill посылает сигнал процессу nginx который... большой текст свёрнут, показать
     
     
  • 10.69, Stax (ok), 19:47, 23/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну тут уж прямо без комментариев Вы новость вообще читали В чем уязвимость, см... текст свёрнут, показать
     
     
  • 11.70, fi (ok), 10:41, 24/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Вы точно уверенны что это был я я всего лишь спросил автора теста - был ли п... текст свёрнут, показать
     
     
  • 12.71, Stax (ok), 15:09, 25/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Да неважно, кто Я, кстати, тоже оригинальному автору писал, да что-то в моем ко... текст свёрнут, показать
     

  • 1.73, Виктор (??), 20:34, 16/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я мучую детей в школе.
     
  • 1.74, Виктор (??), 20:36, 16/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Stax лучше бы ты сосал
     

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



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

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