Редактирование: Методы деанонимизации

{{Зрада}}

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

==Методы деанонимизации==

# Banner grabs of both eepSites inside of I2P, and against know IPs participating in the Darknet, to reduce the anonymity set of the servers. '''(сбор баннеров сервисов и т.п. и сверка их с аналогичными для IP адресов, участвующих в I2P (для известных нод I2P))'''
# Reverse DNS and who is lookups to find out more information concerning the IPs of the I2P nodes. '''(добыча информации при помощи whois и reverse dns lookup по найденым IP адресам)'''
# TCP/IP stack OS finger printing. '''(OS finger printing - удаленное определение типа ОС, можно полечить запретом сканирования портов, своевременным обновлением компонентов ОС, блокированием подозрительных пакетов и другими действиями, выполнять которые умеет большинство фаерволов для любой ОС)'''
# Testing I2P virtual host names on the public facing IP of I2P nodes. '''(проверяется, являются ли известные I2P ноды серверами, на которых хостятся сайты - то есть если имеются сайты shpargalko.i2p и shpargalko.ru то можно с большой долей вероятности утверждать что они администрируются одним и тем же человеком)'''
# Compare the clock of the remote I2P site, and suspected IP hosts on the public Internet, to our own system's clock. We did this via the HTTP protocols "Date:" header. '''(сравнивается время на сайте и время на вашем хосте - не забывайте почаще синхронизировать время компьютера с NTP-сервисами или резать заголовки)'''
# Command injection attacks. '''(удалённое несанкционированное выполнение команд)'''
# Web bugs to attempt to de-anonymize eepSite administrators or users. (This turned out more problematic than we originally thought) '''(использование ошибок в сайтах для деанонимизации администратора или пользователей - предотвратить это сложнее чем вы думаете)'''.

С моей точки зрения - побольше бы подобных исследований, потому что чувство защищённости, которое даёт I2P, потенциально заставляет нас уделять безопасности и анонимности меньше времени, думая, что I2P всё сделает за нас. Рекомендации данные в этой статье в любом случае полезны и помогут сделать сайты ещё анонимнее.

[http://www.irongeek.com/i.php?page=security/darknets-i2p-identifying-hidden-servers Источник].

==Известные случаи деанонимизации==

В русскоязычном сегменте [[I2P]] нашумел случай с деанонимизацией и взломом ресурса [[Times.i2p]]. Это стало возможным благодаря дыре в движке сайта, позволившей выполнить произвольный код на стороне сервера.

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

===Как этого избежать?===

Дыра достаточно тривиальная, поэтому лечится просто и несколькими способами (давно используемыми распространенными движками). Для всех способов нам потребуются файл .htaccess в той папке куда движок вашего сайта позволил загружать файлы пользователей и включенный mod_rewrite в Apache (для этого раскомментируйте строку '''LoadModule rewrite_module modules/mod_rewrite.so''' в файле httpd.conf).

* запрет загрузки php-файлов (1 способ) - вписать в файл .htaccess
 Options -Indexes
 php_flag engine 0
 AddType "text/html" .php .cgi .pl .fcgi
 .fpl .phtml .shtml .php2 .php3 .php4 .php5 .asp .jsp
 RemoveType php
* запрет загрузки php-файлов (2 способ) - вписать в файл .htaccess
 RemoveHandler .phtml .php .php3 .php4 .php5 .php6 .phps .cgi .exe .pl
 .asp .aspx .shtml .shtm .fcgi .fpl .jsp .htm .html .wml
 AddType application/x-httpd-php-source .phtml .php .php3 .php4 .php5
 .php6 .phps .cgi .pl .asp .aspx .shtml .shtm .fcgi .fpl .jsp .htm .html .wml
* запрет обращения к php-файлам в папках пользователей (дополнительный способ)

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

Для него нужно написать в файл .htaccess
     <Files *.jpeg>
      allow from all 
     </Files>
     <Files *.gif>
      allow from all 
     </Files>
     <Files *.png>
      allow from all 
     </Files>
     <Files *.jpg>
      allow from all 
     </Files>
 здесь можно написать еще кейсы
 для других типов файлов
 которые вы пожелаете разрешить загружать
     <Files *.bmp>
      allow from all 
     </Files>
     <Files *.zip>
      allow from all 
     </Files>
     <Files *.rar>
      allow from all 
     </Files>
     <Files *.tar>
      allow from all 
     </Files>
 deny from all

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

==Общий вывод==

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

[[Категория:I2P]]