id: Гость   вход   регистрация
текущее время 22:24 25/11/2020
Владелец: unknown (создано 24/06/2012 17:27), редакция от 12/08/2015 22:34 (автор: unknown) Печать
Категории: софт, анонимность, tor
http://www.pgpru.com/Библиотека/Руководства/СетеваяАнонимность/ПродвинутоеИспользованиеTorвUnix/РаздельноеИспользованиеTorbrowserсСистемнымTorиПрозрачнаяТорификация
создать
просмотр
редакции
ссылки

Раздельный запуск Torbrowser от нескольких пользователей с общим системным Tor-процессом и локальная прозрачная торификация


Оглавление документа:

Цель варианта


  1. Использовать торбраузер с локальным системным тором вместо поставляемого в составе TBB.
  2. Осуществить одновременную работу нескольких пользователей системы через системный тор с построением различных цепочек для каждого пользователя посредством подключения к разным портам SocksPort и посредством прозрачной торификации на разные порты TransPort, DNSPort для других програм (опционально — для самого TBB использование прозрачной торификации устарело и не рекомендуется).
  3. Все пакеты, посланные из под конкретного пользователя торбраузером должны направляться файрволлом только на определённые порты локального хоста, связанные с работой системного тора. Это существенно исключает возможность утечки пакетов при уязвимостях в торбраузере, но существенно не защищает от преднамеренных целевых атак на данную конфигурацию.

Конфигурация тор


Остановите системный тор: /etc/init.d/tor stop. Если в текущей версии с этим есть проблемы, используйте kill.
Закомментируйте в конфиг-файле /etc/tor/torrc опцию SocksListenAddress 127.0.0.1. Она устарела, по умолчанию тор слушает только локальные соединения.


В случае проблем с запуском /etc/init.d/tor start, можно в ответ на соответствующие ошибки добавлять опции:


Для прозрачной торификации по умолчанию и для работы через SocksPort тора используются опции:


Следует добавить нужное количество дополнительных портов:


Поскольку порт 9051 занят, то добавим опции управляющего порта:


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


Запуск тор /etc/init.d tor start не должен приводить к ошибкам и должен показывать, что все внесённые в конфиг порты работают нормально.

Настройка iptables


Во многих системах по-умолчанию используется сложный механизм инициализации, конфигурирования и хранения конфигов iptables. Подразумевается, что этот механизм отключен, а вместо него используется шелл-скрипт, который пользователь поддерживает самостоятельно. В Debian/Linux он может быть размещён, например, в /etc/network/if-pre-up.d. Здесь приведены только фрагменты такого скрипта, относящиеся к рассматриваемому варианту торификации.


Закроем снаружи все открытые тор-порты, даже если они принимают только локальные соединения:

$IPTABLES -- переменная содержит путь к iptables, обычно:
IPTABLES="/sbin/iptables"

# $INET_IFACE -- внешний сетевой интерфейс, обычно:
INET_IFACE="eth0"

# blocked_myports -- пользовательская цепочка для заблокированных портов

iptables -N blocked_myports; iptables -F blocked_myports

