Секьюрность некриптованного rsync-а.

[vitus_wagner]

Вот представьте себе, что есть сайт. Файлы на этот сайт выкладываются с помощью rsync, причем не с -e ssh, а с двумя двоеточиями после hostname. Кто не понял, зачем там два двоеточия, прекращает читать этот пост, читает man rsync, и возвращается сюда просветленный.

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

Алгоритм аутентификации у rsync-а хороший, весь из себя challenge-response, открытые пароли по сети бегать не будут.

Данные, выкладываемые на сайт, тоже вроде ничего сенситивного не содержат - файлы паролей для Basic Auth там внутри дерева не лежат, опция ExecCGI на всём, доступном для записи по rsync выключена, php и подобных тоже нету.

Comments

[http://users.livejournal.com/_slw/]

инжекции боимся?
в html тоже можно какой js инжектнуть, после которого и репутация сайта пострадает и вообще заблокировать могут

[qkowlew.livejournal.com]

Полагаю - всё-таки в данном случае речь о том, что "подслушают" и смогут ли использовать.

[alll]

> файлы паролей для Basic Auth там внутри дерева не лежат

Это они сейчас не лежат. А через год-два-пять - кто знает.

[vitus_wagner]

Для файлов паролей есть другое место в файловой системе. Куда, конечно, можно открыть rsync, но вот туда уже - только по VPN. Хотя удобнее будет докрутить web-ui к неим(который по https), чтобы позволял добавлять-удалять юзеров, а не только менять пароль текущему юзеру.

[qkowlew.livejournal.com]

Если ВСЯ информация, передаваемая по открытому протоколу - в конечном итоге доступна по открытому же протоколу http на страницах сайта - да, ничего страшного.

Да, если есть хотя бы один php или иной исполняемый скрипт, содержимое которого может стать известно злоумышленнику (подчеркну - не перезаписано злоумышленником, а просто известно) - то резко повышается опасность раскапывания его с целью применения его для XSS-атаки. Что тоже следует учитывать.

Я вот на одном сайте у себя на хостинге долго возился чтобы устранить XSS уязвимость. :(
После чего в собственный код умудрился посадить таковую. :)

[amarao-san.livejournal.com]

Если на сайте есть хоть какая-то авторизация, доступная JS'у (или динамические данные), то могут утырить, подсунув js для XSS mitm'ом.

[qkowlew.livejournal.com]

js читается и прямо с http сайта. Не аргумент.

[amarao-san.livejournal.com]

Я говорю про модификацию трафика, то есть "записать свой js" на сайт.

[vitus_wagner]

В смысле, есть известные способы обойти защиту от модификации, встроенную в протокол rsync?

[qkowlew.livejournal.com]

Ага. Нашёл живой пример со своего хостинга.
Имеем SSI код вида:

<!--#include-virtual="/cgi-bin/ibanner?li" -->

имеем структуру каталогов

domain.com/html/ - корень сайта
domain.com/cgi-bin/ - выполняемое cgi (специально разведено в сторону от корня)

Информация о том, какой тут есть исполняемый ibanner с параметрами - достаточно интересная для XSS и похожих по смыслу атак на сайт.

[vitus_wagner]

Ну это типичный случай как бы php - исполняемого на сервере кода, встроенного в html.

[qkowlew.livejournal.com]

"Более чистый пример" из и так анализируемого многими ботами-коллекторами - HTML FORM и ссылка в ней.

Короче - я со своим опытом хостингосерверного строения не могу найти действительно сильного аргумента за обязательное шифрование трафика в рамках поставленной задачи. Если так построивший сайт человек ДОСТАТОЧНО ДИСЦИПЛИНИРОВАН и не нарушает условий (например - ни разу не промахнулся с тем, куда положить .htpasswd файл).

Если же исходить из "средней практики" ошибок и недисциплинированностей - то прослушивание нешифрованного трафика нет-нет, да и принесёт слушающему больше информации, чем краулеру исследование html сайта.

Из смешного - я сейчас подумываю о том, чтобы для избежания кросс-сайт атак по файловой системе (из-за 777 прав на каталоги во многих CMS, догадливости ряда ботов и из-за обнаружения в них попыток перебирать ВСЕ комбинации символов!) сделать забавное изменение в структуре каталогов на шаред хостинге:

сейчас - /home/www/servers/xvid.ru/html - корень сайта xvid.ru
параноидально - /home/www/servers/${random1}/xvid.ru/${random2}/html - корень сайта xvid.ru
/home/www/servers/${random1}/xvid.ru/${random3}/cgi-bin - cgi-bin сайта xvid.ru

[vitus_wagner]

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

В общем, получилось, при условии, что все юзеры используют внешнюю по отношению к данному сайту (например OpenID) аутентификацию, либо мы готовы пойти на то, чтобы связаться со всеми юзерами, которые имели локальую аутентификацию, по имеющимся в открытом доступе контактам и сообщить им что "на клоне у вас пароль такой-то".

[qkowlew.livejournal.com]

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

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

[vitus_wagner]

Речь идет о том, что у желающего произвести клонирование, никакого доступа кроме как по http нет. Никакие дампы базы ему не доступны.

Вопрос именно о возможности форка форума при безвестном исчезновении админа или его неадекватном поведении.

[qkowlew.livejournal.com]

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

в первоначальной задаче ты написал "независимо от воли хостера"

Задача "независимо от воли админа форума" - ДРУГАЯ. :)