path: root/russian/security/key-rollover/index.wml

#use wml::debian::template title="Замена ключей"
#use wml::debian::translation-check translation="5011f532637dc7820b79b151eecfda4ab65aa22f" maintainer="Lev Lamberov"

<p>
В <a href="$(HOME)/security/2008/dsa-1571">рекомендации по безопасности Debian 1571</a>,
команда безопасности Debian обнаружила уязвимость в генераторе случайных чисел, используемом
OpenSSL в Debian и производных от него дистрибутивах. В результате этой уязвимости
некоторые ключи шифрования являются намного более простыми, чем они должны быть, так что
атакующий может отгадать ключ с помощью атаки перебором, имея минимальные знания
о системе. Это, в частности, касается использования ключей шифрования в OpenSSH,
OpenVPN и сертификатах SSL.
</p>

<p>
Эта страница содержит информацию о том, как выполнить процедуру замены ключей для пакетов,
чьи ключи подвержены уязвимости OpenSSL.
</p>

<ul>
<li><b><a href="#openssh">OpenSSH</a></b></li>
<li><b><a href="#openssl">OpenSSL: общие инструкции по созданию PEM-ключа</a></b></li>

<li><a href="#bincimap">bincimap</a></li>
<li><a href="#boxbackup">boxbackup</a></li>
<li><a href="#cryptsetup">cryptsetup</a></li>
<li><a href="#dropbear">dropbear</a></li>
<li><a href="#ekg">ekg</a></li>
<li><a href="#ftpd-ssl">ftpd-ssl</a></li>
<li><a href="#gforge">gforge</a></li>
<li><a href="#kerberos">MIT Kerberos (krb5)</a></li>
<li><a href="#nessus">Nessus</a></li>
<li><a href="#openswan">OpenSWAN / StrongSWAN</a></li>
<li><a href="#openvpn">OpenVPN</a></li>
<li><a href="#proftpd">Proftpd</a></li>
<li><a href="#puppet">puppet</a></li>
<li><a href="#sendmail">sendmail</a></li>
<li><a href="#ssl-cert">ssl-cert</a></li>
<li><a href="#telnetd-ssl">telnetd-ssl</a></li>
<li><a href="#tinc">tinc</a></li>
<li><a href="#tor">tor</a></li>
<li><a href="#xrdp">xrdp</a></li>
</ul>

<p>
Другое ПО тоже использует криптографические ключи, но оно 
<a href="notvuln">не подвержено</a> этой уязвимости, поскольку OpenSSL не используется в нём для создания
или обмена ключами.
</p>

<ul>
<li><a href="notvuln#ckermit">ckermit</a></li>
<li><a href="notvuln#gnupg">GnuPG</a></li>
<li><a href="notvuln#iceweasel">Iceweasel</a></li>
<li><a href="notvuln#mysql">MySQL</a></li>
</ul>

<p>
Инструкции по замене ключей для остального ПО см. в
информации, предоставленной пользователями, на странице <url https://wiki.debian.org/SSLkeys>
</p>

<h1><a name="openssh">OpenSSH</a></h1>

<p>
Для облегчения преобразования ключей были выпущены обновление пакетов, перечисленных в
<a href="$(HOME)/security/2008/dsa-1576">DSA-1576</a>.
</p>

<p>1. Установите обновления безопасности из DSA-1576</p>

   <p>После того, как вы примените обновление, нестойкие пользовательские ключи будут автоматически
   отвергнуты там, где это возможно (хотя иногда определить все такие ключи
   нельзя). Если вы используете такие ключи для авторизации пользователей, они
   тут же перестанут работать и должны быть заменены (см.
   шаг 3).</p>

   <p>OpenSSH-ключи узла могут быть автоматически созданы заново при применении
   обновления безопасности OpenSSH. Обновление запросит у вас подтверждение
   этого шага.</p>

