Защита PHP-скриптов от анализа и модификации. Защита сайта php


Концепт защиты PHP сайта | Безопасность

Все мы, так или иначе, хотели бы быть уверенны в том, что наш сайт или блог никто не сможет взломать. Но увы, реальность такова, что любая система уязвима, как бы сильна она не была бы защищена. Все упирается лишь в ресурсы и в упорство взломщика… Хм… Что то меня не туда потянуло… Будем считать это предисловием =)

Не так давно я писал о том как правильно загружать файлы на сервер. Но допустим вы взяли уже готовую CMS и не знаете, как там реализованна загрузка, да и вобще вся защита. Конечно, особо пытливые и грамотные разработчики изучат код этой цмс прежде чем поставят на свой сайт. Но что делать тем у кого нет столько времени?

Хорошо, или допустим вы из тех кто считает что безопасность и правильная настройка сервера лишней не бывает? Если так то добро пожаловать под кат.

Нет, в статье вы не найдете какой-то супер пупер плагин, фильтрующий все данные, который нужно приинклудить ко всем файлам. Моя идея заключается в использовании директивы auto_prepend_file и постройки списка разрешенных файлов… Но в общем читайте сами…

Данная идея у меня давно сидела в голове, но наконец у меня дошли руки, хоть ничего сложного тут и нету, и я смог эту систему реализовать и написать статью =)

Принцип работы

Как я уже говорил выше, система основанна на работе директивы auto_prepend_file в php.ini. Отвечает она за установку скрипта, который будет выполнятся ПЕРЕД выполнением основного.

К примеру вы открыли index.php, а перед его выполнением запускается файл, указанный в auto_prepend_file. Суть в том, что в этом скрипте мы сможем контролировать дальнейшую работу остальных скриптов. Грубо говоря, продолжить работу и запустить запрошенный скрипт, или завершиться сразу (die()).

К примеру ситуация — злоумышленник залил на ваш сайт шелл через какую нибудь уязвимость и пытается его открыть в браузере. А вместо его шелла, ему, без всяких на то причин, отдается, вот такая вот ошибка:403_forbiddenМеня бы подобное ввело бы в ступор…

Для работы мой системы, нужен список разрешенных файлов, доступ к файлам, отсутствующим же в этом списке будет блокироваться.

Diagram_first

(Не знаю нужна ли эта диаграмма, вроде бы и так все должно быть понятно…)

Конечно составлять такой список вручную — дело не благородное, поэтому я пришел к выводу, что имеет смысл реализовать так называемый «режим обучения». Режим в котором все обращения ко всем скриптам будут заносится в список разрешенных файлов автоматически.

Diagram_second

Что это дает? Вы можете запустить эту систему в режиме обучения и продолжить пользоваться своим сайтом. По мере того как вы будете им пользоваться, ваша база будет пополнятся теми страницами, которыми вы пользуетесь (простите за каламбур). И допустим через месяц — другой у вас в списке будут содержаться все файлы которые имеют отношение к вашему сайту (к которым вы непосредственно обращались).

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

Что умеем

Так как это концепт, то и умеем мы не много.

  • Блокирование неразрешенных скриптов (собственно основная функция). Но опять же это настраиваемо, можно не блокировать соединение, а только лишь уведомлять админа по email
  • Уведомление о нелегитимных запросах администратору по email (краткий отчет или полный отчет, последний включает заголовки пакета и данные POST запроса если таковые имеются)
  • Можно указать IP администратора, который будет иметь доступ к любым скриптам, т.е. данная система его затрагивать не будет (эти IP не будут участвовать в режиме обучения). К примеру теперь не надо закрывать .htaccess-ом софтины типа PhpMyAdmin, SupexDumper и прочие системные утилиты.
  • Ксати Ip адреса поддерживают простенькие маски=)
  • Полностью прокомментированный код, и подробно описанна каждая директива конфигурации
  • Хз что еще…

Настройка

Теперь о том как встроить эту защиту в ваш сайт…

Для этого вам необходим доступ к файлу php.ini

  1. Для начала скачиваем сам скрипт: PrependSecuritySystem
  2. Распаковываем содержимое архива (data.txt и main.php) в какую либо папку на сервере, желательно в папку не доступную из веба (не обязательно, т.к. работать будет в любой, это имеет смысл чтобы убрать скрипт подальше от глаз взломщика)
  3. Открываем файл main.php и редактируем настройки. Необходимо обязательно поменять ip адрес и email админа. Остальные настройки же — по вашему желанию.
  4. Устанавливаем права доступа к распакованным файлам. Под никсами желательно изменить владельца для обоих файлов, отличного от пользователя из под которого работает веб сервер. Для файла main.php необходимо запретить запись для всех. Для файла data.txt необходимо установить права на чтение и на запись для всех (это временно, на период обучения)
  5. Открываем php.ini и вписываем следующее:auto_prepend_file=[путь до распакованного файла main.php]
  6. С данного момента начинается обучение системы. Выжидаем определенное колличество времени, достаточное, по вашему мнению, для полного обучения данной системы.
  7. По окончанию обучения открываем файл main.php и редактируем костанту PSS_STATUS_BLOCK, устанавливаем ее значение в true, сохраняем
  8. Изменяем права доступа на файл data.txt. Запрещаем редактирование данного файла для всех.
  9. Теперь система перешла в режим блокирования неразрешенных скриптов

Многовато шагов, конечно, но с этим, как мне кажется, справится даже ребенок.

Если вам необходимо переобучить систему (с нуля или дополнить), то вам необходимо:

  1. Разрешить запись в файл data.txt
  2. Очистить содержимое data.txt (ТОЛЬКО если вам необходимо переобучить систему с нуля)
  3. Отредактировать костанту PSS_STATUS_BLOCK в файле main.php, установив ее значение в false
  4. Проводим переобучение…
  5. По окончанию переобучения редактируем константу PSS_STATUS_BLOCK устанавливая ее значение обратно в true
  6. Запрещаем запись файла data.txt

Ну а теперь о грустном

