Как защитить сайт от взлома

[radioelectron]

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

 

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

 

Перевод статьи Quick security checklist for webmasters от Google

• Проверьте конфигурацию/настройки своего сервера. Если используется вебсервер Apache, то советы по обеспечению его безопасности можно прочитать здесь, в случае использования серверов от Microsoft рекомендации по безопасности можно найти в tech center resources for IIS.
  
• Следите за появлением всевозможных патчей и исправлений и своевременно обновляйте свои программы/скрипты/модули. Наиболее часто встречающийся источник опасности возникает, когда вебмастер установил на сервер скрипт какого либо блога, форума или пр. и потом забыл о его существовании.
  
• Постояно следите за вашими log files (логами) на сервере. Ежедневная проверка логов должна стать привычкой!
  
• Проверьте сайт на общие уязвимости. Не устанавливайте на сайт каталоги с открытыми разрешениями на добавление. Обязательно проверьте сайт на возможность межсайтового кросспостинга и SQL injection. Используйте длинные сложные пароли.
  
• Осторожно относитесь к скриптам сторонних поставщиков. Если вы планируете установить какой либо скрипт, счетчик, код рекламной сети и другие , постарайтесь убедиться в безупречной репутации поставщика кода. Убедитесь что данной службой успешно пользуются другие сайты.
  
• Проверьте как проиндексирован сайт. Убедиться в том, что все нормально можно просмотрев список проиндексированных гуглом страниц. Это можно сделать используя команду site:our_domain_name
  
• Используйте Google Webmaster Tools. Использование данного сервиса позволит увидеть статус сайта, а также как поисковый бот сканирует сайт. Кроме того, если бот обнаружит наличие всяких вредных программ/скриптов, Вы сможете увидеть адреса "вредных" страниц (они будут исключены из индекса). После устранения "заразы" в том же сервисе можно написать запрос на повторное включение страниц в индекс
  
• Используйте безопасные протоколы. Используйте SSH и SFTP протоколы для передачи данных между локальным компьютером и сервером. Использование этих защищенных протоколов более безопасно, чем обычный telnet и FTP. Большое количество полезных советов по безопасности и использованию этих протоколов можно найти здесь.
  
• Читайте Google Online Security Blog. Здесь можно найти огромное количество постоянно добавляемых советов по безопасности.
  
• Контактируйте с техподдержкой хостинговой компании. Если у вас возникают какие то сомнения и подозрения в нарушении безопасности обязательно обращайтесь в техподдержку.
  

 

Что такое chmod/чмод и права файлов

• Чмод для чайников
  
• http://chmod.ru/
  

 

Относительная информация по защите через файл ".htaccess"

 

Для чего служит файл ".htaccess":

Файлы .htaccess позволяют изменить некоторые настройки веб-сервера Apache применительно к отдельному каталогу и его подкаталогам. Например, если разместить в каталоге logs файл .htaccess со строчкой Options +Indexes, можно будет по адресу http://сайт/logs/ получить полный список содержащихся там файлов (в случае, если там не присутствует ни одного из возможных файлов индекса). Если в logs есть подкаталоги, например, mail и ftp, индексирование будет проводиться и в них тоже; чтобы избежать этого, нужно разместить в них файлы .htaccess с запретом индексации – строчкой Options -Indexes.

 

Блокировка по IP адресам:

Средствами файла .htaccess можно ограничить доступ к ресурсам сайта по IP адресам; например, разрешить доступ к медиа-архиву только пользователям из локальной сети, или запретить какому-либо хосту или сети доступ к какому-либо контенту.

 

Синтаксис для этих директив таков:

 

Order Deny, Allow (или Allow, Deny – в зависимости от того, что требуется)
Deny from all (или адрес хоста)
Allow from all (или адрес хоста)

 

Например,

Order Deny, Allow
Deny from all
Allow from 192.168.0.
Allow from .localnet
Allow from admin.somewhere.in.the.net

вызывает отказ в доступе для всех, кроме сети 192.168.0.0/24, всех хостов, DNS имя которых содержит .localnet, а также хоста, DNS имя которого admin.somewhere.in.the.net.

 

Если нужно запретить доступ группе хостов, используется Allow,Deny:

Order Allow, Deny
Allow from all
Deny from 192.168.1.
Deny from hackers.are.everywhere.in.the.net

 

Принцип прост. По Order определяется порядок обработки правил allow/deny; если мы возьмем второй пример, то сначала сервер обработает правило allow from all, а затем хосты, которые прошли это правило, подвергаются проверке правилом deny; при этом все хосты из сети 192.168.1.0/24 и хост hackers.are.everywhere.in.the.net не проходят эту проверку и не получают доступа.

 

Более сложные применения:

<FilesMatch "\.(txt|dat)$">
Order Deny, Allow
Deny from all
</Files>

– данное правило запретит любым хостам доступ к файлам с расширениями .txt и .dat (например, в них могут храниться внутренние данные скриптов).

 

Запрет обращений к файлу ".htaccess":

Защитить их можно следующим образом, однако, это по умолчанию уже есть в httpd(2).conf, то есть в самой конфигурациии веб-сервера.

 

<Files ~ "^\.ht">
Order allow, deny
Deny from all
</Files>

 

Запрет вывода списка файлов:

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

Строчка

Options -Indexes

отключит этот режим.

 

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

Например,

IndexIgnore *.php* *.pl *.html *.shtml

разрешает вывод списка всех файлов, кроме PHP и Perl скриптов, а также HTML документов.

 

 

Подробно о защите скриптов можно прочитать здесь: Часть I Часть IIДалее краткая заметка:

 

Защита Php-скриптов

 

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

substr($str, 0, 10);

 

Так можно ограничить длину строки. К примеру, ограничить длину ника, вводимого в форме. Функция возвращает часть переменной $str. В данном случае функция вернет строку длинной не более 10 символов, начиная с нулевого, т.е. отбросит все символы, после десятого символа, если таковые имеются. Последний параметр функции является опциональным, т.е. необязательным, можно просто задать substr($str, 5) - в таком случае возвратом функции будет строка, часть переменной $str начиная с пятого символа.

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

 

2. Также очень важно проверять поступающие данные на достоверность.

 

empty($str);

 

Функция возвращает true, если переменная $str пустая [не содержит данных], false - в противном случае.

 

trim($str);

 

Функция возвращает строку, очищенную от пустых символов вначале и конце строки [пробелы, символы табуляции, перевода строки].

 

strip_tags($str);

 

Функция возвратит строку, очищенную от html и php тегов. В качестве второго параметра, начиная с версии PHP 3.0.13, можно задавать разрешенные теги, т.е. те теги, которые не будут вырезаться из строки. Например:

 

$str= strip_tags($str, '<a><i><b>' ); 
htmlspecialchars( $str);

 

Функция заменяет символы в строке $str, имеющие специальное значение в html, на их безопасные эквиваленты:

 

& на & 
< на < 
> на > 
" на " 
' на '

 

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

 

Например:

$str = htmlspecialchars( '<a href="test">Test</a>' , ENT_QUOTES);

 

С помощью регулярных выражений можно (нужно!) многое. Часто требуется заменять какие-либо символы в тексте вручную.

 

Например:

$str= ereg_replace( "n", '<br>', $str);

 

Данное выражение заменит в $str все символы с кодом 10 ["n" - перевод строки] на строку

 

<br>

 

Очень желательно чтобы в поля e-mail и url были введены именно адрес электронной почты и адрес сайта соответственно, а не то, что душе угодно:

 

preg_match( '/^([a-z0-9_-.])+@([a-z0-9_-])+(.([a-z0-9])+)+$/' ,$email);

 

Такая запись устанавливает условие на содержимое переменной $email. Функция вернет true, если данные в переменной похожи на адрес электронной почты, false - в противном случае.

 

preg_match( '/^([a-z0-9_-.])+(.([a-z0-9/])+)+$/' ,$url);

 

Таким регулярным выражением можно проверить и url на правильность

 

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

 

Первым делом скрипты не должны выдавать предупреждения [warning] и тем более ошибки [error] в браузер, и вообще не должны их выдавать.

 

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

 

isset( $var);

 

Функция возвращает true, если переменная определена, false - в противном случае.

 

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

 

С методом post ситуация похожая:

 

register_globals

 

- директива, которая задает возможность (или невозможность) регистрации глобальных переменных, т.е. при получении данных из формы или из адресной строки [get], по умолчанию создаются глобальные переменные с соответствующими именами [имя поля или имя параметра в адресной строке]. Это естественно, но безобразно.. (парадокс!) и вообще в некоторых случаях ведет к дырам в скриптах. Желательно так писать сценарии, чтобы они по возможности старались обходиться без директивы register_globals. Отключить это безобразие в .htaccess файле можно следующим образом:

 

php_flag register_globals Off

 

В таком случае данные get и post будут храниться в глобальных ассоциативных массивах

 

$HTTP_GET_VARS 
и  
$HTTP_POST_VARS

 

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

track_vars - доступность глобальных ассоциативных массивов переменных среды, сервера, get, post и cookie.

variables_order - порядок регистрации переменных среды, сервера, get, post и cookie.

register_argc_argv - переменные $argv и $argc на основе информации, поступившей методом get.

file_uploads - возможность обрабатывать закачку файлов.

Подробнее об этих и других директивах - мануал по Apache

[php.ini, .htaccess].

4. Никогда не бывает лишним удостовериться в том, что данные в скрипт пришли именно с вашего сайта.

if(ereg( '^http://' .$HTTP_HOST ,getenv ('HTTP_REFERER' )));

 

Регулярное выражение проверяет, содержится ли в HTTP_REFERER имя хоста вашего сайта. Если нет, то можно послать деморализующее сообщение в браузер и завершить работу скрипта. Но не стоит 100%но доверять такой проверке, т.к. HTTP_REFERER при большом желании злоумышленник может подделать и законспирироваться под имя хоста.

 

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

Brustus AET-2. Замечательная вещь и даже во многих случаях результативная [выделенный канал + большая база словарей + несложный пароль].

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

код авторизации добавляется следующее:

 

if( file_exists( 'log.txt') && filesize( 'log.txt')> 1024) exit;

 

Т.е. до авторизации делается проверка - если существует лог неудачных авторизаций и его размер [в байтах] больше 1024, то скрипт прекращает свою работу [или выдает деморализующее сообщение ], не доходя до

самого процесса авторизации. На этом перебор у злоумышленника завершится.

 

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

 

 

Источники:

• googlewebmastercentral.blogspot.com
  
• zeosmaster.com