Главная / Блог / Безопасность Cайта

Безопасность Cайта

1191

08.10.2018

Обновлено: 29.06.2020

Время прочтения: 20 минут

Василий Кулик программист

Кулик Василий

Безопасность Cайта

Вступление:

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

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

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

Хостинг, или VPS
Хостинг, безусловно, более доступный в плане ценовой политики, для хранения сайтов в сравнении с выделенным сервером (VPS / VDS). Для ответа на вопрос о безопасности, предлагаю рассмотреть недостатки хостинга:

В отличии от хостинга VPS /VDS открывает возможность самостоятельной установки с настройкой ОС, конфигурации сервера, и интерпретатора индивидуально, для каждого проекта. Из-за отсутствия сайтов-соседов безопасность зависит только с Вашей стороны. Аренда VPS / VDS заметно дороже, но в соображении безопасности оно того стоит!

Защита панели хостинга
Если атакуемый хакерами сайт написан на чистом коде качественно, то это толкает на крайние меры — взлом хостинга (сервера), а точнее подбор пароля в панель хостинга. Сайт — это файлы с программным кодом, которые хранятся на сервере и обрабатываются при запросе клиента (браузера), для получения конкретной страницы. В этой ситуации безопасность сервера очень важна. Риски взлома возрастают из-за наличия некачественных по коду сайтов-соседов, которые можно очень легко взломать и навредить Вашому ресурсу. На многих хостингах и серверах панель управления не защищена 2-х уровневой авторизацией. К примеру, подтверждение входа, после ввода правильного логина и пароля через почту, или СМС. Не исключение, что в готовых панелях, например, VestaCP возможны уязвимости. Для более высокой безопасности рекомендательно собрать свой сервер, установив на него ОС класса Unix. После этого шансы взлома сервера резко уменьшаются за счет отсутствия панелей управления и некачественных сайтов-соседов, собранных на готовых CMS, Framework.

Fail2Ban
Эта программа блокирует все IP-адреса вредителей, усердно пытающихся подобрать пароль, например, к FTP, файловому менеджеру, консоли SSH. Устанавливается только на выделенный сервер вместе с панелью VestaCP, или отдельно, если панель управления сервером отсутствует.

Безопасность FTP
По умолчанию на серверах и хостингах 21 порт (ФТП) открыт для всех и подобрать пароль не составит труда. Эффективный способ защиты - это закрытие 21 порта FTP для всех, с помощью файла ".ftpaccess" помещенного в базовую директорию, разрешенную для Apache:

<Limit ALL> Deny from all </Limit>

В примере выше доступ по ФТП закрыт всем, а это значит, что подбор пароля невозможен. Но если требуется регулярно использовать 21 порт для обмена файлами с сервером — напишите скрипт, который после успешной многоуровневой авторизации допишет в файл Ваш IP и всех авторизованных юзеров, а после завершения использования ФТП - удалит IP с файла.

<Limit ALL> Deny from all Allow from 130.180.211.174 </Limit>

Модуль mod_sequrity
Безопасность в основном зависит от сценариев и программистов, которые их пишут, но для защиты нужно использовать по максимуму все возможности. Модуль mod_security анализирует входящие HTTP-запросы на сервер и принимает решение, пропускать запрос, или нет, на основе заданных администратором правил. Идентичность работы модуля сравнима с сетевым экраном встроенного в ОС.

Установка молудя возможна после скачивания с сайта www.modsecurity.org. Загруженный файл модуля необходимо положить в папку "modules" и включить его в конфигурационном файле Apache httpd.conf, после чего перезагрузить сервер.

Рассмотрим дополнительные, не менее важные правила фильтрации запросов:

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

Модуль mod-evasive

Защитой от DDOS атак в Apache служит модуль mod-evasive для отслеживания количества HTTP-запросов к сайту и страницам, за указаный промежуток времени с конкретного IP и его блокировке на определенное время, при нарушении заданных условий.

После занесения в черный список IP злоумышленника, при попытках открыть сайт снова, приложение Apache все-равно открывается, но теперь вместо страницы сайта, будет возвращена ошибка с кодом 403. Иначе говоря, конкретной блокировки IP нет. В этом случае, Apache не тратит ресурсы и время на вызов PHP, а сразу выдает error 403.

