Вопросы Теги

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

Главным образом просто проявите осторожность, Вы всегда должны:

  • Всегда сохраняйте свою ОС полностью исправленной
  • Не открывайте порты для внешней стороны, если Вы не имеете к. Сканирование nmap может помочь Вам узнать, есть ли у Вас что-либо открытое, Вы не можете знать. Завершите работу этих сервисов, заставьте их послушать на localhost только или проверьте, что они безопасны (полностью исправленный, безопасные пароли и т.д.)
  • При использовании горячей точки всегда предполагайте, что весь трафик зарегистрирован и проанализирован. Т.е. только работайте по надежно зашифрованному соединению, т.е. зашифровал VPN, SSH, HTTPS или подобный.
  • Не игнорируйте предупреждения, которые Ваши зашифрованные соединения дают Вам (плохой сертификат SSL и т.д.).

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

Если необходимо использовать загрузки различных сервисов по сети, VPN является, вероятно, самым легким решением. При необходимости всего в одном сервисе (определенный веб-сайт, некоторый удаленный вход в систему), вероятно, легче использовать шифрование прикладного уровня, такое как HTTPS или SSH.

Если сервис/протокол не использует шифрование, туннель SSH может также быть полезен и легче установить это полноценная VPN.

2
задан 28 January 2010 в 22:54
4 ответа

принятие Вас является параноидальным действительно [иначе сценарий излишества]:

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

если ограничение доступа к № 1 для явного списка диапазонов IP не является опцией - полагают, что некоторая форма привратника - снова - избегает слепых нападений.

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

  • modsecurity для предотвращения, например, внедрения SQL/xss нападает на trac,
  • fail2ban для создания атак с подбором по словарю на механизме аутентификации svn / trac немного тяжелее.
2
ответ дан 3 December 2019 в 12:22

зависит, каков Ваш бюджет.

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

0
ответ дан 3 December 2019 в 12:22

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

Другая опция могла бы состоять в том, чтобы спросить себя: мы должны размещать это вообще? Это работало бы лучше в SourceForge или саванне. {Не} gnu.org или GitHub?

0
ответ дан 3 December 2019 в 12:22
  • 1
    я думал то же самое, я скорее буду убеждать компанию размещать его и просто сохранять резервные копии данных. –   28 January 2010 в 23:38

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

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

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

0
ответ дан 3 December 2019 в 12:22
  • 1
    да это - другой хорошо решение, но слишком много развернуть другому клиенту или контракту. если бы это было только для одного клиента, то это было бы прекрасно, но это должно было бы поддерживать их другие клиенты, таким образом, вещи закончат тем, что стали грязными. обратный подход прокси на самом деле позволяет Вам использовать основной веб-браузер. –   1 February 2010 в 04:13

Теги

Похожие вопросы