Лукавить я не буду, и теперь расскажу о недостатках.

  • Пожалуй главный недостаток по сравнению с которым меркнут все остальные, это то, что эту систему можно обойти. Вы спросите: как же так? Все очень просто, директиву auto_prepend_file можно указать и в .htaccess. И если подойти трезво то если злоумышленник вдруг смог залить шелл, то наверняка он сможет залить и свой .htaccess в котором он может отключить оригинальную директиву.Это работает только под apache, но к примеру под nginx этот трюк не выйдет (у nginx нет файлов .htaccess). НО! Под Nginx можно вообще залить свой php.ini в любую папку и в этой папке будут действовать новые директивы.
  • Злоумышленник может отредактировать «разрешенный» скрипт если есть допустимые права на это, и с этим наша система ничего, к сожалению, сделать не сможет. Разве что необходимо устанавливать правильные права на все исполнемые файлы
  • Помимо PHP есть еще всякие perl, cgi и прочее… с ними данная система не работает.
  • Дополнительная нагрузка. Но вртяли эта нагрузка будет ощутима.

Именно поэтому, казалось бы такая оригинальная система, не может называться идеальной. Но она вполне подойдет в качестве простой превентивной меры, которая остановит не самых упоротых упертых взломщиков. По крайней мере данная система сможет отнять время у взломщика на проведение атаки. К примеру, система уведомит администратора о попытке взлома, дав тем самым администратору возможность устранить уязвимость до тех пор пока злоумышленник разберется с причиной его неудач.

Заключение

Все же, так или иначе, это концепт, может быть вы сможете придумать на ее основе что то лучшее. А может быть вас устроит моя система.

На мой взгляд разумной защиты много не бывает. Использовать что-либо подобное или нет, у вас на сайтах решать вам.

Фуф. Ну и написал я, почти целый день ушел. Простите если описал несколько сумбурно. В общем задавайте ваши вопросы в комментариях, я постараюсь ответить.

PS: хоть я и кодил максимально адекватно, скрипт может иметь баги. Тестировалось на win/apache/php 5.2 — все было ок.

UPD: запилил репозиторий на гитхабе: https://github.com/InSys/PrependSecuritySystem

intsystem.org

10 важных советов безопасности для защиты сайта от хакеров

Вы, наверное, думаете, что ваш сайт не представляет ценности для взлома, но это не так.  Web-сайт постоянно подвергается риску быть взломанным. Большинство взломов происходит не с целью украсть ваши данные или испортить web-сайт, а для того, чтобы использовать сайт для рассылки спама или производить какие-либо незаконные действия. Написано множество скриптов, которые бегают по Интернету в попытке найти сайты с известными проблемами безопасности. Ниже приводится 10 лучших советов, которые помогут сохранить ваш сайт в безопасности:

 

1. Регулярно обновляйте программное обеспечение

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

Об обновлении серверного программного обеспечения должна беспокоиться хостинг компания, так что вам, возможно, не стоит беспокоиться об этом.

Если вы используете программное обеспечение сторонних разработчиков, например, CMS, то вы должны убедиться, что версия актуальна на текущий момент. У большинства разработчиков есть RSS лента с описанием всех вопросов безопасности. WordPress и многие другие CMS уведомляют о доступных новых версиях системы.

 

2. SQL-инъекции

SQL инъекции — атака, когда хакер использует поле web формы или параметры URL строки с целью получения и манипулирования данными, хранящимися в базе данных. При использовании обычных SQL запросов можно вставить вредоносный код, который может изменить таблицы, получить информацию или удалить данные.

Рассмотрим пример:

"SELECT * FROM table WHERE column = '" + parameter + "';"

Если хакер изменит URL параметр и напишет ‘ OR ‘1’ = ‘1, тогда запрос будет выглядеть так:

"SELECT * FROM table WHERE column = '' OR '1'='1';"

Т.к. 1 = 1, то это позволит хакеру добавить дополнительный запрос в конец SQL запроса, который так же будет выполнен.

Вы можете легко предотвратить это, если будете всегда использовать параметризованные запросы.

 

3. XSS

Cross Site Scripting — атака, в которой злоумышленник пытается запустить вредоносный код для посетителей сайта. Нужно убедиться, что вы всегда проверяете данные, кодируете, обрезаете или удаляете все сторонние HTML вставки.

Посмотрим пример:

<html> <head> <meta http-equiv="refresh" content="5;url=<?=$_GET['url']?>"></meta> </head> </html>

Если мы занесем в GET переменную значение http://localhost/?url=»><script>alert(«XSS»)</script><!—, то мы получим XSS атаку.

 

4. Сообщения об ошибках

Будьте осторожны, когда даете слишком много информации в ваших сообщениях об ошибки. Например, вы пытаетесь залогиниться на вашем сайте. Вы должны использовать общие сообщения типа «Неправильное имя пользователя или пароль». Не надо уточнять, что именно, имя или пароль неверны, так как это позволит злоумышленнику понять, что он разгадал одно поле и может сконцентрироваться на другом.

 

5. Проверки на стороне сервера, проверки в формах.

Проверка данных должны быть, как в браузере, так и на стороне сервера. В браузере можно отловить простые ошибки и выделить поля, в которых допущены ошибки. Например, проверить на пустоту или на ввод только цифр. Однако, эти проверки могут быть легко пропущены и на сервер могут отправиться непроверенные данные. Если сервер не будет проверять входные данные, то это может привести к нежелательным последствиям.

6. Пароли

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

Многие пользователи не любят длинные, сложные пароли, однако, просто необходимо, чтобы пароль был не меньше 8 символов, включающие большие и маленькие буквы, цифры. Такой пароль поможет им сохранить их данные в безопасности.

Пароль должен храниться в зашифрованном виде. Можно использовать такие алгоритмы, как SHA. Во время авторизации будут сравниваться только зашифрованные данные паролей. Для дополнительной безопасности можно добавлять «соль» в пароль. Для каждого пароля должна быть своя «соль».

В случае взлома и кражи ваших паролей ничего страшного не произойдет. Хакер не сможет расшифровать пароли. Лучшее, что он может сделать — это использовать словарь паролей для подбора. При использовании «соли» пароли будут подбираться медленней, так как будет искаться хэш для «соли» и пароля, что трудоемко.

