Перейти к содержимому


Фотография

Чем опасен shared хостинг

Форумы IBResource

  • Закрытая тема Тема закрыта
Сообщений в теме: 73
G*g
G*g
  • Участники
  • Cообщений: 281
  • http://
  • Интересы:Люблю красивых телок!

Отправлено

имхо, ни в коем случае в фак. написано так, как будто php - сплошная дыра. уже устал повторять в этой теме, что это не так.
Из всего этого можно только вынести, что IPB требует выделенного хостинга спешиал для него - это уже давно всем известно, только не из-за безопасности, а из-за его громоздкости.
Для общего блага в продвижении php тут нет ничего нового. По словам алексея perl - вообще тогда одна сплошная дыра.
в общем без комментариев... бред...

Сообщение отредактировал G*g: 01 Апрель 2009 - 15:22


Sannis
Sannis
  • Команда форума
  • Cообщений: 11 877
  • http://sannis.ru
  • Город:Москва
  • Интересы:Фотография, физика, высокопроизводительные системы, прикладное программирование, спортивный туризм.

Отправлено

G*g, проблема не в языке, а в правах доступа, насчёт этого всё верно написано.

alexei1966
alexei1966
  • Участники
  • Cообщений: 57

Отправлено

Уважаемый G*g, "дыра" в общем понимании - это когда программа неожиданно ведет себя не так, как было запланировано. А в данном случае скриптовые языки ведут себя именно так, как им положено, просто не все знают, как это должно быть. :D Давайте я для ясности переведу на русский два текста:

The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now.

"Безопасный режим" PHP - это попытка решить проблему безопасности на совместном виртуальном хостинге. С точки зрения архитектуры решать эту проблему на уровне PHP неправильно, однако, поскольку альтернативы на уровне веб-сервера и операционной системы не очень реальны, многие люди, особенно хостинг-провайдеры, пока используют "безопасный режим".
Мануал PHP, 42-я глава


As safe_mode is a name that gives the wrong signals as making PHP safe, we all agreed that we should remove this function. It can never be made totally safe as there will always be ways to circumvent safe_mode through libraries. This kind of functionality also better belongs in the web server or other security scheme.

Поскольку слова "безопасный режим" могут вызвать неправильное представление, будто он делает PHP безопасным, мы все решили, что нам следует удалить эту функцию. Он никогда не может быть полностью безопасным, так как всегда остаются способы обойти safe_mode через библиотеки. Этот вид функциональности лучше реализовывать на уровне веб-сервера или по другой схеме безопасности.
Совещание разработчиков PHP в 2005 году,
http://www.php.net/~....html#safe-mode


Как видите, разработчики PHP после многолетних попыток ограничить скрипты в лазании по серверу плюнули и сдались. В отличие от отдельных товарищей, которые все еще верят, что "хостер с именем и стажем" или "готовая панель для новичков" могут перебороть архитектуру Юникса и его файловую систему. ;) Впрочем, это действительно - скорее из области психологии и "успокоительных для чайников".

Если коротко, на основании своего опыта и здравого смысла резюме я бы предложил такое:

Совместный виртуальный (shared) хостинг предполагает, что в каталогах public_html находятся файлы, которые не содержат конфиденциальной информации - например, статические файлы html. В этом виде он удовлетворяет потребности 95-98% клиентов.

Если же вы предполагаете размещать в каталогах public_html конфиденциальную информацию, либо открываете каталоги для записи со стороны веб-сервера, вам следует подумать о других альтернативах - хостинг с выделенной Апачей, VPS и т.п.


MiksIr
MiksIr
  • Участники
  • Cообщений: 73
  • http://
  • Город:msk.ru

Отправлено

О правах там как и везде - вроде понимает что пишет с одной стороны... а вроде и нет. Средств организации прав есть несколько и приведенная им далеко не самая оптимальная и описана с ошибками. И ACL на юниксе уже не что-то "новенькое", а давно в ядре и работает (и не только для NTFS).

А основную идею можно передать кратко - не ходите к неизвестным хостерам. Я бы выдвинул еще свой лозунг - ходите только к тем, у кого php работает под вашим юзером, но это скорее попытка двигать прогресс =)


Самое главное - не верить всем подряд, включая и тех, что утверждает "я знаю" =)
Как правило, между тем, кто говорит "я знаю" и тем, кто действительно знает, ибо делал все это - огромная разница =)

