Как заблокировать вниз IIS7, не используя ограничения IP-адреса?

Как насчет некоторых ответов:

1. Настройки ACL для Wordpress на IIS (разорванная связь - посмотрите исходное содержание сообщения в блоге ниже),
2. Windows Cache Extension для PHP
3. Не игнорируйте кэширование, просто используйте то, что рекомендуется для IIS
4. Настройки стандартной установки для MySQL хорошо работают для малых и средних блогов Wordpress. Вы могли бы просмотреть эти подсказки по установке для пошагового процесса установки.
5. То, как защитить администраторский каталог Wordpress на IIS, является одной опцией.

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

Исходное содержание сообщения в блоге (полученный из http://web.archive.org/web/20100326200206/http://www.dscoduc.com/2009/11/acl-settings-for-wordpress-on-iis 10.11.2014):

Настройки ACL для WordPress на IIS

После получения моего WordPress ведут блог, я хотел удостовериться, что мой файл ACL был настроен правильно. Этот процесс немного отличается, чем конфигурирование BlogEngine.NET потому что выполнения WordPress с помощью олицетворения вместо разделенной сервисной учетной записи и анонимной учетной записи.

К сожалению, была добавленная сложность, я обновил свой веб-сервер для использования Windows 2008 R2, который имеет последнюю версию IIS, версии 7.0. Улучшения IIS 7.0 включают коренное изменение в способ, которым управляют идентификационными данными. А именно, IIS 7.0 использует две специальных учетных записи, которые не существовали в предыдущих версиях IIS: IUSR и IIS_IUSRS.

Больше информации об этих специальных учетных записях может быть найдено по IIS.NET на статье, названной, Поняв Встроенные Учетные записи Пользователя и Группы в IIS 7.0.

Таким образом, цель состояла в том, чтобы настроить уровень абсолютного минимума доступа, должен был выполнить блог. Для помощи в этом усилии, я провел время с Монитором Процесса Sysinternals для наблюдения за сообщениями ДОСТУПА ЗАПРЕЩЕН, когда я просмотрел блог и выполнил задачи администрирования.

Я запустил путем удаления наследуемых полномочий в корневой папке. Затем я удалил все учетные записи за исключением двух базовых учетных записей, которые требуются, чтобы управлять папкой: СИСТЕМА и Администраторы. Затем я дал ЧТЕНИЕ и разрешения LIST_FOLDER к IUSR и IIS_IUSR в корневой папке. С наследованными полномочиями, включенными по умолчанию на подпапках, этот ACL распространил бы вниз дерево папки.

Если бы я остановился здесь, то я смог бы подать содержание, но не мог бы изменить плагины и сообщения загрузки с вложениями. Я хотел, чтобы все функции блога работали так, я изменил полномочия папки wp-содержания добавлением, ИЗМЕНЯЮТ доступ для учетной записи IUSR, которую предоставления ИЗМЕНЯЮТ и Доступ для записи.

После последней установки ACL я проверил блог и нашел все работающее правильно. В конце концов, был сказан, и сделанный я только должен был настроить ACL в двух местах, корне и папке wp-содержания:

• c:\inetpub\wordpress
• c:\inetpub\wordpress\wp-content

ОБНОВЛЕНИЕ: После того, как я записал это сообщение, я решил удалить доступ для записи к/wp-content папка кроме тех случаев, когда я должен был обновить плагин. Дополнительно я должен был предоставить доступ для записи к/wp-content/uploads папка чтобы к сообщениям блог поддержек с вложениями и изображениями.

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

В конце единственные права, оставленные на для учетной записи IUSR, являются полномочиями чтения/списка для корня веб-сайта (который наследовался вниз через папки сайта), и разрешение чтения/списка/записи на папке загрузок.