К счастью, во многих CMS уже встроены эти функции безопасности, хотя в некоторых, возможно, понадобится дополнительный плагин, который будет добавлять «соль» к паролям.

 

7. Загрузка файлов

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

Если у вас есть форма для загрузки файлов, то вы должны с огромным подозрением относится к загружаемым файлам. Если вы позволяете пользователям загружать изображения, вы не можете полагаясь на расширение файла или MIME тип, чтобы определить, что файл является изображением, как их можно легко подделать. Даже открыв файл и прочитав заголовки, или используя функцию для проверки размера изображения вы не сможете гарантировать полную защиту от подмены. Большинство изображений позволяют хранить раздел комментариев, которые могут содержать PHP код, который может быть выполнен на сервере.

Так что можно сделать, чтобы предотвратить это? В конечном итоге мы хотим, чтобы пользователи не могли запустить файлы, которые они загружают. Не рекомендуется полагаться на расширение файлов. Нередки случаи, когда на сервер поступал файл image.jpg.php.

Можно переименовать загружаемый файл и поставить ему правильное расширение или поставить файлу права CHMOD 0666 (файл не сможет быть выполнен). Можно создать .htaccess файл, который предотвратит обращение к файлам с двойным расширением.

deny from all <Files ~ "^\w+\.(gif|jpe?g|png)$"> order deny,allow allow from all </Files>

 

8. Безопасность сервера

Если вы сами настраиваете свой сервер, то необходимо знать некоторые вещи.

Убедитесь, что у вас установлен firewall и блокируются все несущественные порты. Если возможно, установите DMZ (демилитаризованная зона), обеспечивающую доступ к порту 80 и 443.

Для загрузки файлов на сервер, используйте только безопасные методы, такие как SFTP или SSH.

Если возможно, то запустите базу данных на другом сервере. Таким образом только ваш web-сервер сможет получить доступ к базе данных. В результате ваши данные будут лучше защищены.

Наконец, не стоит забывать об ограничении физического доступа к серверу.

 

9. SSL

SSL — протокол, который используется для обеспечения безопасности в Интернете. Всякий раз, когда вы передаете информацию между сайтом и web-сервером, используется сертификат безопасности. Но, если средства коммуникации не являются безопасными, злоумышленники могут получить сертификат и получить доступ к данным пользователей.

 

10. Средства безопасности

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

Есть много коммерческих и бесплатных продуктов, чтобы помочь вам в этом. Скрипты будут пытаться взломать ваш сайт, используя некоторые из предыдущих упомянутых методов, таких как SQL-инъекции.

Несколько бесплатных инструментов, которые стоит посмотреть:

  • Netsparker (Free Community Edition, доступна пробная версия). Хорошо подходит для тестирования SQL-инъекции и XSS.
  • OpenVAS. Хорошо подходит для тестирования известных уязвимостей, в настоящее время более 25 000. Но инструмент сложен в настройке и требует OpenVAS на сервере, который работает только на * Nix.

 

При получении результатов в первую очередь нужно сосредоточиться на важных вопросах.

Если вы хотите пойти дальше, можно вручную подвергнуть под угрозу ваш сайт путем изменения POST / GET значений.

Еще стоит попробовать протестировать формы, изменить значение POST, чтобы попытаться передать код для выполнения XSS или загрузить скрипт на стороне сервера.

Надеемся, что эти советы помогут вам поддерживать ваш сайт и информацию в безопасности. К счастью, большинство CMS имеют много встроенных функций безопасности, но все равно будет хорошо, если вы будете знать и понимать принципы безопасности.

 

Спасибо за внимание!

Подписываемся на рассылку! 😉

Остались вопросы? Задавайте их в комментариях, вместе разберемся! 😉

 

 

Автор статьи: Alex. Категория: Безопасность Дата публикации: 13.06.2013

alexdev.ru

Защита PHP-скриптов от анализа и модификации

У Вас в браузере заблокирован JavaScript. Разрешите JavaScript для работы сайта!

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

Защиты на уровне сервера:

Zend Encoder / Zend SafeGuard Suite - наиболее популярная коммерческая защита, модули для поддержки Zend обычно установлены на всех платных хостингах. Zend предоставляет привязку скриптов к доменам и ip, установку времени триальной работы скриптов и мощную обфускацию. Поддерживаются все операционные системы. В публичном доступе имеется несколько вариантов утилит для снятия Zend'а, все они представляют собой модифицированный PHP 4-й и 5-й версии. Старые версии Zend'а снимаются без проблем, в последних возникают сложности из-за обфускации исходного кода.

NuSphere NuCoder. Новая, активно развивающаяся коммерческая защита. На уровне собственных API предоставляет взаимодействие с защищаемыми скриптами, поддерживаются операционные системы Windows и Linux. Вследствие малой распространенности не устанавливается на обычных виртуальных хостингах, но вполне может быть установлена пользователями на выделенных серверах. Публичных декодеров нет.

SourceGuardian for PHP. Коммерческая защита, практически не встречается, на вирутальных хостингах не устанавливается. Позволяет устаналивать триальный срок работы скриптов с проверкой даты по внешним серверам точного времени, делать привязку защищаемых скриптов к серверам, ip-адресу, MAC-адресу сетевой карты, причем эти данные используются для расшифровки. Поддерживаются все операционные системы. Публичных декодеров нет.

phpSHIELD. Прототип SourceGuardian for PHP. После слияния двух разработчиков перестал развиваться как самостоятельный продукт. Основной функционал тот же самый, публичных декодеров нет.

ionCube PHP Encoder. Второй по популярности коммерческий продукт для защиты скриптов. После появления публичных декодеров для Zend стал все чаще использоваться и устанавливаться на виртуальных хостингах. Позволяет шифровать не только скрипты, но и шаблоны, xml-документы, изображения, бинарные файлы. Привязывает защищенные файлы к серверам, есть мощный обфускатор, поддерживаются все операционные системы. Публичных декодеров нет, но в некоторых случаях снимается deZender'ом.

PHTML Encoder. Малораспространенная коммерческая система защиты, предоставляет обычный функционал для продуктов такого типа, работает под всеми операционными системами. За отдельную плату можно приобрести исходные коды защиты и модифицировать их под свои нужды. Публичных декодеров нет.