alexei1966
alexei1966
  • Участники
  • Cообщений: 57

Отправлено

Кстати, очень советую всем серьезным пользователям перечитать то, что пишет в этой ветке MiksIr. В некотором роде его тексты - блестящие образцы... Я бы так не смог. ;) В общем, вы поняли, что я имею в виду. :D

G*g
G*g
  • Участники
  • Cообщений: 281
  • http://
  • Интересы:Люблю красивых телок!

Отправлено

я все веду к тому, что ваши статьи только еще больше запутывают пользователей о php, как о средстве написания скриптов. вы утверждаете что на shared-хостингах лучше не хоститься.
по вашей версии ucoz и многие другие бесплатные php-хостинги уже давно бы лежали. но они не лежат. почему?
почему сайты компании, в которой я работал, хостясь на таком же "левом" хостинге, до сих пор работают?
я видел как ломали и выделенные сервера, но это лишь говорит о криворукости админов, но никак не о "дырявости".
то, что в 6 отменяют safe mode - только огромный плюс, так как толку в нем мало, но есть и другие средства защиты от вашего "лазания" по чужим директориям.
если вы не умеете управлять автомобилем, то вам лучше не садиться за него, так как может настать случай, что вы попадете в аварию. также и здесь. не надо впадать в паранойю.

p.s. MiksIr по крайне мере четко формулируют свою мысль и к его словам не придерешься.

alexei1966
alexei1966
  • Участники
  • Cообщений: 57

Отправлено

Кажется, пошел уже чистый флуд... Отвечу маленьким примером. Вот сейчас вечер 1-го апреля. Набираю http://www.ucoz.ru/. Вижу текст:

На сервере ведутся плановые технические работы

Идут технические работы, связанные с обновлением системы. Планируемое окончание всех работ – 31-е марта.

Приносим извинения за временные неудобства.

:D Это не случайное совпадение, поверьте. Есть у меня информация и с "другой стороны"...

А вообще хочу всех успокоить: IPB и всякие там форумы кракерам нафиг не нужны. Как, кстати, и большинство сайтов. Навару с них чуть. Ну, повыпендриваться перед другим таким же малолетним чайником. Ну, написать фигню какую-нибудь на странице.

Серьезная охота идет только за паролем root, ценятся также пароли к пользователям, которые могут зайти по ssh. Собственно, специалисты по безопасности закрытием подобных дыр и занимаются. А что происходит на 5-баксовом shared хостинге - им параллельно. Может, кто пароль к БД клиента подсмотрел через файловую систему. А может, на компьютере клиента троян пасется. Мне вот сосед на днях фотографии притащил на флешке и честно предупредил: там, дескать, вирус, подцепил у знакомых на фирме; так этот вирус у них по флешкам уже года три как бегает, они к нему привыкли и даже бороться перестали. Проверил - троян... Кстати, у этой фирмы и сайт свой есть. ;)

Также иногда целенаправленно ломают некоторые интернет-магазины. А БД с многолетним флудом пользователей - кому это надо? Поэтому, думаю, админы IPB могут спать спокойно - что на shared hosting, что на любом другом. :)

Egor.M
Egor.M
  • Участники
  • Cообщений: 61
  • http://laracroft.ru

Отправлено

Также иногда целенаправленно ломают некоторые интернет-магазины. А БД с многолетним флудом пользователей - кому это надо? Поэтому, думаю, админы IPB могут спать спокойно - что на shared hosting, что на любом другом.

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

yodas
yodas
  • Участники
  • Cообщений: 74

Отправлено

Gg & Mikser ну вы бы уж помолчали, от вас тут только необоснованное нытье и ничего полезного. Надеюсь все это заметили.
2 Алексей спасибо за ценные советы.

G*g
G*g
  • Участники
  • Cообщений: 281
  • http://
  • Интересы:Люблю красивых телок!

Отправлено

Gg & Mikser ну вы бы уж помолчали, от вас тут только необоснованное нытье и ничего полезного. Надеюсь все это заметили.
2 Алексей спасибо за ценные советы.

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

Сообщение отредактировал G*g: 04 Апрель 2009 - 10:42


yodas
yodas
  • Участники
  • Cообщений: 74

Отправлено

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