for PROTOCOL in TCP UDP; do
    for PORT in $(seq 53 58) $(seq 9040 9045) \
        $(seq 9050 90559059 9060do

        $IPTABLES -A blocked_myports -i $INET_IFACE -o !lo -p $PROTOCOL \
        --dport $PORT -j DROP

    done
done

$IPTABLES -A INPUT -p TCP -j blocked_myports
$IPTABLES -A INPUT -p UDP -j blocked_myports


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


$IPTABLES -t nat -A OUTPUT -o lo -j RETURN
$IPTABLES -t nat -A OUTPUT -d 127.0.0.1 -j RETURN


Правило для первого анонимного пользователя:


#Разрешим соединение с SOCKS-портом
$IPTABLES -t filter -A OUTPUT -d 127.0.0.1 -p tcp -m owner \
--uid-owner anonym_1 --dport 9051 -j ACCEPT

###Прозрачная торификация [начало]###
#
#Не требуется при работе TBB
#Может быть использована для одновременной работы других програм
#При отсутствии необходимости эти опции м.б. закоментированы

# Прозрачная торификация TCP на порт 9041

$IPTABLES -t nat -A OUTPUT  -p tcp -m owner --uid-owner anonym_1  \
 -m tcp -j REDIRECT --to-ports 9041
 
$IPTABLES -t filter -A OUTPUT  -d 127.0.0.1 -p tcp -m owner --uid-owner anonym_1  \
 -m tcp --dport 9041 -j ACCEPT
 
#Прозрачная торификация DNS на порт 54

$IPTABLES -t nat -A OUTPUT  -p udp -m owner --uid-owner anonym_1  \
 -m udp --dport 53 -j REDIRECT --to-ports 54

$IPTABLES -t filter -A OUTPUT  -d 127.0.0.1 -p udp -m owner --uid-owner anonym_1  \
 -m udp --dport 54 -j ACCEPT

#
###Прозрачная торификация [конец]###

#Больше этому пользователю ничего не разрешено:

$IPTABLES -A OUTPUT -m owner --uid-owner anonym_1 -j REJECT


По аналогии, правило для второго анонимного пользователя (с закоментированной прозрачной торификацией):


$IPTABLES -t filter -A OUTPUT -d 127.0.0.1 -p tcp -m owner \
--uid-owner anonym_2 --dport 9052 -j ACCEPT

#Прозрачная торификация закоментирована

$IPTABLES -t nat -A OUTPUT  -p tcp -m owner --uid-owner anonym_2  \
# -m tcp -j REDIRECT --to-ports 9042
 
#$IPTABLES -t filter -A OUTPUT  -d 127.0.0.1 -p tcp -m owner --uid-owner anonym_2  \
# -m tcp --dport 9042 -j ACCEPT

#$IPTABLES -t nat -A OUTPUT  -p udp -m owner --uid-owner anonym_2  \
# -m udp --dport 53 -j REDIRECT --to-ports 55

#$IPTABLES -t filter -A OUTPUT  -d 127.0.0.1 -p udp -m owner --uid-owner anonym_2  \
# -m udp --dport 55 -j ACCEPT

$IPTABLES -A OUTPUT -m owner --uid-owner anonym_2 -j REJECT


Разрешим выход наружу самому системному тору:


TOR_UID="debian-tor"

$IPTABLES -A OUTPUT -m owner --uid-owner $TOR_UID -j ACCEPT

Использование tor-arm


Использование пакета Vidalia с системным Tor нецелесообразно из-за полного сворачивания её поддержки. Рекомендуется завести отдельно пользователя, включить его в группу tor-arm и запускать из под него утилиту tor-arm.


Следует избегать запуска tor-arm из под пользователя debian-tor, несмотря на то, что такая рекомендация имеется в пакете и долгое время оставалась неисправленной.


Настройка торбраузера

Начиная с четвёртой версии браузер позволяет автоапдейт. Но в ранних версиях четвёртой ветки стабильность и безопасность этого механизма не гарантировалась. Даже после его стабилизации безопаснее скачивать браузер вручную и проверять контрольные суммы, заверенные подписями GnuPG. Список рекомендуемых версий доступен по ссылке. Скачивание возможно с адреса


Скачанные файлы с подписями и суммами можно разместить в отдельном каталоге и проверить скриптом:

#! /bin/sh

echo > tbbchecklog.txt

sha256sum -c sha256sums-unsigned-build.txt 2>&1 | grep OK >> tbbchecklog.txt

echo >> tbbchecklog.txt

for a in sha256*.asc ; do 
 gpg --verify $a sha256sums-unsigned-build.txt >> tbbchecklog.txt 2>&1 ; 
 echo >> tbbchecklog.txt
done

echo >> tbbchecklog.txt

gpg --verify tor-browser-linux64*.asc >> tbbchecklog.txt 2>&1

echo >> tbbchecklog.txt


Перед ручным обновлением рекомендуется экспортировать старые закладки в файл, удалить старый распакованный каталог TBB. Впоследствии возможно импортировать закладки из файла обратно в новый распакованный браузер (вкладки: Bookmarks — Show all Bookmarks — Import and Backup).


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


В распакованном каталоге TBB удалите расширение запуска Tor из связки:



Запустите TBB:



Зайдите в настройки: Edit → Preferences → Advanced → Network → Settings


И выберите опции:



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


В адресной строке браузера нужно набрать about:config, для внесения некоторых опций, перечисленных в скрипте запуска start-tor-browser:


# extensions.torbutton.custom.socks_host  127.0.0.1
# extensions.torbutton.custom.socks_port  <SocksPort>
# extensions.torbutton.inserted_button    true
# extensions.torbutton.launch_warning     false
# extensions.torbutton.loglevel           2
# extensions.torbutton.logmethod          0
# extensions.torbutton.settings_method    custom
# extensions.torbutton.socks_port         <SocksPort>
# extensions.torbutton.use_privoxy        false
# app.update.auto                         false


В торбраузере, начиная с версии 4.5, организована корректная работа с SOCKS-портом, при этом для разных доменов выбираются разные исходящие узлы и существует возможность менять исходящий узел для каждой вкладки при помощи опции New Tor Circuit for this Site в Torbutton. При этом из-за удаления плагина tor-launcher, предназначенного для запуска локального (несистемного) Tor, часть опций tor-button будет недоступна. В связи с этим рекомендуется настраиваеть торбраузер на работу с системным тором именно через SOCKS-порт, а не через прозрачную торификацию. Прозрачная торификация может быть использована для этого же пользователя для работы с другими программами, но ей лучше не пользоваться при повышенных требования анонимности из-за опасениях утечки профилирующих и идентифицирующих данных, а также по другим возможным причинам.


После сохранения изменений следует перезапустить TBB. В разных вкладках на разных доменах TBB должен показывать разные IP-адреса, а при проверке через одинаковые домены — соответственно одинаковые в пределах жизни цепочки. Проверку наличия обновлений можно периодически осуществлять и вручную, например по основной ссылке рекомендуемых версий и скачивания новой версии.


Можно запустить два и более TBB из под разных пользователей одновременно. При одновременной проверке они должны показывать разный IP-адрес исходящих узлов при проверке на одном и том же домене.


При работе из-под одного пользователя для смены профиля рекомендуется перезапустить браузер и сменить все цепочки программной tor-arm или отправкой сигнала системному тор-процессу.


 
На страницу: 1, 2, 3, 4, 5, ... , 12, 13, 14, 15, 16 След.
Комментарии [скрыть комментарии/форму]
— unknown (24/06/2012 17:54, исправлен 24/06/2012 17:55)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Исходная ветка для общих обсуждений, не относящихся только к этому конкретному варианту.

— Гость (24/06/2012 18:29)   <#>
> Изменения опций торификации в текущей версии TorBrowser/TorButton, включающие режим прозрачной торификации или меняющие SocksPort на значение, отличающееся от 9050, не дают никакого результата. TorBrowser или перестаёт работать, или продолжает работать только через порт 9050, хотя в настройках Torbutton указаны другие значения.

Уже и смену настроек прокси сломали? 1:1? Работало же. Никто не хочет написать баг-репорт?

> Это существенно исключает возможность утечки пакетов при уязвимостях в торбраузере, но существенно не защищает от преднамеренных целевых атак на данную конфигурацию.
Оно? Медведь стучится в дверь ко мне...
— Гость (24/06/2012 19:30)   <#>
А VirtualAddrNetwork остается один и тот же для всех? На случай, когда коннектишься, например, по ssh по адресу скрытого сервиса (без этой опции прозрачная торификация не работала, ssh-клиент пытался законнектиться с локалхостом, а не скрытым сервисом).
P.S. Большой пасибыч за сей труд, unknown!!!
— unknown (24/06/2012 19:51, исправлен 24/06/2012 19:55)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

У меня выглядит как 1:1. Пожалуйста, подтвердите, поэкспериментируйте. Нужно или добиться от TBB нормальной работы через другой SOCKS-порт, или включения прозрачной торификации (так чтобы он работал не через SOKS-порт). Если не получиться — составлять баг-репорт. Или кто-нибудь, подскажите как (и можно ли?) поменять порт назначения файрволлом в данном случае. Потому что в других цепочках (в смысле chains, для iptables, а не тора) модуль owner не работает.


Кстати, двойное заворачивание в тор, как кто-то предлагал в альтернативном варианте — потенциально опасная штука. Можно завернуть цепочку Host 1 — Host 2 — Host 3 в цепочку Host 3 — Host 2 — Host 1 или хотя бы частично обратную. Хотя это маловероятно и для скачивания статистики несущественно.


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


Пока медведь, да.
Помимо концепции медведя пришла в голову концепция отличия практической/коммерческой безопасности от теоретической/исследовательской. В исследовательской нормальное дело улучшать стойкость самого сильного (или вообще любого отдельного) звена, даже если остальные — слабые. Будем изучать и улучшать создание невзламываемых замкОв, даже если при этом мы умеем делать только картонные двери. Зато, когда будет изобретён способ создания прочных дверей к ним уже будут созданы прочные замки и готовый результат можно будет выпускать в широкую практику.


Нужно поэкспериментировать, по идее все цепочки на разных портах всё равно построятся разные. Или выяснить, например это влиет только на запрос скрытого сервиса — выяснения точки встречи, но не на цепочки.


Ну хоть какое-то начало положено, а то почти 9 месяцев ничего родить не получалось :-)