DWebEncoder. Экзотическая защита под Windows, предназначенная для создания скриптовых презентаций и каталогов на компакт-дисках. В установленном виде представляет собой что-то типа самостоятельного web-сервера, на котором исполняются закодированные php-скрипты. Публичных декодеров нет.

PHP Compact. Защита скорее теоретическая, чем практическая. Разрабатывалась на одном из отечественных форумов, но похоже дальше авторских релизов дело не продвинулось. Декодеров нет, впрочем как и защищенных скриптов.

PHPCoder / eAccelerator. Дополнение с открытым кодом к старинным php-акселераторам Turck MMCache и eAccelerator. Переводит скрипты в байт-код с целью повышения скорости их выполнения. Есть версии модулей под Windows и Linux. Публичных декодеров нет, но возможно открытый код проекта как-то поможет в изучении.

Защиты на уровне исходного кода:

PHP LockIt!. Популярная коммерческая защита, встречается очень часто, в основном на скриптах зарубежных разработчиков. Позволяет устанавливать триальный срок работы скриптов, привязку к доменам и ip-адресам, сжимает скрипты штатными средствами php (gzinflate). Единственная сложность - хороший обфускатор. Различные версии защиты отличаются только модификацией модуля распаковки. Легко снимается как в ручном, так и в автоматическом режиме. Без обфускатора снимается в точности до исходного кода, с обфускатором требует дополнительной обработки.

CNCrypto. В свободном доступе нет даже демо-версии, анализ проводился по защищенным скриптам. Навесной модуль сложности в распаковке не представляет, защита держится только на хорошей обфускации исходного кода.

PHPCipher. Защита представляет собой он-лайн сервис. На сайт загружается архив с вашими скриптами и обратно скачивается уже защищенный. Платная лицензия позволяет подписывать защищенные скрипты своими данными и использовать для коммерческих целей. Бесплатная лицензия допускает использование только для личных нужд. Сама защита представляет собой защищенный Zend'ом php-модуль, который подключается к защищенным скриптам. После deZend'а модуля защиты и получения из него всех необходимых констант снимается полностью до исходного кода. Функции обфускатора нет.

ByteRun Protector for PHP. Коммерческий продукт, в зависимости от типа лицензии позволяет защищать скрипты как на уровне сервера, так и на уровне исходного кода. Серверная защита со стандартными возможностями, ничего особенного нет. Защита на уровне скриптов снимается очень легко автоматически и вручную. Публичного декодера на серверную версию нет.

SourceCop PHP Protector. Очень популярная у отечественных разработчиков защита. Представляет собой сильно замусоренный пустым кодом модуль защиты, который подключается через include к защищенным скриптам. Алгоритм декодирования очень простой, не вызывает никаких сложностей в ручном и автоматическом снятии. Во всех случаях снимается полностью до исходного кода, функции обфускатора нет. Есть небольшие особенности для частных случаев декодирования, но здесь они описаны не будут.

CodeLock. Еще одна популярная защита, отличный пример безграмотного программирования. Представляет собой приложение на php, позволяет кодировать как сами скрипты, так и результат их работы в браузере средствами javascript. Скрипты можно защищать паролем, но из-за бездарной реализации пароль легко узнать даже не снимая навесную защиту. Модуль защиты представляет собой замусоренный пустым кодом php-скрипт, который подключается к защищаемым скриптам. Алгоритм защиты очень простой, снимается полностью до исходного кода. Функции обфускации нет.

TrueBug PHP Encoder, с недавнего времени TrueBug PHP Obfuscator & Encoder. Очень интересный протектор для исследования. До версии 1.0.2 использовались стандартные средства php для gzip-компрессии, начиная с версии 1.0.3 авторами был разработан собственный алгоритм сжатия. В новом продукте TrueBug PHP Obfuscator & Encoder добавлена функция обфускации и оптимизации исходного кода. Единственное слабое место защиты - неизменный алгоритм декодирования скриптов, но сам алгоритм меняется для каждой версии защиты. После разбора защиты снимается легко в точности до исходного кода, естественно при условии что не был использован обфускатор.

Zorex PHP CryptZ. Защита, как и CodeLock, представляет собой приложение на php, для его работы требуется база MySQL. Модуль защиты - подключаемый скрипт на php, зашифрованный в несколько слоев. После разбора алгоритма снимается очень легко в точности до исходного кода. Функции обфускатора нет.

Free PHP Encoder. Бесплатный он-лайновый сервис для кодирования php-скриптов. Модуль защиты представляет собой подключаемый php-скрипт, накрытый Zend'ом, который надо скачать с сайта. После снятия Zend'а и разбора алгоритма защита легко снимается полностью до исходного кода. Алгоритм защиты неизменный, функции обфускатора нет.

gencoder. Скрипт на php, кодирование примитивное, стандартный base64. Большего внимания не заслуживает и практического интереса не представляет.

FREE Encrypted PHP. Бесплатный он-лайновый шифровщик файлов, выполняющий привязку к серверу и ограничение по времени работы скрипта. К зашифрованным скриптам подключается модуль расшифровки, накрытый ionCube. После открытия алгоритма расшифровки легко снимается.

Free Online PHP Obfuscator. Бесплатный он-лайновый шифровщик файлов, несмотря на слово "obfuscator" в названии, дополнительно сжимает и шифрует скрипты. Внешняя шифровка сложности в снятии не представляет, основная защита держится на обфускации текстовых строк и имен переменных.

Обфускаторы:

Особого интереса в плане изучения не представляют, все работают по одинаковому принципу: замена названий переменных на набор случайных символов, удаление комментариев, переносов строк и пробелов, использованных для форматирования кода. К ним относятся GridinSoft PHP Processor, Semantic Designs Obfuscator, PHP Defender, Raizlabs PHP Obfuscator, Obfusc, POBS, PHP UnReader, Code Eclipse и другие. По деобфускации различных скриптов есть полезная статья статья.Для определения чем защищены скрипты можете воспользоваться программой PCL's PHPiD. По всем вопросам "а где взять декодеры?" и "а как сломать?" обращайтесь к поисковым системам.

