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

ЗРАДА! Информация была грубо перекатана со свидомой википедии. Требуется дополнить её фактами, разбавить картинками, переписать или хотя бы почистить от мусора.

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

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

1. 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))
2. Reverse DNS and who is lookups to find out more information concerning the IPs of the I2P nodes. (добыча информации при помощи whois и reverse dns lookup по найденым IP адресам)
3. TCP/IP stack OS finger printing. (OS finger printing - удаленное определение типа ОС, можно полечить запретом сканирования портов, своевременным обновлением компонентов ОС, блокированием подозрительных пакетов и другими действиями, выполнять которые умеет большинство фаерволов для любой ОС)
4. Testing I2P virtual host names on the public facing IP of I2P nodes. (проверяется, являются ли известные I2P ноды серверами, на которых хостятся сайты - то есть если имеются сайты shpargalko.i2p и shpargalko.ru то можно с большой долей вероятности утверждать что они администрируются одним и тем же человеком)
5. 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-сервисами или резать заголовки)
6. Command injection attacks. (удалённое несанкционированное выполнение команд)
7. Web bugs to attempt to de-anonymize eepSite administrators or users. (This turned out more problematic than we originally thought) (использование ошибок в сайтах для деанонимизации администратора или пользователей - предотвратить это сложнее чем вы думаете).

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

Источник.

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

В русскоязычном сегменте 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 - не место где вы можете похвастаться своей способностью написать целый движок для сайта, или своим нежеланием постоянно следить за заметными и не очень потенциальными и явными дырами в своем сайте в частности и в своей машине в общем. Если собрались поднимать сайт на своем или просто редком движке - потрудитесь предварительно его хорошенько протестировать. Если собрались поднимать сайт на популярном и проверенном многими движке - потрудитесь приобрести хотя бы минимальные знания в обеспечении локальной безопасности.