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

Безопасная установка Wordpress в подкаталог на сервере

наши маркетинговые дроиды хотели бы вести блог на нашем домене. Я проверил несколько, и хотя у MovableType меньше всего уязвимостей, Wordpress выиграл гонку.

Я очень скептически отношусь к установке программного инструмента, который часто используется на наших основных серверах. Однако власть имущие хотят, чтобы URL-адрес блога был www.domain.com/blog/ вместо blog.domain.com (что, конечно, позволило бы мне запустить блог где-нибудь на дешевом VPS).

Я всегда могу установить Wordpress, пройти через закалку и надеяться на лучшее. Или у кого-нибудь есть идея, как я могу вести блог в подкаталоге, сохраняя его отдельно, не влияя на функциональность? Я играл с проксированием в htaccess и т.д. безрезультатно. Мы запускаем LAMP и перед нами BIG IP-балансировщик нагрузки, если это поможет ...

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

Любые идеи?

Если вы следите за обновлениями и не устанавливаете какие-либо странные плагины, WordPress относительно безопасен. Он также относительно изолирован ... худшее, что сделает кто-то, кто взломает WP, - это испортит блог.

Три мысли ...

1- Не думайте о том, что WordPress требует отдельного поддомена. Несмотря на то, что WP относительно безопасен, его изоляция упростит вашу жизнь в будущем.

2- Реализация nginx перед балансировщиком нагрузки, и пусть он проксирует \blog запросы к blog.. Это хорошая долгосрочная топология.

3- Можно ли настроить балансировщик нагрузки на прокси / перезапись? Если вы укажете балансировщик нагрузки, вам может помочь.

Зависит от среды, и это предполагает, что вы используете Linux и Apache, возможно, какое-то решение LAMP, если это часто встречается из того, о чем я слышал.

Ваше объяснение звучит так, будто вы знаете, что делаете, но считали ли вы chroot / jail / как угодно называть это на жаргоне вашей ОС? Конечно, правильно подать все в среду chroot - это совсем другое дело, и именно здесь резина встречает вас на пути. Поскольку вы говорите о производственной среде, я полагаю, что это может быть проблемой для производительности и стабильности (опять же, я вижу множество документов, настаивающих на том, чтобы производственные службы более низкого уровня, такие как BIND DNS, работали в chroot, поэтому я сомневаюсь, что это так плохо; я имею в виду в смысле запуска другого chroot-ed экземпляра Apache вместе с вашим другим). Вы можете захотеть начало здесь для объяснения chroot для Apache. Я предполагаю, что если вы можете сделать это и MySQL, все готово.

Однако все это кажется излишеством. Вы сказали htaccess, так что для меня это определенно звучит как Apache. У вас есть балансировщики нагрузки. На мой взгляд, гораздо проще «съесть свой пирог и съесть его тоже». Я имею в виду, просто перепишите URL-адреса с вашими файлами conf Apache (что требует лишь немного навыков и тестирования) или заставьте балансировщик нагрузки сделать это (у меня его нет, но у некоторых коллег есть F5, и они говорят, что он может делать это на низком уровне, и это весело). В любом случае, выбирайте сами, первый абзац напрямую касается вашего вопроса. Хорошей охоты.