Взято здесь: www.manhunter.ru. Автор: ManHunter

htmlweb.ru

Проверенные способы защиты PHP

PHP является одним из самых популярных языков для веб-разработки на данный момент. В результате, хакеры постоянно ищут способы использования PHP сценариев для получения несанкционированного доступа или нанесения ущерба системе. Безопасность PHP кода необходима в любом веб-приложение, которое вы разрабатываете.

Для обеспечения безопасности PHP-приложения существует две основные категории методов защиты кода. Первая категория включает настройку самого интерпретатора PHP через файл php.ini, что оказывает влияние на безопасность приложения в целом. Вторая категория подразумевает использование проверенных методов программирования и написание безопасного кода для предотвращения использования уязвимостей.

Защита PHP с помощью php.ini

В PHP существует целый ряд настроек, которые влияют на безопасность ваших приложений. Этими настройками можно управлять с помощью файла php.ini. Контролируя саму работу PHP, вы снижаете потенциальный ущерб, который могут нанести ошибки.

Запретить Register Globals

До версии 4.2.0, PHP использовал глобальные переменные для предоставления доступа к входным переменным из запросов GET и POST. Эта функция была ликвидирована, поскольку она обеспечивает лазейку в безопасности. Злоумышленники могут использовать его для управления переменными в рамках различных сценариев. Но для обеспечения обратной совместимости PHP позволяет настраивать register_globals в php.ini. Когда эта опция включена, PHP работает в старом режиме и регистрирует глобольные переменные для входных значений. Чтобы обеспечить безопасность PHP, всегда следует выключать эту настройку. Избегайте использования сценариев, которым требуется register_globals, поскольку это обычно является признаком потенциально опасных или редко обновляемых сценариев.

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

PHP-сценарии могут использовать функцию fopen для чтения и записи файлов на файловой системе сервера. Это, конечно, очень нужная возможность. Тем не менее, она также может представлять угрозу безопасности. Ошибка в сценарии PHP может позволить злоумышленнику читать или переписывать системные файлы. К счастью, в PHP есть ряд параметров, которые позволяют контролировать, к каким файлам PHP может получить доступ.

Один из вариантов, который можно использовать в php.ini это open_basedir. Данный параметр принимает в качестве значения подкаталог, такой как /home/user/html/. Ввод/вывод интерпретатора ограничивается указанным подкаталогом, что предотвращает чтение и запись файлов за пределами данного подкаталога с помощью PHP.

Вы можете также использовать параметр safe_mode в php.ini для управления доступом к файлам. В безопасном режиме PHP способен открывать только те файлы, которые принадлежат тому же пользователю, что и веб-сервер. Настройка также предотвращает запуск исполнимых файлов с помощью PHP. Если нужно разрешить PHP доступа к файлам, которые принадлежат разным владельцам, можно использовать safe_mode_gid. Параметр ограничивает доступ в PHP только теми файлами, которые принадлежат группе, под которой работает веб-сервер.

Сокрытие PHP

Хотя обеспечения безопасности путем внесения неясности недостаточно для защиты приложения, это усложнит попытки взлома, поскольку хакеры не будут знать, какие технологии вы используете. PHP выдает себя по ряду признаков, среди которых заголовки и подпись Apache. Это можно отключить с помощью expose_php = off в php.ini.

Ещё один признак, который выдает PHP, это отображение ошибок. Ошибки часто включают в себя информацию о путях и других параметрах, которую хакер найдет неоценимой. Сообщения об ошибках являются бесценными в процессе разработки для тестирования и отладки, но они должны быть выключены при введении приложения в эксплуатацию. Вы можете их отключить, установив: display_errors = Off в php.ini. Полезной функцией является запись сообщений об ошибках в лог-файл, которую можно включить, установив: log_errors = On в php.ini.

Наконец, можно настроить Apache для перезаписи URL, чтобы скрыть расширение PHP.

Использование проверенных методов программирования

После обеспечения безопасности PHP настройкой php.ini, необходимо обратить внимание на сам код. Другим методом защиты PHP является хорошая техника программирования. Есть целый ряд проверенных методов программирования, но не меньше методик, которые нужно избегать.

Контроль POST и передачи форм

Подмена форм (form spoofing) является распространенным видом атаки на веб-сайты.. Обычно это делается путем создания POST-запроса и отправки его по URL адресу, указанному в атрибуте action на форме. Чаще всего, подмена бывает безвредной, но раздражающей, например, когда спамеры отправляют спам сценариям, которые обрабатывают форму обратной связи. Тем не менее, подмена формы может быть опасной. Некоторые разработчики считают, что использование раскрывающегося списка на форме может ограничить пользовательский ввод. После этого они не проверяют данные, введенные пользователем, потому что считают, что форма выполнила проверку для них. Это может быть опасно, если кто-то отправит сценарию данные, не используя форму. Переданные данные не будут ограничиваться списком выбора.

Одним из способов защиты от подмены формы является использование одноразовых маркеров. Генерируйте случайные маркеры и храните вместе с сессией. Затем с помощью скрытых полей ввода отправляйте одноразовые маркеры как часть формы. При обработке формы сравните маркер в сессии и маркер на форме. Если они совпадают, обработайте форму, если нет – выведите сообщение об ошибке. После обработке следует удалить маркер из сессии.

Одноразовые маркеры не дают стопроцентной защиты. Даже если вы используете систему маркеров, всегда проверяйте ввод при обработке формы.

Защита баз данных

При работе с базами данных вы не должны использовать динамические SQL операторы, которые основаны на пользовательском вводе. Это создает реальную возможность для злоумышленников направить неправильные данные в базу данных. Иногда вы должны использовать вводимые пользователем данные в запросе SQL. Проверяйте введенные пользователем данные, прежде чем использовать их в запросе. Если база данных MySQL, вы можете использовать функцию mysql_real_escape_string(). Эта функция удалит недопустимые символы, эффективно обрабатывая пользовательский ввод. Если ваш код использует PHP функциональность magic_quotes_gpc, сейчас самое время пересмотреть назначение кода. Использование magic_quotes_gpc будет прекращено в PHP версии 6.

