Назад | Перейти на главную страницу

Лучшая практика для совместного использования или разрешения доступа к trac и svn для безопасности пользователей Интернета?

Что считается наилучшей практикой для предоставления доступа к trac и svn пользователям из Интернета, не связанным с компанией?

Должен ли он быть в DMZ, должен ли он быть внутренним с какой-либо формой SSH-соединения или с использованием https?

Если вы должны были сделать это и быть параноиком безопасности, каким должен быть список лучших практик, предполагающий базовый брандмауэр в глобальной сети, если сервер будет на своей собственной ноге в сети, как зона периметра (вдали от внутренних пользователей, двойной брандмауэр) .

заранее спасибо.

предполагая, что вы действительно параноик [также известный как избыточный сценарий]:

  1. поместите обратный прокси-сервер [например, используя apache2] в подсети с брандмауэром, сделайте его доступным только через https, только с выбранного IP-адреса внешних пользователей, которым необходимо получить к нему доступ [это защищает вас от слепых атак на возможные уязвимости в apache / svn / trac] . пересылать по нему только запросы на действительные URL [например, / svn и / trac] на фактический сервер, расположенный в отдельной подсети. убедитесь, что этот прокси-сервер может подключиться только к вашему фактическому серверу, только через порт 80 / tcp. ничего больше.
  2. поместите свой фактический сервер svn / trac в отдельную подсеть с контролируемым доступом: разрешите входящие HTTP-соединения изнутри вашей компании и с прокси. запретить исходящие соединения.

если ограничение доступа к # 1 для явного перечисления диапазонов IP не является вариантом - рассмотрите возможность использования привратника - опять же - чтобы избежать слепых атак.

на уровне прокси - рассмотрите возможность использования:

  • modsecurity чтобы избежать, например, атак sql инъекций / xss на trac,
  • fail2ban немного усложнить словарные атаки на механизм аутентификации svn / trac.

Стандартный сервер с доступом только по https - довольно безопасное решение с ограниченным количеством открытых портов и т. Д.

Параноидальная конфигурация может быть VPN (например openvpn) доступ для пользователей за пределами компании. Trac и svn будут доступны только из вашей частной сети и из VPN. Доступ пользователей к VPN будет защищен сертификатами, выданными вами. И, конечно же, никакой другой сервер и внутренняя сеть не будут доступны через VPN.

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

Если бы я делал это, я бы поместил trac в ящик за пределами основного корпоративного брандмауэра, но установил для него правила брандмауэра, чтобы блокировать доступ ко всему, кроме ssh (для меня) и http (для всех остальных).

Другой вариант - спросить себя: стоит ли нам вообще это размещать? Будет ли это лучше работать на sourceforge или savannah. {Non} gnu.org или github?

зависит от вашего бюджета.

попробуйте с брандмауэром спереди, разрешающим только доступ по https, и с двусторонним ssl на стороне Apache.