<p>2. Обновите файлы known_hosts</p>

   <p>Создание новых ключей узла приведёт к тому, что при подключении к этому узлу с системы, использующей SSH,
   будет отображаться предупреждение до тех пор, пока ключ узла не будет обновлён в файле
   known_hosts на стороне клиента. Предупреждение будет выглядеть приблизительно так:</p>

<pre>
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
</pre>

   <p>В этом случае просто был изменён ключ узла, а вам следует обновить
   соответствующий файл known_hosts, как это обозначено в сообщении.
   
   Рекомендуется использовать доверенный канал для получения
   ключа сервера. Ключ находится в файле /etc/ssh/ssh_host_rsa_key.pub на
   сервере; его отпечаток может быть распечатан с помощью команды:</p>

      <p>ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub</p>

   <p>Помимо пользовательских файлов known_hosts, может существовать
   системный файл /etc/ssh/ssh_known_hosts. Этот файл
   используется и клиентом ssh, и sshd для предоставления функциональности
   hosts.equiv. Этот файл так же следует обновить.</p>

<p>3. Проверьте все пользовательские ключи OpenSSH</p>

   <p>Наиболее безопасным способом является создание всех пользовательских ключей заново
   за исключением тех случаев, когда с достаточной определённостью может быть установлено, что
   данный ключ был создан на системе, не подверженной уязвимости.</p>

   <p>Проверьте, уязвим ли ваш ключ, используя инструмент ssh-vulnkey, включённый
   в обновление безопасности. По умолчанию ssh-vulnkey проверит стандартный
   каталог на наличие пользовательских ключей (~/.ssh/id_rsa, ~/.ssh/id_dsa and ~/.ssh/identity),
   ваш файл authorized_keys (~/.ssh/authorized_keys и
   ~/.ssh/authorized_keys2) и системные ключи узла
   (/etc/ssh/ssh_host_dsa_key и /etc/ssh/ssh_host_rsa_key).</p>

   <p>Чтобы проверить все ваши ключи, если они находятся в стандартном
   каталоге (~/.ssh/id_rsa, ~/.ssh/id_dsa, or ~/.ssh/identity) выполните следующую команду:</p>

     <p>ssh-vulnkey</p>

   <p>Чтобы проверить все ключи в вашей системе, используйте следующую команду:</p>

     <p>sudo ssh-vulnkey -a</p>

   <p>Чтобы проверить ключ в нестандартном каталоге, используйте следующую команду:</p>

     <p>ssh-vulnkey /путь/к/ключу</p>

   <p>Если ssh-vulnkey выводит <q>Unknown (no blacklist information)</q>, то у него нет
   информации о том, уязвим этот ключ или нет. Если у вас имеются сомнения, удалите
   этот ключ и создайте новый.
   </p>

<p>4. Создайте заново уязвимые пользовательские ключи</p>

   <p>Ключи OpenSSH, используемые для авторизации пользователей, следует создать заново вручную,
   включая те ключи, которые были перенесены с другой
   системы.</p>

   <p>Новые ключи могут быть созданы, используя ssh-keygen, напр.:</p>

   <pre>
   $ ssh-keygen
   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/user/.ssh/id_rsa):
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /home/user/.ssh/id_rsa.
   Your public key has been saved in /home/user/.ssh/id_rsa.pub.
   The key fingerprint is:
   00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 user@host
   </pre>

<p>5. Обновите файлы authorized_keys (если это необходимо)</p>

   <p>После того, как пользовательские ключи заново созданы, соответствующие публичные ключи
   следует добавить во все файлы authorized_keys (и файлы authorized_keys2,
   если таковые имеются) на удалённых системах. Убедитесь в том, что уязвимые ключи
   удалены.</p>
   
<h1><a name="openssl">OpenSSL: общие инструкции по созданию PEM-ключа</a></h1>