Еще записи по теме

live-code.ru

Защита сайта htaccess или waf своими руками

Обеспечить защиту сайта проще всего используя файл htaccess, находящийся к коневой веб папке.

В этой статье мы собрали максимально количество инструкций, позволяющих защититься от различного рода атак.Вставляя необходимые блоки в ваш файл, вы сможете отключать/выключать необходимые правила.

Следует помнить что после внесенных изменений с файла .htaccess необходимо убрать права на запись, оставив только права на чтение.

И так начинаем формировать файл htaccess …

Включаем перенаправления. Далее нам они понадобятся.RewriteEngine On

Выключаем сигнатуры сервера для защиты от определения используемого программного обеспечения через служебные заголовки сервера.ServerSignature OffOptions -IndexesDirectoryIndex index.php index.html index.htm

Определяем правильные ответы на коды ошибок «запрещено» и «страница не найдена».ErrorDocument 400 defaultErrorDocument 401 defaultErrorDocument 403 "Forbidden"ErrorDocument 404 "Page Not Found"

Выключаем потенциально опасные директивы php, в зависимости какая версия используется.Для PHP4.xphp_flag magic_quotes_gpc offphp_flag magic_quotes_runtime offphp_flag register_globals offДля PHP 5.xphp_flag display_errors offphp_flag magic_quotes_gpc offphp_flag magic_quotes_runtime offphp_flag register_globals off

Переходим непосредственно к правилам WAF — Web Application Firewall. Часто его продают за отдельные большие деньги, но частично функции можно реализовать подручными средствами.

Блокируем все типы запросов, кроме стандартных GET и PUTRewriteCond %{REQUEST_METHOD} ^(TRACE|DELETE|TRACK|DEBUG) [NC]RewriteRule .* - [F,L]

Защита от DDoS через атаку на параметр RangeRewriteCond %{REQUEST_METHOD} ^(HEAD|GET) [NC]RewriteCond %{HTTP:Range} ([0-9]*-[0-9]*)(\s*,\s*[0-9]*-[0-9]*)+RewriteRule .* - [F]

Защита от LFI (Local File inclusion) и RFI (Remote file inclusion)RewriteCond %{QUERY_STRING} ![a-zA-Z0-9_]=http://%{HTTP_HOST}/RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http:// [OR]RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=https:// [OR]RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=ftp:// [OR]RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=gopher:// [OR]RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=(\.\.//?)+ [OR]RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=/([a-z0-9_.]//?)+ [OR]RewriteCond %{QUERY_STRING} (\.\./|%2e%2e%2f|%2e%2e/|\.\.%2f|%2e\.%2f|%2e\./|\.%2e%2f|\.%2e/) [OR]RewriteCond %{QUERY_STRING} \=\|w\| [NC]RewriteRule .* - [F,L]

Запрещаем доступ к системным файлам в которых могут содержаться пароли доступа.RewriteCond %{QUERY_STRING} ^(.*)/self/(.*)$ [NC,OR]RewriteCond %{QUERY_STRING} ^(.*)cPath=http://(.*)$ [NC,OR]RewriteCond %{QUERY_STRING} (localhost|loopback|127\.0\.0\.1) [NC,OR]RewriteCond %{QUERY_STRING} (\.{1,}/)+(motd|etc|bin) [NC,OR]RewriteCond %{QUERY_STRING} \$_POST [NC,OR]RewriteCond %{QUERY_STRING} wp-config.php [NC,OR]RewriteCond %{QUERY_STRING} (javascript:).*(;).* [NC,OR]RewriteCond %{QUERY_STRING} \=PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC,OR]RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC,OR]RewriteCond %{QUERY_STRING} ^(%2d|\-)[^=]+$ [NC]RewriteRule .* - [F,L]

RewriteCond %{THE_REQUEST} (%0A|%0D|\\r|\\n) [NC,OR]RewriteCond %{THE_REQUEST} cgi-bin [NC,OR]RewriteCond %{REQUEST_URI} owssvr\.dll [NC,OR]RewriteCond %{REQUEST_URI} server-status [NC]RewriteRule .* - [F,L]

RewriteRule /DOCUMENT_ROOT - [F,L]RewriteRule /_mem_bin - [F,L]RewriteRule /msadc - [F,L]RewriteRule /_vti_bin - [F,L]RewriteRule /_vti_inf.html - [F,L]

<FilesMatch "\.(cfg|pl|htaccess|htpasswd|ini|phps|fla|psd|log|sh|sql|inc|tpl|svn|git|cvs|phtml|asp)$">Order Allow,DenyDeny from All</FilesMatch>

Защита от атак ShellShockRewriteCond %{QUERY_STRING} (\s*)\s*{\s*:;\s*};RewriteCond %{THE_REQUEST} (\s*)\s*{\s*:;\s*};RewriteCond %{HTTP_REFERER} (\s*)\s*{\s*:;\s*};RewriteCond %{HTTP_USER_AGENT} (\s*)\s*{\s*:;\s*};RewriteRule .* - [F,L]

Закрываем доступ к вашему сайту ряду сайтов.RewriteCond %{QUERY_STRING} ^.*(http|https|ftp)(%3A|:)(%2F|/)(%2F|/)(w){0,3}.?(blogger|picasa|blogspot|tsunami|petapolitik|photobucket|imgur|imageshack|wordpress\.com|img\.youtube|tinypic\.com|upload\.wikimedia|kkc|start-thegame).*$ [NC,OR]RewriteCond %{THE_REQUEST} ^.*(http|https|ftp)(%3A|:)(%2F|/)(%2F|/)(w){0,3}.?(blogger|picasa|blogspot|tsunami|petapolitik|photobucket|imgur|imageshack|wordpress\.com|img\.youtube|tinypic\.com|upload\.wikimedia|kkc|start-thegame).*$ [NC]RewriteRule .* index.php [F,L]

Часто уязвимая компонента TimThumbRewriteCond %{HTTP_REFERER} ^.*%{HTTP_HOST}.*RewriteCond %{REQUEST_URI} (timthumb\.php|phpthumb\.php|thumb\.php|thumbs\.php) [NC,OR]RewriteCond %{REQUEST_URI} (uploadify/uploadify.php) [NC]RewriteRule .* - [F,L]