— Гость (24/06/2012 19:56)   <#>
Как я понимаю, есть программы, которые не могут работать с сервисом, не зная его IP, и ssh к таковым относится. В частности, он проверяет соответствие как DNS, так и IP предыдущим записям в known_hosts. Для таких случаев в Tor предусмотрена раздача фиктивных IP по запросам. В этом смысле неработоспособность ssh на скрытом ресурсе без VirtualAddrNetwork вполне предсказуема, а вот прозрачная торификация тут, имхо, ни при чём.
— Гость (24/06/2012 20:20)   <#>
> как (и можно ли?) поменять порт назначения файрволлом в данном случае. Потому что в других цепочках (в смысле chains, для iptables, а не тора) модуль owner не работает.

Интересный вопрос, надо экспериментировать. Теоретически rdr + pass in/out должно отрабатывать. Есть ещё функционал в route-to, но я плохо понимаю, что именно оно делает. В rdr меня смущает, что pass out не будет использоваться, т.е. пакеты от всех пользователей (идущие на некоторый порт) будут перенаправляться на заданный порт. А на стадии pass in опция user ловит только то, от имени кого запущен сервис, а не то, кто послал. Впрочем, почти уверен, что сделать можно.

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

Позже. Прозрачная торификация не заработает почти точно, т.к. в последних 2-3 версиях она уже не работала. Прокси стоит проверить.