Посылая запросы в большом количестве, http сервер Apache вынужден отклонять их с кодом ответа 403, забирая при этом все ресурсы сервера на эти действия. Если Вы пользуетесь выделленым сервером, mod-evasive устанавливать стоит, поскольку сервер будет легче положить, если на запросы хакера Apache будет вызывать ещё и приложение PHP.

Установка в Ubuntu запускается командой:

sudo apt-get install libapache2-mod-evasive

Для создание файла настроек запустите команду:

sudo touch /etc/apache2/mods-available/mod-evasive.conf

Откройте файл настроек:

sudo nano /etc/apache2/mods-available/mod-evasive.conf

Вставьте и настройте условия для mod-evasive:

<IfModule mod_evasive20.c> DOSHashTableSize 4096 DOSPageCount 5 DOSSiteCount 50 DOSPageInterval 1 DOSSiteInterval 1 DOSBlockingPeriod 300 DOSEmailNotify admin@site.com </IfModule>

Описание доступных опций:

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

sudo a2enmod mod-evasive sudo service apache2 restart

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

Запрет на выполнение сценариев в ненужных местах
Возможность запустить скрипт в папке, служащей для хранения изображений, CSS и JavaScript кода может привести к неожиданным последствиям, а запретить подобное достаточно просто. Для этого создайте файл ".htaccess" и положите в папку, в которой необходимо запретить выполнение кода:

<FilesMatch "\.([Pp][Hh][Pp]|[Cc][Gg][Ii]|[Pp][Ll]|[Ph][Hh][Tt][Mm][Ll])\.?.*"> Order allow,deny Deny from all </FilesMatch>

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

Ещё один способ запрета выполнения скриптов - это команда отключения запуска PHP-движка в файле .htaccess: php_flag engine off. В отличии от способа выше, файлы PHP будут открываться, как текстовые файлы, а хакер сможет просмотреть их содержимое.

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

Options All —Indexes

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

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

<Files ~ ".bd|777.zip"> Order Deny,Allow Deny from all </Files>

В этом примере запрещено прямое открытие всех файлов с расширением ".bd" и конкретного zip-архива с названием "777.zip". Через разделитель "|" можно указывать необходимое количество файлов, доступ к которым через URL необходимо запретить вообще.

index.php в URL
Очень часто при наличии "index.php" в теле запросе заканчивается ошибкой в приложении, чем и пользуется хакер, для просмотра место хранения файла, в котором эта ошибка возникла. Воспрепятствовать подобному можно, добавив команду в корневой ".htaccess", которая перенаправит запрос на страницу 404, при обнаружении подобного.

RewriteEngine On RewriteRule ^(.*)index\.php$ $1 [R=404,L]

Хотлинк
Вставка URL изображений Вашего сайта на другой называется хотлинком. Этот момент относится к безопасности. Скопировав прямой URL-адрес изображений требуемого количества и вставив на другой сайт, с большой посещаемостью, хакер добивается перегрузки "интернет-шнурков" Вашего сервера. Для защиты от хотлинка необходимо запретить загрузку изображений с других сайтов, кроме поисковых систем. Для этого в корневом файле .htaccess прописываем условия:

RewriteCond %{HTTP_REFERER} !^$ #Далее список разрешенных сайтов RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?kwo-master.com (наш домен).*$ [NC] RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?yandex.ru [NC] RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?google. [NC] RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?msn. [NC] RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?yahoo. [NC] RewriteCond %{HTTP_REFERER} !search?q=cache [NC] #Список запрещенных для хотлинка форматов RewriteRule \.(jpe?g|bmp|gif|png|webp|css|zip|pdf|txt|doc)$ - [NC,F,L]

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

Безопасность PHP системного уровня

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

Отключение опасных функций
В язык php встроено несколько тысяч функций и среди них есть функции, воспользовавшись которыми хакер может получить доступ к ini-файлам, выполнить php-код из строки, что недопустимо. С помощью "disable_functions" можно отключить подобные функции вообще, уменьшив риск взлома.

