Dark Mind (Все сообщения пользователя)

Про кашу согласен.
Задачи безопасности WEB вообще и битрих в частности у меня подвесились только сейчас. Всегда был аутсорсинг. До этого приходилось заниматься только деструктивными задачами в части WEB, а конструктивными только в части работоспособности и безопасности всей корпоративной сети в целом.
Ну, не являюсь я WEB разработчиком и не хочу им становиться... Похоже битрих - это такой же геморрой, как и заказные конфигурации 1c. Факультативно с ним не справиться. Либо заниматься только этим (все равно, на остальное времени не останется), либо своей основной непосредственной работой...

Достаточно ли сcылки на приведенную документацию или лучше почитать по теме что-то ещё альтернативное? (Благо, завтра выходной...)

Дело в том, что с Корпорталом я ковырялся всего лишь дня четыре. Основной задачей был перенос виртуальной машины  из формата сплит-файлов, заточенных под VM Player в формат ESXi 5.1 и надувание /swap до 8GiB, а /home до 2TiB. Ну и, соответственно, разворачивание виртуальной машины на хост-сервере под Вымой Варю ESXi. Что уже успешно сделано.
Глубоко архитектуру движка Корпортала я еще не ковырял. Так, ткнул слегка палцем, а ...оно сразу и потекло...  Представляю, сколько еще натечет в процессе пуско-наладки...

В default-овом виде, еще даже до разворачивания конфигурации битриха я сразу же могу по прямой ссылке через tcp-80 прочитать любой файл, находящийся с каталогах уровнем ниже /home/bitrix/www без всякой авторизации.

В связи с этим вопросы, чтобы не тратить кучу времени на расковыривание архитектуры движка и обратный инженеринг:
Корпортал работает одновременно на двух WEB серверах в связке. Так?
Nginx работает непосредственно с php скриптами Битриха, а Apache работает в режиме WEB акселератора на отдачу. Так?
Соответственно, рубить доступ к прямым ссылкам лучше где, на Nginx или на Apache?
Предполагаю, что если рубить доступ в настройках Nginx, то это может привести к частичной неработоспособности конфигурации битриха. Может лучше начать ковырять доступ на стороне Apache?

Простейшим брутфорс-сканером

Предположим, нужно дискредитировать Фирму А, обвинив ее в нарушении 152 ФЗ.

Исходные данные для атаки:
самые интересные файлы могут лежать в upload/crm/xxxx/yyyy.*
cкорее всего, расширение интересующих нас файлов будет jpg (еще возможны варианты tif и pdf, но вероятность jpg существенно выше)
из демоверсии корпортала мы знаем что xxxx и yyyy это HEX в нижнем регистре, т.е набор символов 0123456789abcdef
xxxx - минимум 3 символа, yyyy - минимум 2 символа.

дальше пишется брутфорс-сканер под эти условия.

Это даже существенно проще чем взлом WPA.

Для дискредитации фирмы нам нужна доказательная база. Для формирования доказательной базы обвинения нам достаточно всего лишь одной картинки с персональными данными.

При условии, что это ночь и WAN канал свободен и его полоса пропускания хотя бы 4 Mibps на upload, за 4-5 часов работы этого сканера всего лишь с одного атакующего хоста очень высока вероятность, что поставленная задача будет решена.

А если атакующих хостов больше чем один?
А если сканер выполнить в виде недеструктивного трояна? (правда, если использовать торяна, то это уже 28 гл. действующего УК РФ, что практически бездоказательно в первых двух случаях)

После дискредитации Фирмы А, заказавшая атаку Фирма Б легко побеждает в тендере госконтрактов.
В тоже время Фирма А получает серьезные проблемы и теряет приличные деньги, скорее всего, превышающие стоимость коробочной версии Корпортала.

Полагаю, что это вполне реалистичный сценарий, без всякой паранойи и конспирологии

Взят на тест "Корпоративный портал" и уже, оплачена коробочная версия.

Естественно, руководство решило этот вопрос без учета моего мнения по теме.
На кор-портале планируется хранить и оперативно работать с большим объемом конфиденциальных и персональных данных, включая сканы документов, удостоверяющих личность.

В результате тестирования выяснилось следующие: Все файлы, находящиеся в каталоге /home/bitrix/www доступны к просмотру и открытию по tcp-80 без авторизации на протале, конечно при условии что из browser-a будет обращение по прямому пути типа:
myhost.mydomain/upload/crm/1c3/05.gif
myhost.mydomain/upload/disk/0ff/0fffde52bcb09215bdaa524fd31ec8d6.docx
(это примеры живых ссылок из развернутой демы)

Так и задумано?

А если там скан паспорта прикленный к lid-у? Не будет ли это явным нарушением 152 ФЗ со всеми вытекающими последствиями?

Ну, в локалке то - хрен бы с ним. Шибко грамотных, имеющих злой умысел в конторе, вроде, нет...
Однако, снаружи это работает абсолютно так же как и изнутри. А вот это уже совсем не Ice.

В связи с этим вопрос: так можно ли хранить конфиденциальные и персональные данные в Битрикс Кор-портал или нет?

Нужно ли глушить на смерть tcp-80 к Кор-порталу из внешки, а внешних корпоративных пользователей пускать к порталу в локалке только over VPN?

Если только через VPN, то я очень слабо себе представляю, как например с I-Phone с динамическим серым IP over 3G/LTE поднять IPSec к корпоративному VPN шлюзу.
Ну пусть даже не IPSec, а всего лишь L2TP, но все равно это весьма нетривиальная задача для железяк с "Андрюшкой" на борту, хотя в некоторых случаях решаемая.
А после того как я начинаю думать о планшетах и смартфонах от Apple, весьма популярных среди руководства, у меня вообще волосы встают дыбом от ужаса.

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

ЗЫ: Я не понимаю, почему в SQL базе хранятся ссылки на файлы, находящиеся в upload, вместо того, чтобы их хранить как BLOB поля непосредственно в SQL базе!!!
Тогда бы доступ к хранящимся документам по прямой ссылке без авторизации был бы действительно невозможен!
Я понимаю, что в этом случае SQL Server пришлось бы выносить на отдельный и достаточно производительный хост, но тогда бы не было такой дыры в безопасности.