> Можно завернуть цепочку Host 1 — Host 2 — Host 3 в цепочку Host 3 — Host 2 — Host 1 или хотя бы частично обратную.

Как ноды в цепочке моментально смогут понять, что реализовался именно описанный случай (без корреляций и статистики)?

> Возможно как-то поднять псевдоустройство или прокси на локальном хосту с правами пользователя и таким способом обмануть файрволл.

Если Tor-рутер на физически другой машине, это сильно упрощает настройку. А так... ssh -w root@127.0.0.1 позволяет сделать хоть сто дополнительных псевдоинтерфейсов, но это грязный и перегруженный метод. Есть и другие способы создания и работы с псевдоинтерфейсами, если всё локально. Возможно, какой-нить VLAN или просто насоздавать дополнительных IP-алиасов для lo и фильтровать в зависимости от IP (127.0.0.1, 127.0.0.2 и т.д.).
— unknown (24/06/2012 20:38)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

скорее всего никак.
  1. Если из этого варианта выйдет что-то путное, то его можно будет перенести и на тор-рутер, тем более на торпроджекте кто-то такую тему продвигает, но это будет скорее другой вариант. Данный случай пока без рутера/виртуалок (например, слабый нетбук с беспроводным инетом).
  2. В связи с проксями/псевдоинтерфейсами здесь упомянуты догадки не о способе настройки, а о способе взлома схемы этого варианта, его ограничениях в области безопасности. Может ли злонамеренный код, загрузившийся и запустившийся через дыру в TBB сделать такую привязку к локалхосту, чтобы обойти настройки файрволла, не повышая свои привилегии до рута? Скорее всего может. Поэтому внешний роутер или упрятывание в виртуалку имеют смысл, но в этом варианте просто не рассматриваются. Предлагается эти варианты изучать отдельно.