disable_functions = ini_get, ini_get_all, parse_ini_file, passthru, php_uname, proc_open, shell_exec, show_source, system, popen, eval, posix_getpwuid, posix_getgrgid, posix_uname

Вот так выглядят параметры конфигурации PHP

безопасность сайта

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

Конфигурационные переметры php.ini стоящие внимания:

Безопасность на уровне приложения

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

В процессе создания интерпретатор PHP кладет файл сессии в одну директорию, а как Вы знаете, время хранения по умолчанию равно 1440 сек. Многие заблуждаются, убеждая себя об окончательной ликвидации файла _SESSION спустя 1440 сек. Но увы... Не тут-то было... Сессия продолжает хранится на сервере, занимая при этом место на диске.

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

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

Остальные конфигурации изложены на оф. документации по PHP.

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

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

Убедившись в присутствии таковой защиты, злоумышленники не будут "флудить" на сервере, поскольку это отнимает много времени и скорее всего Ваш сервер будет оставлен в покое.

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

CAPTCHA
Каптча используется в целях проверки данных с гарантией, что их отправил человек, а не бот. Такая проверка в сети интернет очень актуальна. Злоумышленник желая навредить сайту пишет скрипт, который будет "флудить", а именно накручивать голосование, регистрироваться, отправлять формы обратной связи. Правильно написанная каптча заставит злоумышленника прилагать собственные усилия и много времени, для прохождения проверки. Варианты каптчи могут быть реализованы в виде:

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

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

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

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

После получения данных из формы на сервере, обязательно нужно проверить:

$login='';if(isset($_POST['login'])){$login=htmlspecialchars (stripslashes(strip_tags (trim($_POST['login']))));}

Для прояснения общей картины, по проверке форм со стороны сервера, приведу пример проверки формы сообщения с сайта:

<?php $msg='<p class="order_ms">Мы приняли Ваше сообщение!<br> В ближайшое время с Вами свяжется наш менеджер, для ответа!</p>';
if(count($_POST)==3){ $polya=implode('',$_POST); $c=mb_strlen($polya, 'UTF-8'); if($c>160 || $c<20)){echo $msg;exit;} $name='';if(isset( $_POST['name'])){$name=htmlspecialchars (strip_tags (trim($_POST['name'])));} $mess='';if(isset( $_POST['mess'])){$mess=htmlspecialchars (strip_tags (trim($_POST['mess'])));} if(mb_strlen($name, 'UTF-8')>10 || mb_strlen($mess, 'UTF-8')>120){exit;} //Когда проверки успешно пройдены — отправляем сообщение из формы связи echo $msg; }

Загрузка файлов на сервер

Одна из самых опасных задач с точки зрения безопасности. При отсутствии тщательной проверки злоумышленник загрузив скрипт сможет делать с Вашим сайтом и сервером в своих интересах все, что пожелает. Неважно, какие файлы загружаются. Аватарки это, текстовые, или звуковые файлы. Проверка в несколько этапов обязательна: настройка php.ini → получение файла → проверка безопасности и валидация → перемещение из временной директории в постоянное место.

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

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

php_value max_execution_time 500 php_value max_input_time 500 php_value upload_max_filesize 30M php_value post_max_size 30M

Файл во время загрузки помещается в оперативную память сервера и если превышает допустимый размер - не будет загружаться. В такой ситуации, максимальный размер файла зависит непосредственно от объема ОЗУ.

Для реализации этапа получение файла, необходима форма загрузки:

<form action="file-handler.php" method="post" enctype="multipart/form-data"> <input type="file" name="avatar"> <input type="submit" name="upload" value="Загрузить"> </form>

В свойствах формы необходимо задать тип кодировки атрибутом enctype. По умолчанию кодировка application/x-www-form-urlencoded т. е. равно текущей кодировке формы. Для бинарных файлов кодировки не должно быть, поэтому указываем multipart/form-data.

По окончанию загрузки файл записывается во временную директорию и данные о файлах помещаются в суперглобальный массив $_FILES. Переменная $_FILES['avatar'] содержит данные:

Array ( [name] => picture.jpg //оригинальное имя файла [type] => image/jpeg //MIME-тип файла [tmp_name] => home\user\temp\phpD07E.tmp //бинарный файл (путь к файлу во временном хранилище) [error] => 0 //код ошибки [size] => 178773 //размер файла в байтах )

Файл на сервер отправлен и на очереди проверка корректности файла. Не всем данным из $_FILES нужно доверять, ведь размер и тип можно подделать и вместо кода картинки может оказаться вредоносный код. Функцией is_uploaded_file() проверим, был ли файл загружен до конца:

if(isset($_FILES['avatar'])){ //Перезапишем переменные для удобства $filePath=$_FILES['avatar']['tmp_name']; $errorCode=$_FILES['avatar']['error']; //Проверим на ошибки if ($errorCode!==0 || !is_uploaded_file($filePath)){ //Массив с названиями ошибок $codeErr=[ UPLOAD_ERR_INI_SIZE=>'Размер файла превысил значение upload_max_filesize в конфигурации PHP.', UPLOAD_ERR_FORM_SIZE=>'Размер загружаемого файла превысил значение MAX_FILE_SIZE в HTML-форме.', UPLOAD_ERR_PARTIAL=>'Загружаемый файл был получен только частично.', UPLOAD_ERR_NO_FILE=>'Файл не был загружен.', UPLOAD_ERR_NO_TMP_DIR=>'Отсутствует временная папка.', UPLOAD_ERR_CANT_WRITE=>'Не удалось записать файл на диск.', UPLOAD_ERR_EXTENSION=>'PHP-расширение остановило загрузку файла.', ];
$err=isset($codeErr[$errorCode]) ? $codeErr[$errorCode] : 'При загрузке файла произошла неизвестная ошибка.'; echo $err; } }

В ключе $_FILES['avatar']['name'] присутствует изначальное имя и расширение загружаемого файла. Если расширение недопустимо - отбрасываем такие файлы не раздумывая:

$name = $_FILES['avatar']['name']; if(substr_count($name,'.')!=1){return false;} $type = mb_strtolower(explode('.', $name)[1],'UTF-8'); if(in_array($type, array('php', 'php3', 'php4', 'html', 'htm', 'exe', 'js', 'tiff'))){return false;}

Значение ключа name формируется браузером и может быть подделан, поэтому нужен второй уровень проверки:

$type=$_FILES['avatar']['type']; $mime_type = array('image/png', 'image/jpg', 'image/jpeg', 'image/gif');//Массив разрешенных типов файлов if(!in_array( $_FILES['avatar']['type'], $mime_type) || $_FILES['avatar']['size'] > 1500000 || filesize($patch) > 1500000){return false;}//Если нет в массиве разрешенного типа загружаемого файла.

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

Последним этапом изображения необходимо валидировать с помощью функции getimagesize(), которая вернет массив данных (не более 7-ми), а в случаи неудачи - NULL со сгенерированным предупреждением:

Array ( [0]=>1280 //ширина [1]=>768 //высота [2]=>2 //тип [3]=>width="1280" height="768" //аттрибуты для HTML [bits]=>8 //глубина цвета [channels]=>3 //цветовая модель [mime]=>image/jpeg //MIME-тип )

Все файлы изображений измеряются в длинне и высоте. Если загружен вредоносный файл - ширина и высота равна нулю. Для этого необходима проверка функцией getimagesize(). Поскольку в случае неудачи возвращается NULL с предупреждением — оператором @ необходимо подавить ошибку, чтобы её никто не видел. Теперь условие не будет выполнено и загрузка файла будет отклонена.

$image=@getimagesize($filePath); if (filesize($filePath) > 31457280) {die('Размер изображения не должен превышать 30 Мбайт.');} if ($image[1] <=0 && $image[0] <=0 $limitWidth) {die('Некорректное изображение');}

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

$dirupload=$root.'/images/'; if(is_dir($dirupload)){ $prava=substr(decoct (fileperms($dirupload)), -3); //права доступа каталога if($prava!='777') {chmod($dirupload,0777);} //Изменяем права, если недостаточно для загрузки $name = md5_file($patch); //Сгенерируем новое имя файла на основе MD5-хеша $extension = image_type_to_extension($image[2]); //Сгенерируем расширение файла на основе типа картинки $dirupload = $dirupload.$name.$extension; if(move_uploaded_file( $_FILES['avatar']['tmp_name'], $dirupload)){ chmod($dirupload,0444); return true;} } return false;

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

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

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

Каждая цифра разрешает определенные права:

Максимально возможные права 4+2+1=7 (чтение+запись+выполнение), или 4+1=5 (чтение+выполнение). Предлагаю для примера разобрать права 754:

Рекомендуемые права для каталогов и файлов на сервере:

Обратите внимание: в ОС Windows вообще отсутствуют права доступа. Они только на Unix-систем. Узнавать и выдавать права доступа на этой ОС бесполезно.

Язык PHP обладает функциями работы с правами. Выше я упоминал, что у файла всегда есть владелец и у каждого файла есть информация о владельце. Каждый пользователь имеет UID (уникальный идентификатор) и этот UID хранится в каждом файле. Функция fileowner() позволяет его узнать:

echo fileowner("files_777.txt");

Для смены владельца, используется функция chown():

chown("new_user", "files_777.txt");

В примере передача прав файла "files_777.txt" пользователю "new_user", но вместо имени владельца можно указать его UID.

Следующие PHP-функции - это filegroup() и chgrp(). Работают аналогично функциям fileowner() и chown(), но отвечают за группу пользователей:

echo filegroup("files_777.txt"); chgrp("mygroup", "files_777.txt");

И последние функции получения и смены прав доступа к файлам и каталогам - это fileperms() и chmod():

echo fileperms("files_777.txt"); chmod("files_777.txt", 0777);

Обращаю Ваше внимание, что права задаются с обязательным указанием ведущего нуля!

Сообщения об ошибках
Такая маленькая мелочь солидно поможет в защите сайта. Если пользователь в форме авторизации указал верно логин, а пароль нет - не нужно сообщать, какие данные неверны. Обойдитесь общей фразой, например: «Неправильное имя пользователя или пароль».

Dos и Ddos-атака на WEB-сайт

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

Отказаться от CMS-систем, фреймворков, платформ, библиотек. Эти все готовые решения имеют очень низкий уровень безопасности, за счет некачественного кода, множество "дыр" для взломов. В 95% случаев, массовые взломы происходят через эти все готовые решения, взлом которых после 2016 года вырос более, чем на 40%. Поэтому, малое количество программистов во избежания взломов предпочитают писать чистый и качественный код, который не распространяется, и работает в 180-500 раз быстрее, при этом имеет почти нулевую нагрузку на железо сервера, что так же снижает вероятность взломов и отказа работы сайта при очень массовых Dos-атаках на 100%.

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

Исследования проводились на оборудовании Emachines E729Z, с процессором Intel Pentium CPU P6200, 2 ядра (2.13 GHz).
Имя продукта:Скорость выполнения простой задачи:
Wordpress0.47002696990967 сек.
Joomla0.31301784515381 сек.
OpenCart0.12800693511963 сек.
YII0.29201698303223 сек.
Наши Веб-сайты на чистом коде0.00099992752075195 сек.

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

Имя продукта:У сколько раз медленнее:
Wordpressу 467-500 раз
Joomlaу 313 раз
OpenCartу 128 раз
YIIу 292 раза
Bitrixу 238 раз

Для просветления Вашего сознания стоит сказать следующее: пока, например, Wordpress обработает 1 запрос, то в эту ед. времени сайт на чистом коде примерно 380-400 запросов. Из этого вердикт последует таковой: когда безопасность стоит на первом месте - на помощь прибегают программисты чистого кода, которых единицы на рынке IT-индустрии.

Скрипт Apache+PHP против Dos / Ddos-атак
Чтобы не позволять хакеру Dos / DDos-атаки отнимать без надобности ресурсы сервера, можно внедрить работающий способ, написав программу со следующим алгоритмом:

#ip Order allow,deny allow from all deny from 168.254.26.18

После чего, Apache будет знать IP хакера и его не пропустит. Не рекомендую записывать заблокированные IP в базу, поскольку в такой ситуации сервер пропустит запрос, потратив время на вызов интерпретатора PHP, для проверки по базе блаклиста и остановке скрипта, что требует намного больше ресурсов сервера.

Данный алгоритм скрипта почти ничем не уступает модулю mod-evasive.

Защита Admin-зоны

Устанавливая сложный пароль и изменив название папки админки - это детский лепет для хакера. Мы рекомендуем предпринять следующее:

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

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

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

Общие рекомендации

Доступ к настройкам домена.
При регистрации домена, Вы указываете свои личные данные и привязываете его к своему хостингу (серверу). Имея доступ к настройкам Вашего домена, его можно спокойно забрать, привязав к другому сайту и будет обидно, если Ваш очень известный домен забрали нехорошие люди. Поскольку Вы указали свои паспортные данные, они станут известны нежелательной личности. Много заказчиков жалуются на веб-студии, которые отказываются предоставлять доступ к домену, даже если он куплен за Ваши деньги. Избежать подобного достаточно просто: регистрируйте домен сами и поверьте, это не сложно!

В процессе покупки домена создается учётная запись на сайте регистратора, доступ к которой предоставляется по логину и паролю. Обязательно включите подтверждение входа через СМС во избежания подбора пароля и кражи Вашего домена.

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

Храните секреты
Это значит не быть многословным, не разглашать принятые меры о безопасности проекта, различного рода доступы, исходный код и архитектуру! Любопытным разведчикам не открывайте секретов. Это залог Вашего успеха!

Заключение

Принимая даже все известные меры по безопасности, нереально обезопасить сайт от взлома на все 100%. Если Ваш код, ОС и программы безопасны — то только сегодня. Может быть завтра хакеры выработают новые и более действующие способы обхода защиты.

Придерживайтесь наших рекомендаций и Вы снизите вероятность взломов. Не слушайте людей, использующие CMS-системы, фреймворки и выдающих себя за программистов. Это системы управление содержимым. Они не для программистов, а для обычных людей, которые не знают программирование, поэтому эти бесплатные решения — для 99% веб-студий лидеры. Программисты — они и архитекторы работающие напрямую с кодом, с серверами и железом, строго придерживаясь стандартов программирования. Не одобряют 99% веб-студий, поскольку они подставляют заказчиков под массовые угрозы взлома, контроля и передачи данных в службы безопасности, делая им сайты на готовых программных продуктах!

безопасность сайта

Так же хочу предупредить о том, что любой взлом, или попытка — противозаконные действия. Многие хакеры остаются безнаказанными, но если они кого-то достают — веселое лицо хакера превращается в грустную тыкву ;). Из-за лени большинства владельцев взломанных сайтов, создается ложное впечатление, что это ненаказуемо, но уверяю Вас в обратном!

А вот изучать, как мыслят и действуют хакеры — не можно, а нужно! Поэтому лучше семь раз подумайте, чем совершить действия, которые станут интересны кибер-полиции.

Что-то не понятно?
Спросите у нас и мы обязательно Вам поможем!

Отправляя форму, Вы подтверждаете указание своего e-mail адреса.

Рекомендуемые статьи этой категории

Как выбрать хостинг

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

Подробнее
Ошибки в верстке новичков и опытных

ТОП распространенных ошибок верстальщиков и методы исправления. Скриншоты результатов ошибок и примеры кода, для их устранения.

Подробнее
Оптимизация верстки + 10 трендовых фишек

Узнайте о фишках оптимизации вашей верстки HTML+CSS и ваши сайты станут еще быстрее, лучше и с высокой оценкой качества. Вы узнаете о легком способе оптимизации изображений, шрифтов, текста и кода.

Подробнее
Как реально сэкономить на SEO-продвижении и кто может сделать качественный сайт

Работающий и проверенный способ экономиии на продвижении сайтов в поиске, с гарантиями качества от Google. Возможность самого качественного сайта.

Подробнее

Оставить заявку