UserAgent’ы сканеров безопасности и автоматических взломщиковRewriteCond %{HTTP_USER_AGENT} (|’|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]RewriteCond %{HTTP_USER_AGENT} (;||'|"|\)|\(|%0A|%0D|%22|%27|%28|%3C|%3E|%00).*(libwww-perl|wget|python|nikto|curl|scan|winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner) [NC]RewriteRule .* - [F,L]

RewriteCond %{HTTP_USER_AGENT} "NT 5.1; SV1" [NC]RewriteRule .* - [F,L]

Защита от SQL иньекций и удаленного выполнения кодаRewriteCond %{QUERY_STRING} ^(.*)([-_a-z]{1,15})=(eval|chmod|chdir|mkdir|rmdir|whoami|uname|unzip|gunzip|grep|more|umask|telnet|ssh|ftp|which|mkmode|touch|logname|edit_file|search_text|find_text|php_eval|download_file|ftp_file_down|ftp_file_up|ftp_brute|mail_file|mysql|mysql_dump|db_query|file_get_contents)([^a-zA-Z0-9].+)*$ [OR]RewriteCond %{QUERY_STRING} ^(.*)(wget|shell_exec|passthru|popen|proc_open)(.*)$RewriteRule .* - [F,L]

RewriteCond %{QUERY_STRING} (|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]RewriteCond %{QUERY_STRING} (\|%3E) [NC,OR]RewriteCond %{QUERY_STRING} (|%3E) [NC,OR]RewriteCond %{QUERY_STRING} (\|%3E) [NC,OR]RewriteCond %{QUERY_STRING} (|%3E) [NC,OR]RewriteCond %{QUERY_STRING} (\|%3E) [NC,OR]RewriteCond %{QUERY_STRING} (|%3E) [NC,OR]RewriteCond %{QUERY_STRING} (\|%3E) [NC,OR]RewriteCond %{QUERY_STRING} (|%3E) [NC,OR]RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]RewriteCond %{QUERY_STRING} base64_(en|de)code[^(]*\([^)]*\) [NC,OR]RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]RewriteCond %{QUERY_STRING} ^.*(\(|\)||%3c|%3e).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*(\x00|\x04|\x08|\x0d|\x1b|\x3c|\x3e|\x7f).* [NC,OR]RewriteCond %{QUERY_STRING} (NULL|OUTFILE|LOAD_FILE) [NC,OR]RewriteCond %{QUERY_STRING} concat[^\(]*\( [NC,OR]RewriteCond %{QUERY_STRING} union([^s]*s)+elect [NC,OR]RewriteCond %{QUERY_STRING} union([^a]*a)+ll([^s]*s)+elect [NC,OR]RewriteCond %{QUERY_STRING} \-[sdcr].*(allow_url_include|allow_url_fopen|safe_mode|disable_functions|auto_prepend_file) [NC,OR]RewriteCond %{QUERY_STRING} (;||'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC,OR]RewriteCond %{QUERY_STRING} (sp_executesql) [NC]RewriteRule .* - [F,L]

Небезопасные системные компонентыRewriteRule /phpmy/ - [F,L]RewriteRule /phpmyadmin/ - [F,L]RewriteRule /phpMy/ - [F,L]RewriteRule /_phpmyadmin/ - [F,L]RewriteRule /pma/ - [F,L]RewriteRule /MyAdmin/ - [F,L]RewriteRule scripts/setup.php - [F,L]RewriteRule /backup - [F,L]RewriteRule dumper.php - [F,L]RewriteRule /admin/phpmyadmin - [F,L]RewriteRule /admin/pma - [F,L]RewriteRule /dbadmin - [F,L]RewriteRule /mysql-admin - [F,L]RewriteRule /mysqlmanager - [F,L]RewriteRule /mysql - [F,L]RewriteRule /phpadmin - [F,L]RewriteRule /phpmanager - [F,L]RewriteRule /phpmyadmin1 - [F,L]RewriteRule /phpmyadmin2 - [F,L]RewriteRule /phpMyAdmin-2 - [F,L]RewriteRule /php-myadmin - [F,L]RewriteRule /phpmy-admin - [F,L]RewriteRule /pma2005 - [F,L]RewriteRule /PMA2005 - [F,L]RewriteRule /p/m/a - [F,L]RewriteRule /pma - [F,L]RewriteRule /sqlmanager - [F,L]RewriteRule /sqlweb - [F,L]RewriteRule /typo3/phpmyadmin - [F,L]RewriteRule /webadmin - [F,L]RewriteRule /webdb - [F,L]RewriteRule /web/phpMyAdmin - [F,L]RewriteRule /xampp/phpmyadmin - [F,L]RewriteRule /myadminscripts/setup.php - [F,L]RewriteRule /mysqladmin - [F,L]RewriteRule /php-my-admin - [F,L]RewriteRule /phpmyadmin - [F,L]RewriteRule /websql - [F,L]RewriteRule /myadmin - [F,L]RewriteRule /sql/ - [F,L]RewriteRule /mysql/ - [F,L]RewriteRule /setup.php?dir - [F,L]RewriteRule /MSOffice/cltreq.asp - [F,L]RewriteRule ///?_SERVER[DOCUMENT_ROOT] - [F,L]RewriteRule //?_SERVER[DOCUMENT_ROOT] - [F,L]RewriteRule /pagead/test_domain.js - [F,L]RewriteRule /pagead/osd.js - [F,L]RewriteRule /pagead/expansion_embed.js - [F,L]RewriteRule /pagead/render_ads.js - [F,L]RewriteRule /pagead/atf.js - [F,L]RewriteRule (.*)\cmd.exe$ - [F,L]

Блокируем паразитный трафикRewriteCond %{HTTP_REFERER} iskalko\.ru [NC,OR]RewriteCond %{HTTP_REFERER} buttons-for-website\.comRewriteCond %{HTTP_REFERER} semalt.semalt\.comRewriteCond %{HTTP_REFERER} cenoval\.ruRewriteCond %{HTTP_REFERER} darodar\.comRewriteCond %{HTTP_REFERER} cenokos\.ruRewriteCond %{HTTP_REFERER} seoexperimenty\.ruRewriteCond %{HTTP_REFERER} gobongo\.infoRewriteCond %{HTTP_REFERER} adcash\.comRewriteCond %{HTTP_REFERER} websocial\.meRewriteCond %{HTTP_REFERER} cityadspix\.comRewriteCond %{HTTP_REFERER} luxup\.ruRewriteCond %{HTTP_REFERER} superiends\.orgRewriteCond %{HTTP_REFERER} socialseet\.ruRewriteCond %{HTTP_REFERER} screentoolkit\.comRewriteCond %{HTTP_REFERER} cur\.lvRewriteRule .* - [F]

RewriteRule ^cache/js/.+\.php\d{0,1}$ - [L]RewriteRule ^cache/css/.+\.php\d{0,1}$ - [L]RewriteRule ^cache/.+\.php\d{0,1}$ - [F,L]RewriteRule ^cache/.+\.php\d{0,1}$ - [F,L]RewriteRule ^tmp/ - [F,L]RewriteRule ^images/.+\.php\d{0,1}$ - [F,L]

RewriteCond %{QUERY_STRING} (^|&)tmpl=(component|system) [NC]RewriteRule .* - [L]RewriteCond %{QUERY_STRING} (^|&)t(p|emplate|mpl)= [NC]RewriteRule .* - [F]

RewriteRule ^(configuration\.php(-dist)?)$ - [F]

RewriteRule ^components/com_uddeim/captcha15\.php$ - [L]RewriteRule ^modules/mod_raxo_allmode/tools/tb.php$ - [L]RewriteRule ^plugins/system/GoogleGears/gears-manifest\.php$ - [L]RewriteRule ^plugins/content/jw_allvideos/includes/jw_allvideos_scripts\.php$ - [L]RewriteRule ^administrator/components/com_admintools/restore\.php$ - [L]RewriteRule ^administrator/components/com_akeeba/restore\.php$ - [L]RewriteRule ^kickstart\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !(\.php)$RewriteCond %{REQUEST_FILENAME} -fRewriteRule ^components/com_agora/img/members/ - [L]

RewriteRule ^administrator/?$ - [L]RewriteRule ^administrator/index\.(php|html?)$ - [L]RewriteRule ^administrator/index[23]\.php$ - [L]RewriteRule ^administrator/(components|modules|templates|images|plugins)/([^/]+/)*([^/.]+\.)+(jp(e?g|2)?|png|gif|bmp|css|js|swf|html?|mp(eg?|[34])|avi|wav|og[gv]|xlsx?|docx?|pptx?|zip|rar|pdf|xps|txt|7z|svg|od[tsp]|flv|mov)$ - [L]RewriteRule ^administrator/ - [F]

RewriteRule ^xmlrpc/(index\.php)?$ - [L]RewriteRule ^xmlrpc/ - [F]

RewriteRule ^includes/js/ - [L]RewriteRule ^(includes|language|libraries|logs|tmp)/ - [F]

RewriteRule ^(cache|components|modules|plugins|templates)/([^/]+/)*([^/.]+\.)+(jp(e?g|2)?|png|gif|bmp|css|js|swf|html?|mp(eg?|[34])|avi|wav|og[gv]|xlsx?|docx?|pptx?|zip|rar|pdf|xps|txt|7z|svg|od[tsp]|flv|mov)$ - [L]

Это далеко не все, но поможет в 90% случаях. Список постоянно обновляется. Следите за изменениями.

www.secbot.org

4+ простых способа защиты вашего сайта « Блог сайтостроителя

Сегодня, как никогда, приходится заботиться не только о том, чтобы сайт исправно функционировал и работал, но также и о безопасности сайта. Все чаще можно услышать о случаях взлома тех или иных сайтов. В некоторых случаях, конечно, это не правда, и является лишь пиаром, но реальные случаи взлома есть, это бесспорно.

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

Защищаем файл конфигурации от постороннего доступа

Обычно в каждой нормальной CMS файлы конфигурации защищены от лишних глаз. Но дополнительная защита никогда не бывает лишней. Да и не на каждой CMS есть такая защита и не каждый хостинг запрещает подключение удаленных файлов или своего файла удаленным сервером.

Для защиты файла конфигурации от постороннего доступа будем использовать файл .htaccess. Для этого в файл надо вписать:

<Files filename.php> Order Deny,Allow Deny from All </Files>

Где filename.php - имя файла конфигурации. Например, в WordPress необходимо будет вписать wp-config.php вместо имеющегося.

Запрет прямого обращения к определенному php файлу

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

<?php if ( basename($_SERVER['SCRIPT_FILENAME']) == 'filename.php' ) die ('Please do not load this page directly. Thanks!'); ?>

Где filename.php - файл, который необходимо защитить.

Защищаем директории от прямого обращения и просмотра

Старый дедовский способ защиты директорий - в каждую папку добавлять пустой файл index.html. Но это довольно долгое и нудное занятие. Хотя его и можно автоматизировать, но мы поступим иначе и снова воспользуемся файлом .htaccess, добавив в него всего одну строку:

Блокировка определенного IP-адреса или зоны адресов

Данный способ предназначен для защиты от спамеров или от ботов, которые проказничают на вашем сайте. Для защиты необходимо во всё тот же волшебный файл .htaccess добавить следующее.

<Limit GET POST PUT> Order Allow,Deny Allow from All Deny from 123.456.789.012 </Limit>

Где 123.456.789.012 - IP-адрес проказника. Если нужно закрыть целую зону, то нужно вписать 123.456.789 или можно даже 123.456. 😉

Методы дополнительной защиты сайта

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

Говоря об определенных движках и платформах

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

С детства не дружу с графикой и фотографией, а очень жаль. Но у кого есть склонности к этому, то можете пройти курсы фотографов. Даже если по профессии не будете этим заниматься, то для общего развития очень полезно будет.

А молодые специалисты в своём деле предлагают погрузиться в Интернет Маркетинг и познать тайны рекламы в интернете и продвижения бренда

Рейтинг 5 балла Просмотров: 1384

sitestroyblog.ru