<p>
Это просто напоминание тем, кто создаёт (может быть заново) сертификаты в
формате PEM. Ваш сайт, вероятно, имеет другие правила
управления ключами, которым вам нужно следовать. Кроме того, вам, скорее всего, может потребоваться
получение подписи третьей стороны (центра сертификации) для ваших сертификатов,
а не использование сертификатов, которые подписаны вами самими, как это показано ниже:
</p>

<pre>
cd /etc/ssl/private
openssl genrsa 1024 &gt; mysite.pem
cd /etc/ssl/certs
openssl req -new -key ../private/mysite.pem -x509 -days 9999 -out mysite.pem
</pre>
  
<h1><a name="bincimap">bincimap</a></h1>

<p>
Пакет bincimap автоматически создаёт сертификат с собственной подписью
через программу openssl для сервиса bincimap-ssl и помещает его
в /etc/ssl/certs/imapd.pem. Чтобы создать его заново, выполните следующее:
</p>

<pre>
rm -f /etc/ssl/certs/imapd.pem
dpkg-reconfigure bincimap
</pre>

<h1><a name="boxbackup">boxbackup</a></h1>

<p>
Boxbackup отсутствует в стабильном выпуске Debian, он есть только в тестируемом выпуске/Lenny.
</p>

<p>
В основной ветке разработки опубликован анализ ключей, созданных
на системах с недостаточно случайным PRNG. Вы можете ознакомиться с подробностями
<a href="http://lists.warhead.org.uk/pipermail/boxbackup/2008-May/004476.html">здесь</a>.
</p>

<p>
Если PRNG в вашем OpenSSL недостаточно случаен, вам следует выполнить следующее:
</p>

<ul>
<li>Создайте заново все уязвимые сертификаты, которые были созданы или
подписаны на уязвимых системах</li>
<li>Создайте заново все данные ключей (*-FileEncKeys.raw)</li>
<li>Удалите данные, сохранённые на вашем сервере, с соответствующим уровнем
обеспечения безопасности (по меньшей мере, перезапишите файлы нулям, или сделайте что-то ещё, если у вас паранойя)</li>
<li>Загрузите всё заново</li>
<li>Примите необходимые меры соответствующие допущению, что вы
хранили ваши данные в виде простого текста на публичном сервере без авторизации.
(т.е., начните с нуля, удалите все следы резервных
копий данных и примите другие необходимые меры для преуменьшения вероятности открытия ваших
секретов)</li>
</ul>

<h1><a name="cryptsetup">cryptsetup</a></h1>

<p>
Cryptsetup сам по себе не использует для шифрования openssl (эти применимо и к
устройствам LUKS, и к устройствам dm-crypt).
</p>

<p>
<em>Если</em> cryptsetup был настроен на использование файлов с ключами, зашифрованными с помощью SSL (настройка
не по умолчанию, которая должна быть явным образом изменена пользователем),
и для создания файла ключей была использована сломанная версия openssl, шифрование файла ключей
может быть менее стойко, чем это ожидалось (поскольку криптографическая соль не является
по-настоящему случайными данными).
</p>

<p>
В качестве решения можно либо заново зашифровать файл ключей (если вы
достаточно уверены, что зашифрованный файл не был раскрыт
каким-либо третьим лицом), либо очистить и переустановить уязвимый раздел (-ы),
используя новый ключ.
</p>

<p>
Инструкции о том, как заново зашифровать файл ключей:
</p>

<p>
Выполните следующие действия для каждого файла ключей, зашифрованного SSL, заменив
&lt;путь_к_зашифрованному_ssl_ключу&gt; путём к фактическому файлу ключей:
</p>

<pre>
tmpkey=\$(tempfile)
openssl enc -aes-256-cbc -d -salt -in &lt;путь_к_зашифрованному_ssl_ключу&gt; -out "$tmpkey"
shred -uz &lt;путь_к_зашифрованному_ssl_ключу&gt;
openssl enc -aes-256-cbc -e -salt -in "$tmpkey" -out &lt;путь_к_зашифрованному_ssl_ключу&gt;
shred -uz "$tmpkey"
</pre>