Фишка в том, что куда ни ткни носом везде уязвимости есть в любом софте. Человек просто прояснил некторые моменты, которые для многих могли непонятны и вследствие этого многие имеют из-за этого проблемы, не зная ее "корня". А вы как то не понятно даже на свой счет все это приняли.
Да и нигде он не говорил про чью то тупость, прото у кого то больше опыта у кого то меньше и для того существуют такие места как например этот форум чтобы опытом делиться. А если нечем или не хочешь делится, что толку сидеть тут и пыхтеть.

Сообщение отредактировал yodas: 04 Апрель 2009 - 13:39


MiksIr
MiksIr
  • Участники
  • Cообщений: 73
  • http://
  • Город:msk.ru

Отправлено

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

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

ArtemedoN
ArtemedoN
  • Участники
  • Cообщений: 332
  • http://www.swtimeline.ru/
  • Город:Израиль

Отправлено

У кого сложилось не хорошее впечатление - вас никто не заставляет вообще заходить в эту тему. Как говорится: давай те не будем кормить троллей и перестанем оффтопить. Только где тот кто обещал тему переименовать и в другой раздел поставить?

Sannis
Sannis
  • Команда форума
  • Cообщений: 11 877
  • http://sannis.ru
  • Город:Москва
  • Интересы:Фотография, физика, высокопроизводительные системы, прикладное программирование, спортивный туризм.

Отправлено

У кого сложилось не хорошее впечатление - вас никто не заставляет вообще заходить в эту тему. Как говорится: давай те не будем кормить троллей и перестанем оффтопить. Только где тот кто обещал тему переименовать и в другой раздел поставить?

Спорят, я пока не переносил. Не хамите.

P.S. Не стоит беспокоиться, темя прикреплена и о ней не забудут.

MiksIr
MiksIr
  • Участники
  • Cообщений: 73
  • http://
  • Город:msk.ru

Отправлено

Ок, если по существу, попробую сформулировать свои знания (занимался хостингом от админа до менджера, сейчас уже совсем в другой области, так что ни с кем не аффилирован =))) и дополнить/поправить Алексея и вообще начать с того, как все начиналось =)

Изначальный посыл у Алексея правильный. В юниксе права разграничиваются на основе uid - т.е. индентификатора пользователя. Так же в юниксе рождение нового процесса с нуля (exec) - очень долгая и затратная операция. Граздо более веселая операция - "деление" процесса (fork).

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

Так как www должен был читать файлы у юзера - он по определению имел туда доступ, но вебсервер неподконтролен юзеру, так что если не брать во внимание возможные дыры в веб-сервере, такой доступ безопасен. А вот о CGI такого не скажешь - и придумали suexec. Это прослойка между вебсервером и CGI скриптом которая умеет менять юзера, от которого она запущена (эта возможность заложена в юниксе) - вебсервер делал exec на suexec, тот менял права на указанного юзера и делал exec на CGI скрипт пользователя, который запускался от имени юзера уже и не имел соответственно доступа к другим.

Потом появился PHP. Его огромным плюсом, за который его полюбили, была возможность работы как модуль апача (вебсервера), а значит хорошее быстродействие (exec-ов там не делается вообще). ИМХО, это во многом и определил его торжественно развитие и задвигание Perl-a. Для перла были тоже решения как модуль апача, самое известное это mod_perl, но там никто и не думал о безопасности - задачи были другие. А разработчики PHP думали.

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

Опять ИМХО - этот дурацкий сейф мод в угоду непонятно кому был тормозящий прогресс ошибкой =) Но что случилось, уже не исправить.

Итак, имеется mod_php имеющий доступ ко всем файлам системы (совершенно не важно как это реализовано - есть куча способов сделать это от обычных user/group/other до продвинутых ACL и еще более продвинутых RBAC), но программно все возможные варианты досупа к чужим файлам прикрыты.

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

Первое, конечно, это запускать PHP как обычный CGI под управлением suexec. Правда, тут выплыли некторые косяки с авторизацией и был изобретен suphp. Кстати, алексей, suphp - это всего лишь сервисная надстройка над suexec - именно его она и использует, так что выигрыша быстродействия suphp не дает никакого. Какие еще решения?

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