— Гость (24/06/2012 21:09)   <#>

В способе с двойным заворачиванием в Tor не может, а тут... надо курить ваши правила. Виртуалка защищает, прежде всего, от вот этого, а не от обходов настроек firewall'а или от ошибки с повышением привелегий.

Ну и, раз пошла такая пьянка, режьте перенесите этот[создать] топик в общую копилку сакральных знаний[создать] (или хотя б ссылку поставьте), а по виртуалкам пока мало информации.

P.ک.: «Слабый нетбук с беспроводным инетом» как раз и есть идеальный шанс организовать на нём wifi-Tor-рутер :)
— unknown (24/06/2012 22:00)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Если готовы его поддерживать неанонимно, то распишитесь своим ключом и я (или SATtva, потому как с правами при переносе у меня часто бывают обломы) его перенесу, передав вам права на его владение как зарегистрированному пользователю.
— Гость (24/06/2012 22:11)   <#>
перенесите этот[создать] топик
Если готовы его поддерживать неанонимно, то распишитесь своим ключом
Расписался. Впрочем, как все знают, подпись авторство не доказывает. Не суть важно, у кого будут формальные права на владение, т.к. разумно дать права на редактирование всем. Вдруг кто-то захочет дополнить/доработать материал.
— unknown (24/06/2012 22:31, исправлен 24/06/2012 22:35)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Скопировал[создать]. Пока сделал доступ группе OpenPGP, владение вам, дальше можете сами изменить доступ.

— Гость (24/06/2012 23:08)   <#>
А как может угрожать с точки зрения возможного профилирования то, что TBB и при прозрачной торификации работает через порт 9050?
Скажем, если идет утечка каких-то пакетов под юзером, прозрачно торифицированным под другим SocksPort'ом, то они будут заворачиваеться фаерволом уже в этот порт, а не в 9050, и идти по другой цепочке Tor-нод.
Насколько это угрожает?
P.S. Когда я тестил FF и громоптицу у них вроде утечек не было, вот tkabber давал неск. пакетов dns-запросов утечки, можно было видеть их завернутыми в Tor фаерволом через iptables -L -v -t nat. Но вдруг?
— spinore (24/06/2012 23:39, исправлен 24/06/2012 23:51)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786

> Скопировал. Пока сделал доступ группе OpenPGP, владение вам, дальше можете сами изменить доступ.
Спасибо. Уже сменил.


> А как может угрожать с точки зрения возможного профилирования то, что TBB и при прозрачной торификации работает через порт 9050?


Не очень понятно, о чём речь.

  1. Если прозрачная торификация делается на Tor-рутере, то последний для торифицированных машин работает как gateway: клиенты не видят, на какие порты внутри Tor-рутера перенаправляются пакеты.
  2. Если прозрачная торификация работает на той же машине, что и порождает торифицируемый трафик, то потенциально клиент может видеть список всех открытых портов.
    1. Чем они нестандартней, тем, формально, больше профилирования, но это всё равно попытка перехитрить самого себя: обычному пользователю доступно так много информации, что вряд ли список открытых портов здесь что-то изменит.
    2. Можно рассуждать и по-другому: пусть есть массовый эксплоит, опирающийся на то, что у всех всё запущено стандартно и на стандартных портах, тогда, поменяв станадртый порт, можно будет уберечься от такой массовой стандартизированной атаки (и такое уже было).
    Хотя, если подходить к вопросу серьёзно, практически пустые спекуляции — хоть A, хоть B. Без виртуальной машины проблема вообще не решается, да и с ней будет защита не от профилирования, а от утечки информации о том, что анонимный и неанонимный профиль работают физически на одной и той же машине (операционной системе).
— unknown (25/06/2012 00:39, исправлен 25/06/2012 00:49)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Скорее всего, Гость (24/06/2012 23:08) не интересовался утечкой списка открытых изнутри портов в случае эксплойта. Хотя это замечание тоже интересно. Речь скорее о том, чтобы при утечках/сбоях настройки безо всяких эксплойтов цепочки разных пользователей между собой не перепутались.


Следует различать работу через SOCKS порты: 9050, 9051 (в нашем примере он вместо управляющего), 9052, 9053 и т.д. — это не прозрачная торификация. Это прямое соединение с тор-демоном.


Перенаправление трафика опцией iptables-REDIRECT на локальные TransPort 9040, 9041, 9042, и т.д. и DNSPort 53, 54, 55 и т.д. — это прозрачная торификация. Прозрачная торификация работает без нареканий для тех программ, которые не работают через SOCKS, а пытаются напрямую слать пакеты в инет. Или они получат цепочку на своём порту, или по каким-то причинам не смогут работать вообще.


Что касается не прозрачной торификации, а работы напрямую через SOCKS. Здесь пакеты шлются не во внешнюю сеть, а сразу на локалхост, поэтому и редирект портов для них не работает. К сожалению, я не знаю как его сделать в этом случае локально с применением модуля owner.


Если программа работает через SOCKS и настроена скажем на порт 9051, а пытается соединиться через порт 9050, а в файрволле это для данного пользователя не разрешено, то она и не сможет это сделать. Общее правило, разрешающее для всех пользователей выход через 9050 — временное из-за проблем с TBB и оно действительно может привести и к смешиванию цепочек при аналогичных дефектах в других программах, соединяющихся с тором через SOCKS. Как только проблему с TBB удасться решить, нужно будет разрешить для каждого пользователя свой единственный SOCKS-порт. Единственное, что при этом может быть, это как в случае с багом в торбраузере с утечками DNS. Торбраузер получал бы цепочки через SOCKS-порт, а утечка DNS проходила бы через прозрачно торифицированный DNS-порт, но оба должны быть уникальными для данного пользователя так, чтобы не смешиваться с чужими портами, что будет блокироваться настройками файрволла. Пока что из-за общего порта 9050 это не так.


Т.е. в идеале, если бы не баги в TorButton, у каждого пользователя должна быть уникальная тройка SOCKS, Transport и DNS портов. Файрволл должен разрешать (строго на локалхост) прямое соединение для первого и прозрачную торификацию для двух других. Если происходит слёт настроек на другой порт или утечки, то всё должно продолжать работать или только в рамках этих трёх портов или не работать никак.

— unknown (25/06/2012 10:53, исправлен 25/06/2012 11:22)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Уже есть.


Torbutton always reset SOCKS port to 9050 — якобы пофиксили 7 месяцев назад. Похоже, что или недофиксили, или снова поломали.


Enhance "Transparent Torification (Requires custom transproxy or Tor router)" in Tor Button. — а эту опцию активно пилят, но пока не могут сделать как надо.


Vidalia's "Avoid public network" dialog should ask about tor router? — поддержку тор-роутеров и прозрачной торификации возможно включат и в видалию, хотя это и не в приоритете.


Exits should block reentry into the tor network — рано или поздно экситы будут блокировать двойное заворачивание в тор, так что рассчитывать на этот костыль для развязывания TBB не стоит.


replace iceweasel with Torbrowser? — проект TAILS изучает возможность перехода с патченного Iceweasel на прозрачно торифицированный TBB и возможность сборки deb-пакетов для Debian/Debian-based систем.

На страницу: 1, 2, 3, 4, 5, ... , 12, 13, 14, 15, 16 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3