<h1><a name="dropbear">dropbear</a></h1>

<p>
Если у вас имеются ключи /etc/ssh/*host*, то либо удалите их, либо до обновления
ключей dropbear выполните
<a href="#openssh">инструкции для openssh</a>.
</p>

<p>
Сценарии, выполняющиеся после установки dropbear, преобразуют существующие ключи openssh в формат dropbear,
если они не могут найти ключи узла dropbear.
</p>

<pre>
rm /etc/dropbear/*_host_key
dpkg-reconfigure dropbear
</pre>

<p>
Заметьте, что ключи, созданные самим dropbear, не подвержены
уязвимости (он использует libtomcrypt, а не OpenSSL).
</p>

<h1><a name="ekg">ekg</a></h1>

<p>
Пользователи программ ekg или ekg2 (последняя имеется только в экспериментальном выпуске),
использующие функциональность шифрования <q>SIM</q> и создавшие пару ключей, используя
команду <q>/key [-g|--generate]</q> (которая использует для этого libssl),
должны заново создать эти ключи после обновления libssl и перезапустить
программу.
</p>

<p>
Разработчики основной ветки разместили на своём веб-сайте заметку:
<a href="http://ekg.chmurka.net/index.php">http://ekg.chmurka.net/index.php</a>
</p>

<p>
Если вам требуется дальнейшая помощь, задайте вопрос в ekg-users@lists.ziew.org или
ekg2-users@lists.ziew.org (оба списка и на английском, и на польском языках).
</p>

<h1><a name="ftpd-ssl">ftpd-ssl</a></h1>

<pre>
rm -f /etc/ftpd-ssl/ftpd.pem /etc/ssl/certs/ftpd.pem
dpkg-reconfigure ftpd-ssl
</pre>

<p>
Это подходит для настройки по умолчанию. Если администратор до этого дополнительно настроил
инфраструктуру SSL, эти ключи также следует создать
заново.
</p>

<h1><a name="gforge">gforge</a></h1>

<p>
Пакет gforge-web-apache2 в sid и lenny настраивает веб-сайт
с временным сертификатом в том случае, если не были найдены существующие сертификаты. Позже
пользователям следует заменить его <q>действительным</q> сертификатом. Этот временный сертификат
выпущен для Snake Oil, поэтому он уже известен как нестойкий
сертификат (даже без этой ошибки SSL), но некоторые пользователи могут принять
его без задней мысли. 
</p>

<h1><a name="kerberos">MIT Kerberos (krb5)</a></h1>

<p>
Ни одна часть MIT Kerberos в Debian 4.0 (<q>Etch</q>) не использует OpenSSL, и поэтому Kerberos
в Debian 4.0 вообще не подвержен этой уязвимости.
</p>

<p>
В Lenny отдельный двоичный пакет krb5-pkinit использует OpenSSL. MIT
Kerberos сам по себе не создаёт долговременных пар ключей, даже когда используется расширение
PKINIT, поэтому любые уязвимые долговременные пары ключей должны были быть
созданы не с помощью ПО MIT Kerberos. Расширение PKINIT
лишь указывает существующие пары ключей и не ответственно за управление
ключами.
</p>
<p>
Долговременные пары ключей, используемые с PKINIT, могут быть уязвимы в том случае, если они были созданы
на уязвимой системе Debian, но это создание ключей является внешним по отношению к MIT Kerberos.
</p>
<p>
Тем не менее, функции случайных чисел OpenSSL используются для DH-обмена,
когда используется авторизация PKINIT, что означает, что атакующий может
использовать атаку перебором для получения доступа к ответу KDC на авторизацию PKINIT
и в последствии может получить доступ к любой сессии, созданной с использованием
сервисных билетов этой авторизации.
</p>
<p>
Любые KDC, использующие расширение PKINIT из Lenny должны немедленно обновить пакеты libssl0.9.8
и перезапустить Kerberos KDC с помощью следующей команды:
</p>
<pre>
/etc/init.d/krb5-kdc restart
</pre>
<p>
Всякие билеты Kerberos, дающие билеты (TGT), или зашифрованные сессии, получающиеся при
авторизации PKINIT с использованием Kerberos KDC с уязвимым пакетом libssl,
следует рассматривать как подозрительные; возможно, что перехватившие пакеты атакующие
смогут скомпрометировать эти ключи и сеансы.
</p>

<h1><a name="nessus">Nessus</a></h1>

<p>Сценарий серверного пакета Nessus (nessusd) после установки создаёт
некоторые ключи SSL для безопасного взаимодействия между сервером Nessus и клиентом.
Этот канал взаимодействия должен рассматриваться как скомпрометированный, поскольку злоумышленник
мог перехватить информацию, которой обмениваются друг с другом сервер и
клиент (эта информация включает информацию об уязвимостях удалённых узлов), и
потенциально отправить команды на сервер от лица авторизованного пользователя.</p>

<p>Кроме того, если администратор создал либо ключ Nessus CA, либо пользовательский
сертификат (с помощью nessus-mkcert-client) для удалённой авторизации на сервере,
на котором установлена уязвимая версия OpenSSL, эти
ключи следует считать скомпрометированными. Заметьте, что удалённые пользователи с доступом к
серверу Nessus могут запускать атаки на серверы, которые им разрешено атаковать,
и, если это включено в локальной конфигурации (в Debian этот параметр по умолчанию имеет значение <q>no</q>),
загружать расширения, которые могут быть выполнены на сервере Nessus с правами
суперпользователя.</p>

<p>Сценарии с настройками сопровождающего создадут заново сертификаты OpenSSL при
настройке пакетов, если они не найдут эти сертификаты. Вам нужно удалить сертификаты и
создать новые, используя следующие команды:</p>

<pre>
rm -f /var/lib/nessus/CA/cacert.pem
rm -f /var/lib/nessus/CA/servercert.pem
rm -f /var/lib/nessus/private/CA/cakey.pem
rm -f /var/lib/nessus/private/CA/serverkey.pem
dpkg-reconfigure nessusd
</pre>

<p>Когда это будет сделано, вам нужно будет удалить старые пользовательские ключи
в /var/lib/nessus/users/USERNAME/auth и создать их заново с помощью
nessus-mkcert-client. После удаления ключа CA старые ключи будут считаться неправильными.
</p>

<p>После того, как будет заново создан ключ CA, вам будет нужно передать вашим пользователям новый
сертификат CA, а ваши пользователи должны будут принять новый сертификат
сервера Nessus, когда они снова к нему подключатся. Настройки сертификата для старого
сервера должны быть автоматически удалены, но вы также можете удалить их вручную,
редактируя <code>.nessusrc.cert</code> (если вы используете клиент Nessus) или
<code>.openvasrc.cert</code> (если вы используете клиент OpenVAS).</p>


<h1><a name="openswan">OpenSWAN / StrongSWAN</a></h1>

<pre>
rm /etc/ipsec.d/private/`hostname`Key.pem /etc/ipsec.d/certs/`hostname`Cert.pem
dpkg-reconfigure (open|strong)swan
/etc/init.d/ipsec restart
</pre>

<p>
Внимание: перезапуск служб ipsec приведёт к закрытию всех открытых в данный момент соединений IPSec,
которые, возможно, надо будет перезапустить с другой стороны.
</p>

<h1><a name="openvpn">OpenVPN</a></h1>

<p>
Сделайте резервную копию ваших файлов секретных ключей. Хотя имена ключей являются случайными, они
могут быть обнаружены с помощью команды
</p>
<pre>grep secret /etc/openvpn/*.conf</pre>

<p>
Создайте их заново с использованием
</p>
<pre>openvpn --genkey --secret SECRET_FILENAME</pre>

<p>
Затем скопируйте общие секретные ключи на удалённые узлы и перезапустите VPN
на каждом из узлов с помощью команды
</p>
<pre>/etc/init.d/openvpn force-reload</pre>

<h1><a name="proftpd">Proftpd</a></h1>

<p>
Пакет Debian не имеет возможностей создания ключей, поэтому следующие
шаги будут необходимы только в том случае, если ключи SSL были созданы внешней программой.
</p>

<p>
В грядущей загрузке proftpd в нестабильный выпуск будет добавлен шаблон tls.conf
с приведённым ниже комментарием.
</p>

<p>
Заметьте, что создание подписанного самостоятельно сертификата отличается от
того, что предлагается в общем разделе об openssl, для того, чтобы
избежать использование явного пароля при запуске службы.
</p>

<p>
Вы можете создать заново подписанный самостоятельно сертификат, используя следующую команду:
</p>
<pre>
 openssl req -x509 -newkey rsa:1024 \
         -keyout /etc/ssl/private/proftpd.key -out /etc/ssl/certs/proftpd.crt \
         -nodes -days 365
</pre>

<p>
Оба файла должны быть доступны для чтения только суперпользователю. Пути файлов можно
проверить/настроить через следующие директивы настройки:
</p>
<pre>
TLSRSACertificateFile                   /etc/ssl/certs/proftpd.crt
TLSRSACertificateKeyFile                /etc/ssl/private/proftpd.key
TLSCACertificateFile                    /etc/ssl/certs/CA.pem
TLSOptions                              NoCertRequest
</pre>

<h1><a name="puppet">puppet</a></h1>

<p>
Имеется два способа работы с сертификатами puppet, первый &mdash; через capistrano,
второй &mdash; вручную.
</p>

<p>
Создание заново сертификатов SSL для Puppet, используя capistrano, подробно описано здесь:
<a href="http://reductivelabs.com/trac/puppet/wiki/RegenerateSSL">http://reductivelabs.com/trac/puppet/wiki/RegenerateSSL</a>
</p>

<p>
Для создания сертификатов заново вручную, выполните следующие шаги:
</p>

<ol>
<li>Вам нужно удалить и создать заново вашу информацию CA:
<pre>
/etc/init.d/puppetmaster stop
rm -rf $vardir/ssl/*
/etc/init.d/puppetmaster start
</pre>
<p>
Тем не менее, если у вас запущен mongrel, вместо того, чтобы запускать puppetmaster с
помощью сценария инициализации, вам нужно будет сначала остановить интерфейс веб-сервера
(apache, nginx и т.д.), а затем выполнить следующую команду:
</p>
<pre>
puppetmasterd --daemonize ; sleep 30 ; pkill -f 'ruby /usr/sbin/puppetmasterd'
</pre>
<p>
Приведённая выше команда необходима потому, что если запущен mongrel,
puppetmaster не будет создавать CA.
</p>
</li>
<li>Очистите клиентские сертификаты
<pre>
/etc/init.d/puppet stop
rm $vardir/ssl/*
</pre> 
</li>
<li>Каждый клиент должен запросить новый сертификат:
<pre>
puppetd --onetime --debug --ignorecache --no-daemonize
</pre> 
</li>
<li>Когда все запросы получены, вы можете одновременно подписать их:
<pre>
puppetca --sign --all
</pre> 
</li>
<li>Запустите ваши puppet-клиенты:
<pre>
/etc/init.d/puppet start
</pre>
</li>
</ol>

<p>
Также вам следует временно включить autosign, если вам это подходит.
</p>

<h1><a name="sendmail">sendmail</a></h1>

<p>
Sendmail (и в Etch, и в Lenny) во время установки может создавать сертификаты OpenSSL
по умолчанию.
</p>

<p>
Замена ключа тривиальна:
</p>
<pre>
/usr/share/sendmail/update_tls new
</pre>

<p>
Если у вас имеются настроенные шаблоны в /etc/mail/tls, их
значения будут использованы для создания новых сертификатов.
</p>

<h1><a name="ssl-cert">ssl-cert</a></h1>

<p>
Сертификат /etc/ssl/certs/ssl-cert-snakeoil.pem может быть
создан заново с помощью следующей команды:
</p>

<pre>make-ssl-cert generate-default-snakeoil --force-overwrite</pre>

<h1><a name="telnetd-ssl">telnetd-ssl</a></h1>

<pre>
rm -f /etc/telnetd-ssl/telnetd.pem /etc/ssl/certs/telnetd.pem
dpkg-reconfigure telnetd-ssl
</pre>

<p>
Это подходит для настройки по умолчанию. Если локальный администратор дополнительно настроил
инфраструктуру SSL, эти ключи также следует создать
заново.
</p>

<h1><a name="tinc">tinc</a></h1>

<p>
Удалите все подозрительные публичные и частные файлы ключей:
</p>
<ol>
<li>Удалите rsa_key.priv.</li>
<li>Отредактируйте все файлы в каталоге hosts/ и удалите блоки публичных ключей.</li>
</ol>

<p>
Создайте новую пару ключей (публичный/частный):
</p>
<pre>
tincd -n &lt;netname&gt; -K
</pre>

<p>
Обменяйтесь файлом настройки вашего узла, содержащим новый публичный ключ, с другими
членами вашей VPN. Не забудьте перезапустить ваши службы tinc.
</p>

<h1><a name="tor">tor</a></h1>

<p>
Tor отсутствует в стабильном выпуске, но версия из Lenny уязвима.
</p>

<p>
Клиенты с запущенной версией 0.1.2.x не подвержены уязвимости. Узлы Tor или скрытые поставщики
сервиса с любой запущенной версией, а также любой с версией 0.2.0.x подвержены
уязвимости.
</p>

<p>
См.
<a href="http://archives.seul.org/or/announce/May-2008/msg00000.html">сообщение об
уязвимости</a> в списке рассылки объявлений Tor.
</p>

<p>
Рекомендуется обновиться до версии 0.1.2.19-3 (доступна в тестируемом выпуске, нестабильном выпуске, backports.org и
в обычном <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorOnDebian">репозитории
noreply.org</a>) или 0.2.0.26-rc-1 (доступна в экспериментальном выпуске и обычном <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorOnDebian">репозитории
noreply.org</a>). Если у вас запущен транслятор, установка этих версий приведёт к
созданию новых серверных ключей (/var/lib/tor/keys/secret_*).
</p>

<p>
Если вам нужно запускать узел Tor без использования инфраструктуры пакета
(пользователь debian-tor, /var/lib/tor как DataDirectory и т.д.), вам нужно будет
вручную удалить плохие ключи.  См. ссылку на рекомендацию, приведённую выше.
</p>

<p>
Если вы являетесь скрытым поставщиком сервиса и создали свой собственный ключ с
помощью уязвимой libssl, то удалите частный ключ вашего
скрытого сервиса. Это изменит имя узла вашего скрытого сервиса
и может потребовать перенастройки ваших серверов.
</p>

<p>
Если у вас запущена версия 0.2.0.x, настоятельно рекомендуем обновиться &mdash; 3 из
6 v3 серверов авторизации имеют скомпрометированные ключи. Старые версии 0.2.0.x
перестанут работать в течении недели или двух.
</p>

<h1><a name="xrdp">xrdp</a></h1>

<p>
xrdp использует созданные ключи. Большинство клиентов по умолчанию не проверяет
эти ключи, следовательно их изменение безболезненно. Вам лишь нужно выполнить следующие команды:
</p>

<pre>
rm /etc/xrdp/rsakeys.ini
/etc/init.d/xrdp restart
</pre>

<p>
xrdp отсутствует в стабильном выпуске.
</p>