- попытка научить апач менять пользователя - есть кустарное решение в виде модуля которое меняет uid поняв к кому пришел запрос (минус - после отработки запроса процесс умирает и нужно fork-ать новый, тогда как в обычном режиме один процесс может отработать большую очередь запросов) - встречался, изпользут такое. Есть решение от разработчиков в апаче 2, но в общем ничего хорошего о его стабильности не слышал (хотя в свое время кто-то вроде говорил, что и его используют)

- самое удачное и перспективное решение, как мне кажется - mod_fastcgi. Тут разделяется вебсервер и PHP, последний работает от своего пользователя, а счастье привносит менеджер запуска этого PHP - он умеет рождать (exec) новые процессы PHP, протокол fastcgi позволяет прогонять через один PHP процесс множество запросов, а менеджер следит - если какой-то процесс PHP долго неактивен - он его убивает, а у другого юзера если приходится должно ждать в очереди - открывает "вторую кассу" =) В общем, работает очень похоже на то, как работает Апач при обслуживании запросов. Т.е. решение, конечно, хуже чистого mod_php по производительности, но значительно лучше CGI режима при той же безопасности. Однако, рещение широкого распространения не получило опять же из-за разработчиков PHP - реализация fastcgi режима ими далека от совершенства и возникают неприятные моменты (с которыми можно бороться, но это уже опыт).

- а будущее тут - php-fpm патч. Это замена PHP-ной реализации fastcgi, которое имеет много вкустностей (кстати, рано или поздно этот патч войдет в основную ветку PHP). Будущее - потому что основная вкусность не реализована - это менеджер процессов для множества юзеров почти так, как описано выше, но без косяков так как уже внутри PHP =) Прелесть тут еще одна - fastcgi протокол открытый, и PHP может напрямую получать запросы уже не от апача, а от популярных нынче легких веб-сереров (nginx, lighttpd).

Резюмируя. Есть два подхода - програмное разделение прав и перекладывание разделение прав на ядро юникса. Второй подход выглядит более безопасным, но кушает ресурсы более чем первых. Первый подход используется достаточно давно, большинство косяков выловлено, опасность представляет 1) люди не умеющие настраивать безопасность, 2) дыры в самом PHP. Среди профессиональных хостеров первое не встречается, второе фиксится сразу же (и случается не часто)

Все остальные настройки - они известны всем и каждому. Прочие отличные от PHP скрипты запускаются как CGI через врапер ключая exec cmd для SSI. Это уже ответственность безопасности разработчиков Apache.

Теперь про квалификацию и ответственность. Хостеры есть разные. Есть вася_купивший_сервер, есть его разновидность - вася_считающий_себя_знатоком. Есть начинающие хостеры с головой. Есть профессионалы. Возможно Алексей общался только с первыми (они в общем в большинстве своем и сидят на форумах) - ибо всякие душещипательные истории "Хостеру пофиг", "хостер из вредности отключит safe mod" и т.д. - это вот к ним относится. Выбирая левого хостера - скорее всего получите кучу проблем и без пресловутого safe mode. У второй категории в принципе все лучше, люди там умнее, с пользователями разговаривать уже учаться на их языке... но в общем ясно дело, что "в семье не без урода". Читайте хостниг-форумы, как ведут себя представители хостера, какие о нем отзывы и т.д. Третий вариант - профессионалы, которые в принципе не допустят примитивных ошибок начинающих и которые умеют внятно говорит... но и стоят подороже, конечно.

Резюмируя-2: Можно ли получит хак через хостера? - да, можно, чем "левее" хостер, тем выше вероятность (но может и кирпич упасть на голову и уже будет проблема не актуальна). Зависит ли это от того - как запущен PHP - да, но слабо, очень слабо - как правило зависит лишь от дураков, а дураку все равно, что неправильно настраивать - права и группы или PHP.

Сообщение отредактировал MiksIr: 05 Апрель 2009 - 03:58


alexei1966
alexei1966
  • Участники
  • Cообщений: 57

Отправлено

Надо же, мои посты уже не считают "бредом". ;)

Давайте еще раз повторю свою мысль в другой редакции. Есть два вида организации взаимодействия пользователь - веб-сервер.

При первом (веб-сервер запускается под пользователем или специальным отдельным пользователем вида apache_petrov) ваша конфиденциальность по умолчанию защищена архитектурой Юникса. Взломщик может добраться до вашей БД только через "парадный ход", а он обычно защищен.

