консолидируйте файлы CMS в одном месте

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

Теперь, контролируйте свою сеть для любых поисков DNS и/или запросов ARP на их дюйм/с. Многие снифферы будут значением по умолчанию искать любые адреса, которые они находят, и таким образом любой поиск на этих устройствах был бы серьезным предупреждением.

Умный хакер мог выключить эти поиски, но многие не будут думать к, и это определенно замедлило бы его.

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

  1. Используйте полностью коммутируемую сеть
  2. Свяжите порты коммутатора с MAC-адресами
  3. Запретите включение неразборчивого режима на NICs (если это возможно, в Вашей среде)
  4. Используйте защищенные протоколы
1
задан 29 October 2009 в 12:13
2 ответа

Краткосрочное решение:

Переместиться

/admin/ 
index.php
etc...

к, скажем, /opt/cms

Создайте символьные ссылки для файлов к новому местоположению. т.е.:

$ ln -s /home/user/admin /opt/cms/admin
$ ln -s /home/user/index.php /opt/cms/index.php

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

Затем используйте SVN в/opt/cms каталоге, который связан со всеми.

Долгосрочное решение:

Устраните пользовательские каталоги полностью. Переместите приложение в одно единственное местоположение веб-сайта (/opt/cms или/var/www/cms, и т.д....). Используйте своего рода перезапись URL для создания example.com/~user/images/* точка к example/user/images/* и сделайте a /opt/cms/user/images каталог для каждого пользователя. Это решение означает, что пользователь не знает, что что-либо изменяется.

Долгосрочная перспектива, перепишите CMS, чтобы сохранить различие негласно, или сделать новую структуру и дать пользователям новый URL.

2
ответ дан 3 December 2019 в 22:45
  • 1
    сходство все больше, это могло бы быть единственным решением, точки, является Вашим :) –  robjmills 2 November 2009 в 16:24

Я не знаком с расположением файла Bespoke, но Вы думали о выполнении этого через svn:externals свойство?

Это позволяет Вам связывать 'внешний' репозиторий с местоположением в Вашем текущем репозитории. При наличии центрального репозитория, где Сделанные на заказ жизни (частный за Вашу организацию или общественность repos, если они предлагают один) связанный со всеми Вашими репозиториями проекта, это разберет прокручивающиеся вещи с SVN снимок.

При выполнении обновления svn или фиксации svn в местоположении в repos изменения будут вытягивать или морщить к внешнему repos и сохранять все в синхронизации.

svn:externals только поддерживает папки до версии 1.5, так быть уверенным, что Вы находитесь на 1,6 или выше таким образом, можно связать вещи как index.php к проекту правильно (если bespokes файлы не могут быть помещены в единственный каталог).

0
ответ дан 3 December 2019 в 22:45
  • 1
    спасибо, собираясь проверять внешний облик. К вашему сведению " Bespoke" не название CMS, это - CMS, мы создали внутренне использующий код, который сделан на заказ нам. –  robjmills 29 October 2009 в 13:06

Теги

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