При втором способе (виртуальный совместный хостинг) ваши данные по умолчанию полностью открыты той же самой архитектурой Юникса, к ним имеют доступ еще 100-200 пользователей. Администраторы хостера должны закрыть доступ со стороны "чужих" пользователей для каждого интерфейса отдельно, вручную. При этом любая дыра в любой библиотеке, используемой Апачей (а их несколько десятков!), мгновенно сведет усилия администраторов на нет (именно об этом писали разработчики PHP, когда обосновывали прекращение работы над safe mode). Следует также помнить, что сведения о дырах в библиотеках обычно поступают к разработчикам с большим опозданием, когда кракеры уже успели вовсю этой дырой попользоваться.

Далее - каждый выбирает по себе женщину, религию и хостинг. :D Я вот предпочел бы иметь защиту архитектурой Юникса. Кому-то ближе руки народных умельцев от хостинга и сэкономленные 5 долларов в месяц. :)

MiksIr
MiksIr
  • Участники
  • Cообщений: 73
  • http://
  • Город:msk.ru

Отправлено

Бред был в сторону попытки описания технической стороны - а косяков там было очень много.
И опять же вы играете пугалками. Давайте, напугаем еще больше - нет никакой защиты "по умолчанию" архитектурой юникс - криворукрий админ допустивший 755 на домашних каталогах это быстро докажет. Т.е. для любой защиты нужены прямые руки. Кривые руки сводят защиту на нет. Это же относится к дестякам дыр в апаче - прямые руки не ставят неизвестные модули "просто так". Основные же стабильны и безопасны приблизительно настолько же, насколько безопасен сам юникс. Для большей безопасности существуют опять же дополнительные меры, как неисполняемые стеки и тому подобное. Т.е. процент нахожения дыры в апаче выше, чем в юниксе, но остается ничтожно мал с вероятностью косяков админа. Так что пугать людей "ацкими дырами" - лоховство, уж извините.
Подавляющее большинство хаков - это или сами дырявые PHP скрипты или, что еще чаще - трояны и соц. инженерия. Об этом стоит беспокоиться пользователям в первую очередь, а не о том, что их хостинг "стопудова дырявый"

Сообщение отредактировал MiksIr: 05 Апрель 2009 - 22:47


alexei1966
alexei1966
  • Участники
  • Cообщений: 57

Отправлено

Остается прояснить анатомические детали: как клиенту определять прямизну рук сисадминов хостера, которых он в глаза не видел и не увидит. Определить прямизну ног сотрудницы, заключающей договор о хостинге как-то легче. :D

Верить "имени" провайдера? Загляните в статистику по российским веб-хостерам:

http://internet.cnews.ru/hosting/stat/

Возьмем для примера Вальюхост, в просторечии - Валуй. Реально крупнейший российский провайдер. А вот в прямизне рук валуйских админов я (и не только я) сильно не уверен. Тем не менее лично знаю одну даму, которая валуйскими услугами крайне довольна. В общем, сколько людей, столько и мнений. ;)

Если конкретно про историю, с которой началось обсуждение - с вероятностью 99% кракеры получили доступ к базе потому, что физически находились на том же виртуальном хостинге. Они подсмотрели логин/пароль, который лежит в явном виде, и дальше через какой-нибудь phpMyAdmin слили БД. А что делать дальше - не знали, даже простой пароль не смогли подобрать. Были бы трояны/соц.инженерия - в руки к кракерам попал бы пароль админа. "Дырявые скрипты" - это об чем? Хостинг и еще раз хостинг...

MiksIr
MiksIr
  • Участники
  • Cообщений: 73
  • http://
  • Город:msk.ru

Отправлено

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

WildRAID
WildRAID
  • Клиенты
  • Cообщений: 1 004
  • http://
  • Город:мамы

Отправлено

Риск есть в любом деле. Вы можете умереть в любую секунду с небольшой вероятностью. Утрата каких-то жалких файлов - это мелочи. В сравнении со многими и многими вещами.

Приобретая услуги любого хостинга, вы всегда рискуете потерять информацию. Shared, не shared .. who cares. Там работают люди, которые ошибаются. Везде работают люди, которые ошибаются.

Если хотите полностью взять ответственность на себя - поставьте сервер дома и настройте самостоятельно. И все равно - никаких гарантий.

По-моему, это очевидные вещи. О чем тема?




Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных