Ръководство за закаляване и сигурност на уеб сървъра Apache

Практическо ръководство за защита и втвърдяване на Apache HTTP Server.


Уеб сървърът е важна част от уеб-базирани приложения. Apache Web Server често се поставя на ръба на мрежата, поради което става една от най-уязвимите услуги за атака.

Настройката по подразбиране предоставя много чувствителна информация, която може да помогне на хакера да се подготви за атака на приложенията. По-голямата част от атаките на уеб приложения са чрез XSS, изтичане на информация, управление на сесии и SQL инжектиране, които се дължат на слаб код за програмиране и невъзможност за саниране на инфраструктурата на уеб приложенията.

Интересни изследвания от Положителни технологии разкрива, 52% от сканираното приложение имаше висока уязвимост.

В тази статия ще говоря за някои от най-добрите практики за осигуряване на Apache HTTP сървър на Linux платформа.

Следните са тествани на Apache 2.4.x версия.

  • Това предполага, че сте инсталирали Apache на UNIX платформата. Ако не, можете да преминете през ръководството за инсталиране.
  • Ще извикам инсталационната директория / opt / apache като $ Web_Server в това ръководство.
  • Препоръчваме ви да вземете резервно копие на съществуващ конфигурационен файл преди всяка промяна.

Contents

Публика

Това е предназначено за администратор на Middleware, поддръжка на приложения, системен анализатор или всеки, който работи или има желание да научи закаляването & Насоки за сигурност.

Справедливи познания на Apache Web Server & Командата UNIX е задължителна.

бележки

Нуждаете се от някакъв инструмент за проверка на HTTP заглавките за някои от проверките за внедряване. Има два начина да направите това.

  1. Използвайте вградени в браузъра инструменти за разработчици, за да инспектирате HTTP заглавките. Обикновено е в раздела Мрежа
  2. Използвайте онлайн инструмент за проверка на заглавия на HTTP отговор

Премахване на банера на версията на сървъра

Бих казал, че това е едно от първите неща, които трябва да вземете предвид, тъй като не искате да излагате версията на уеб сървъра, която използвате. Разкриването на версия означава, че помагате на хакера да ускори процеса на разузнаване.

Конфигурацията по подразбиране ще разкрие версията на Apache и типа на ОС, както е показано по-долу.

  • Отидете в папката $ Web_Server / conf
  • Променете httpd.conf с помощта на редактора vi
  • Добавете следната директива и запазете httpd.conf

ServerTokens Prod
Подпис на сървъра изключен

  • Рестартирайте апаш

ServerSignature ще премахне информацията за версията от страницата, генерирана от Apache.

ServerTokens ще промени Header само за производство, т.е. Apache

Както можете да видите по-долу, версия & Информацията за ОС няма.

Деактивиране на списъка с браузъри на директории

Деактивирайте списъка с директории в браузър, така че посетителят не вижда какви файлове и папки имате под корен или поддиректория.

Нека да тестваме как изглежда в настройките по подразбиране.

  • Отидете в директорията $ Web_Server / htdocs
  • Създайте папка и няколко файла вътре в нея

# mkdir тест
# докосвай здравей
# докоснете здравей

Сега, нека се опитаме да осъществим достъп до Apache от HTTP: // Localhost / изпитване

Както можете да видите, това разкрива какви файлове / папки имате и съм сигурен, че не искате да излагате това.

  • Отидете в директорията $ Web_Server / conf
  •  Отворете httpd.conf с помощта на vi
  •  Потърсете директорията и променете директивата за опции на None или –Indexes

Опции -Индекси

(или)

Опции няма

  • Рестартирайте Apache

Забележка: ако имате няколко директиви на директорията във вашата среда, трябва да помислите да направите същото за всички.

Сега, нека се опитаме да осъществим достъп до Apache от HTTP: // Localhost / изпитване

Както можете да видите, тя показва забранена грешка, вместо да показва списъка с тестови папки.

ETAG

Той позволява на отдалечените атакуващи да получат чувствителна информация като номер на възел, многочастна MIME граница и дъщерния процес чрез заглавката на Etag.

За да предотвратите тази уязвимост, нека я приложим по-долу. Това е необходимо за коригиране на PCI съответствие.

  • Отидете в директорията $ Web_Server / conf
  • Добавете следната директива и запазете httpd.conf

FileETag Няма

  • Рестартирайте апаш

Стартирайте Apache от непривилегирован акаунт

Инсталацията по подразбиране работи като никой или демон. Използването на отделен непривилегирован потребител за Apache е добре.

Идеята тук е да се защитят други работещи услуги в случай на някаква дупка в сигурността.

  • Създайте потребител и група, наречена apache

# groupadd apache
# useradd – G apache apache

  • Променете собствеността на инсталационната директория на апаш на новосъздаден непривилегирован потребител

# chown –R apache: apache / opt / apache

  •  Отидете на $ Web_Server / conf
  •  Променете httpd.conf с помощта на vi
  •  Търсене на потребител & Групова директива и промяна като апаширан акаунт за непривилегирована сметка

Потребител апаш
Групов апаш

  •  Запазете httpd.conf
  •  Рестартирайте Apache

grep за тестване на http процес и се уверете, че той работи с апаш потребител

# ps –ef | grep http

Трябва да видите, че един процес работи с root. Това е така, защото Apache слуша на порт 80 и трябва да се стартира с root.

Защитете разрешението на бинарна и конфигурационна директория

По подразбиране разрешението за двоична и конфигурация е 755, което означава, че всеки потребител на сървър може да прегледа конфигурацията. Можете да забраните на друг потребител да влиза в папка conf и bin.

  • Отидете в директорията $ Web_Server
  • Промяна на разрешение на папка bin and conf

# chmod –R 750 бин конф

Защита на системните настройки

В инсталация по подразбиране потребителите могат да отменят конфигурацията на апаш, използвайки .htaccess. Ако искате да попречите на потребителите да променят настройките на вашия сървър на апаш, можете да добавите AllowOverride в None, както е показано по-долу.

Това трябва да стане на нивото на корена.

  • Отидете в директорията $ Web_Server / conf
  •  Отворете httpd.conf с помощта на vi
  •  Търсете Директория на кореново ниво

Опции -Индекси
AllowOverride None

  •  Запазете httpd.conf
  •  Рестартирайте Apache

Методи за заявка на HTTP

HTTP 1.1 протоколът поддържа много методи за заявка, които може да не се изискват и някои от тях имат потенциален риск.

Обикновено може да са ви необходими GET, HEAD, POST методи за заявка в уеб приложение, които могат да бъдат конфигурирани в съответната директива за директория.

Поддръжка за конфигурация по подразбиране ОПЦИИ, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT в протокол HTTP 1.1.

  •  Отидете в директорията $ Web_Server / conf
  •  Отворете httpd.conf с помощта на vi
  • Потърсете Директория и добавете следното

отричам от всички

  • Рестартирайте Apache

Деактивирайте HTTP заявка за проследяване

По подразбиране методът Trace е активиран в уеб сървъра Apache.

Разрешаването на това може да позволи атака с кръстосано проследяване и потенциално да се даде възможност на хакер да открадне информация за бисквитките. Нека да видим как изглежда в конфигурацията по подразбиране.

  •  Направете IP уеб сървър на telnet със слушателски порт
  •  Направете TRACE заявка, както е показано по-долу

#telnet localhost 80
Опитвате 127.0.0.1…
Свързан е с localhost.
Героят за бягство е ‘^]’.
TRACE / HTTP / 1.1 Хост: тест
HTTP / 1.1 200 OK
Дата: Sat, 31 Aug 2013 02:13:24 GMT
Сървър: Apache
Трансфер-кодиране: откъснато
Тип съдържание: съобщение / http 20
TRACE / HTTP / 1.1
Водещ: тест
0
Връзка е затворена от чужд хост.
#

Както можете да видите по-горе TRACE заявката, тя отговори на моята заявка. Нека го деактивираме и тестваме.

  •  Отидете в директорията $ Web_Server / conf
  • Добавете следната директива и запазете httpd.conf

TraceEnable изключен

  •  Рестартирайте апаш

Направете IP уеб сървър на telnet с порт за слушане и направете TRACE заявка, както е показано по-долу

#telnet localhost 80
Опитвате 127.0.0.1…
Свързан е с localhost.
Героят за бягство е ‘^]’.
TRACE / HTTP / 1.1 Хост: тест
HTTP / 1.1 405 Методът не е разрешен
Дата: Sat, 31 Aug 2013 02:18:27 GMT
Сървър: Apache Allow: Content-Length: 223Content-Type: text / html; кодировка = изо-8859-1
405 Методът не е разрешен

Методът не е разрешен

Заявеният метод TRACE не е разрешен за URL /.

Връзка е затворена от чужд хост.
#

Както можете да видите по-горе TRACE заявката, тя блокира моята заявка с метод HTTP 405 не е разрешен.

Сега този уеб сървър не позволява TRACE заявка и помощ при блокиране на Cross Site Tracing атака.

Задайте бисквитка с HttpOnly и Secure flag

Можете да смекчите по-голямата част от обичайната атака за кръстосани скриптове, използвайки HttpOnly и Secure флаг в бисквитка. Без да имате HttpOnly и Secure, е възможно да се открадне или манипулира сесия на уеб приложение и бисквитки, и това е опасно.

  •  Уверете се, че mod_headers.so е активиран във вашия httpd.conf
  •  Отидете в директорията $ Web_Server / conf
  •  Добавете следната директива и запазете httpd.conf

Редактиране на заглавка Set-Cookie ^ (. *) $ $ 1; HttpOnly; Secure

  •  Рестартирайте апаш

Clickjacking Attack

Clickjacking е добре известни уязвимости на уеб приложенията.

  •  Уверете се, че mod_headers.so е активиран във вашия httpd.conf
  •  Отидете в директорията $ Web_Server / conf
  •  Добавете следната директива и запазете httpd.conf

Заглавката винаги добавя опции за X-Frame SAMEORIGIN

  •  Рестартирайте апаш

X-Frame-Options също поддържат още две опции, които обясних тук.

Включете страна на сървъра

Server Side Include (SSI) има риск от увеличаване на натоварването на сървъра. Ако сте споделили околната среда и уеб приложенията с голям трафик, трябва да помислите да деактивирате SSI, като добавите директива Включва в опциите.

SSI атаката позволява използването на уеб приложение чрез инжектиране на скриптове в HTML страници или изпълнение на кодове от разстояние.

  • Отидете в директорията $ Web_Server / conf
  •  Отворете httpd.conf с помощта на vi
  •  Потърсете Директория и добавете Включва в Директивата за опции

Опции –Indexes -Включва
Поръчката позволява, отказвайтеВсичко от всички

  • Рестартирайте Apache

Забележка: ако имате няколко директиви на директорията във вашата среда, трябва да помислите да направите същото за всички.

X-XSS защита

Защитата на Cross Site Scripting (XSS) може да бъде заобиколена в много браузъри. Можете да приложите тази защита за уеб приложение, ако то е деактивирано от потребителя. Това се използва от повечето гигантски уеб компании като Facebook, Twitter, Google и т.н..

  • Отидете в директорията $ Web_Server / conf
  • Отворете httpd.conf с помощта на vi и добавете следващата директива на заглавието

Комплект заглавки X-XSS-защита "1; режим = блок"

  •  Рестартирайте Apache

Както можете да видите, XSS-Protection е инжектиран в заглавката на отговора.

Деактивирайте протокола HTTP 1.0

Когато говорим за сигурност, ние трябва да защитаваме колкото можем. Така че защо използваме по-стара HTTP версия на протокола, нека също ги деактивираме?

HTTP 1.0 има слабост в сигурността, свързана със отвличането на сесия. Можем да деактивираме това с помощта на модула mod_rewrite.

  • Уверете се, че сте заредили mod_rewrite модула във файл httpd.conf
  •  Активирайте директивата RewriteEngine както следва и добавете условие Rewrite, за да разрешите само HTTP 1.1

ПренапишетеEngine на
RewriteCond% {THE_REQUEST}! HTTP / 1.1 $
RewriteRule. * – [F]

Конфигурация на стойността на изчакване

По подразбиране стойността на времето за изчакване на Apache е 300 секунди, което може да стане жертва на бавна атака Лорис и DoS. За да смекчите това, можете да намалите стойността на изчакване до може би 60 секунди.

  • Отидете в директорията $ Web_Server / conf
  • Отворете httpd.conf с помощта на vi
  •  Добавете следното в httpd.conf

Време за изчакване 60

SSL

Наличието на SSL е допълнителен слой сигурност, който добавяте в уеб приложението. Конфигурацията на SSL по подразбиране обаче води до определени уязвими места и трябва да помислите за настройване на тези конфигурации.

SSL ключ

Нарушаването на SSL ключ е трудно, но не и невъзможно. Това е просто въпрос на изчислителна мощност и време.

Както може би знаете, като използвате компютър от епохата на 2009 г. се пропука за около 73 дни обратен инженер 512-битов ключ.

Така че колкото по-голяма е дължината на ключа, толкова по-сложно става разбиването на SSL ключ. Повечето гигантски уеб компании използват 2048 битов ключ, както по-долу, така че защо не го правим?

  •  Outlook.com
  •  Microsoft.com
  •   Live.com
  •  Skype.com
  •  Apple.com
  •  Yahoo.com
  •  Bing.com
  •  Hotmail.com
  •  Twitter.com

Можете да използвате OpenSSL, за да генерирате CSR с 2048 бит, както е показано по-долу.

openssl req -out geekflare.csr -newkey rsa: 2048 -nodes -keyout geekflare.key

Ще генерира CSR, който ще трябва да изпратите на сертификатен орган да го подпишем. След като получите подписания сертификатен файл, можете да ги добавите във httpd-ssl.conf файл

SSLCertificateFile # Сертификат, подписан от органа
SSLCertificateChainFile # Подписващ сертификат, даден от властта
SSLCertificateKeyFile #Key файл, който генерирахте по-горе

  • Рестартирайте уеб сървъра на Apache и се опитайте да получите достъп до URL адреса с https

SSL шифър

SSL Cipher е алгоритъм за криптиране, който се използва като ключ между два компютъра през Интернет. Шифроването на данни е процесът на преобразуване на обикновен текст в секретни шифровани кодове.

Въз основа на конфигурацията на вашия уеб сървър SSL Cipher шифроването на данни ще се извърши. Затова е важно да конфигурирате SSL Cipher, който е по-силен и не е уязвим.

  • Отидете в папката $ Web_Server / conf / extra
  •  Променете директивата SSLCipherSuite в httpd-ssl.conf по-долу, за да приемате само по-високи алгоритми за криптиране

SSLCipherSuite HIGH:! MEDIUM:! ANULL:! MD5:! RC4

  •  Запазете конфигурационния файл и рестартирайте апаш сървъра

Забележка: Ако имате много слаби шифри в своя одиторски отчет за SSL, можете бързо да ги отхвърлите добавяйки! в началото.

Деактивиране на SSL v2 & v3

SSL v2 & v3 има много пропуски в сигурността и ако работите за тест за проникване или съответствие с PCI, тогава се очаква да закриете констатацията за сигурност, за да деактивирате SSL v2 / v3.

Всяка SSL v2 / v3 комуникация може да бъде уязвима за атака „Човек в средата“, която може да позволи подправяне или разкриване на данни.

Да приложим уеб сървъра на апаш да приема само най-новата TLS и да отхвърля заявката за свързване на SSL v2 / v3.

  • Отидете в папката $ Web_Server / conf / extra
  • Променете директивата SSLProtocol в httpd-ssl.conf по-долу, за да приемате само TLS 1.2+

SSLProtocol –ALL + TLSv1.2

След като приключите със конфигурацията на SSL, добре е да тествате уеб приложението си с онлайн SSL / TLS сертификатен инструмент, за да намерите всяка грешка в конфигурацията.

Mod Security

Mod Security е защитна стена с отворен код на уеб приложението, която можете да използвате с Apache.

Той идва като модул, който трябва да компилирате и инсталирате. Ако не можете да си позволите защитна стена на комерсиално уеб приложение, това ще бъде отличен избор.

За да осигурят обща защита на уеб приложенията, Основните правила използват следните техники:

  • HTTP Protection – откриване на нарушения на HTTP протокола и локално дефинирана политика за използване
  • Търсене в черен списък в реално време – използва IP репутация на трети страни
  • Уеб-базирано откриване на злонамерен софтуер – идентифицира злонамерено уеб съдържание чрез проверка на API за безопасно сърфиране в Google.
  • HTTP Отказ от защита на услугата – защита срещу HTTP Flooding и бавни HTTP DoS атаки.
  • Обща защита от уеб атаки – откриване на обща атака за защита на уеб приложения
  • Автоматично разпознаване – Откриване на ботове, сканери, скенери и друга злонамерена активност на повърхността
  • Интеграция с AV сканиране за качване на файлове – идентифицира злонамерени файлове, качени чрез уеб приложението.
  • Проследяване на чувствителни данни – Проследява използването на кредитни карти и блокира течове.
  • Троянска защита – откриване на достъп до троянски коне.
  • Идентифициране на дефекти в приложението – сигнали за неправилни конфигурации на приложението.
  • Откриване и скриване на грешки – прикриване на съобщения за грешки, изпратени от сървъра.

Изтегли & Инсталация

Следните предпоставки трябва да бъдат инсталирани на сървъра, където искате да използвате Mod Security с Apache. Ако някое от тях не съществува, компилацията на Mod Security ще се провали. Можете да използвате yum install на Linux или Centos, за да инсталирате тези пакети.

  • apache 2.x или по-висока
  • пакет libpcre
  •  пакет libxml2
  • пакет liblua
  • пакет либур
  •  libapr и libapr-util пакет
  •  mod_unique_id модул в комплект с уеб сървър Apache

Сега, нека изтеглите последната стабилна версия на Mod Security 2.7.5 от тук

  • Прехвърлете изтегления файл в / opt / apache
  • Извличане на modsecurity-apache_2.7.5.tar.gz

# gunzip –c modsecurity-apache_2.7.5.tar.gz | катран xvf –

  • Отидете на извлечена папка modsecurity-apache_2.7.5

# cd modsecurity-apache_2.7.5

  • Стартирайте скрипта за конфигуриране, включително apxs пътя към съществуващия Apache

# ./configure –with-apxs = / opt / apache / bin / apxs

  • Compile & инсталирайте с make script

# направи
# направи инсталиране

  • След като инсталацията приключи, ще видите mod_security2.so в папка с модули под / opt / apache

Сега това приключва, сте инсталирали Mod Security модул в съществуващ уеб сървър Apache.

Конфигурация

За да използваме функцията за защита на Mod с Apache, трябва да заредим модула за защита на мода в httpd.conf. Модулът mod_unique_id е задължително условие за Mod Security.

Този модул осигурява променлива среда с уникален идентификатор за всяка заявка, която се проследява и използва от Mod Security.

  • Добавете следния ред за зареждане на модул за Mod Security в httpd.conf и запазете конфигурационния файл

LoadModule уникални_id_module модули / mod_unique_id.so
LoadModule security2_module модули / mod_security2.so

  •  Рестартирайте уеб сървъра на апаш

Mod Security вече е инсталиран!

Следващото нещо, което трябва да направите, е да инсталирате основното правило на Mod Security, за да се възползвате максимално от неговата функция.

Последното основно правило може да бъде изтеглено от следваща връзка, която е безплатна. https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master

  • Копирайте изтегления цип на основното правило в папка / opt / apache / conf
  • Разархивирайте основния файл с правила
  • Може да искате да преименувате папката на нещо кратко и лесно за запомняне. В този пример ще преименувам на crs.
  • Отидете в папката crs и преименувайте modsecurity_crs10_setup.conf.example в modsecurity_crs10_setup.conf

Сега, нека да дадем възможност на тези правила да работят с уеб сървъра Apache.

  •  Добавете следното в httpd.conf

Включете conf / crs / modsecurity_crs_10_setup.confInclude conf / crs / base_rules / *. Conf

В горната конфигурация ние зареждаме основния конфигурационен файл на модула за сигурност Modsecurity_crs_10_setup.conf и базови правила base_rules / *. Conf, предоставени от основните правила на Mod Security за защита на уеб приложения.

  •  Рестартирайте уеб сървъра на апаш

Успешно сте конфигурирали Mod Security с Apache!

Много добре. Сега уеб сървърът Apache е защитен от защитната стена на уеб приложението Mod Security.

Приготвяме се да започнем

Нека започнем с някои от критичните конфигурации в Mod Security, за да се втвърди & сигурни уеб приложения.

В този раздел ще направим цялата промяна на конфигурацията в /opt/apache/conf/crs/modsecurity_crs_10_setup.conf.

В този раздел ще посочим /opt/apache/conf/crs/modsecurity_crs_10_setup.conf като setup.conf, например за целта.

Важно е да разберете какви правила на OWASP се предоставят безплатно. Има два вида правила, предоставени от OWASP.

Основни правила – тези правила са силно тествани и вероятно съотношението на фалшива аларма е по-малко.

Експериментални правила – тези правила са с експериментална цел и може да имате висока фалшива тревога. Важно е да конфигурирате, тествате и внедрите в UAT, преди да ги използвате в производствена среда.

Незадължителни правила – тези незадължителни правила може да не са подходящи за цялата среда. Въз основа на вашето изискване можете да ги използвате.

Ако търсите защита от CSRF, проследяване на потребители, отвличане на сесия и др., Може да помислите за използване на незадължителни правила. Имаме основни, незадължителни и експериментални правила след извличане на изтегления crs zip файл от страницата за изтегляне на OWASP.

Конфигурационният файл на тези правила е достъпен в папката crs / base_rules, crs / optional_rules и папка crs / eksperimental_rules. Нека се запознаем с някои от основните правила.

  • modsecurity_crs_20_protocol_violations.conf: Това правило защитава от уязвимости на протокола като разделяне на отговора, контрабанда на заявки, като се използва протокол, който не е разрешен (HTTP 1.0).
  • modsecurity_crs_21_protocol_anomalies.conf: Това е за защита от искане, което липсва с Host, Accept, User-Agent в заглавката.
  • modsecurity_crs_23_request_limits.conf: Това правило зависи от конкретното приложение като размер на заявката, размер на качването, дължина на параметър и т.н..
  • modsecurity_crs_30_http_policy.conf: Това е за конфигуриране и защита на позволен или забранен метод като CONNECT, TRACE, PUT, DELETE и т.н..
  • modsecurity_crs_35_bad_robots.conf: Откриване на злонамерени роботи
  • modsecurity_crs_40_generic_attacks.conf: Това е за защита от инжектиране на команда на ОС, дистанционно включване на файлове и т.н..
  • modsecurity_crs_41_sql_injection_attacks.conf: Това правило за защита на SQL и сляпа SQL заявка за инжектиране.
  • modsecurity_crs_41_xss_attacks.conf: Защита от заявка за скрипт между сайтове.
  • modsecurity_crs_42_tight_security.conf: Откриване и защита на преминаване на директория.
  • modsecurity_crs_45_trojans.conf: Това правило за откриване на обща продукция за управление на файлове, качване на HTTP задна страница, известен подпис.
  • modsecurity_crs_47_common_exceptions.conf: Това се използва като изключителен механизъм за премахване на често срещани фалшиви позитиви, които могат да се срещнат смучат като вътрешна манекенска връзка Apache, SSL пингер и т.н..

Влизане

Регистрирането е едно от първите неща, които трябва да се конфигурират, така че да имате създадени регистрационни файлове за това, което Mod Mod Security прави. Предлагат се два вида дърводобив; Debug & Дневник за одит.

Журнал за отстраняване на грешки: това е да дублира съобщенията за грешка Apache, предупреждения и съобщения от дневника за грешки.

Журнал за одит: това е да напишете дневниците на транзакциите, които са маркирани от правилото за защита на Mod Mod Mod Security ви предоставя гъвкавост да конфигурирате одит, отстраняване на грешки или и двете регистрации.

По подразбиране конфигурацията ще запише и двата регистрационни файла. Можете обаче да промените въз основа на вашето изискване. Дневникът се контролира в директивата SecDefaultAction. Нека да разгледаме конфигурацията на регистрация по подразбиране в setup.conf

SecDefaultAction „фаза: 1, отказ, регистрация“

За да влезете Debug, Audit log – използвайте „log“ За да регистрирате само журнал за одит – използвайте „nolog, auditlog“ За да регистрирате само журнала за отстраняване на грешки – използвайте „log, noauditlog“ Можете да зададете местоположението на журнала за одит, което да се съхранява, което се контролира от SecAuditLog директива.

Нека запишем вход в одита в /opt/apache/logs/modsec_audit.log, като добавим, както е показано по-долу.

  • Добавете директива SecAuditLog в setup.conf и рестартирайте Apache Web Server

SecAuditLog /opt/apache/logs/modsec_audit.log

  • След рестартирането трябва да видите как се генерира modsec_audit.log

Активиране на двигателя на правилата

По подразбиране Правилото на двигателя е Изключено, което означава, че ако не активирате Rule Engine, не използвате всички предимства на Mod Security.

Правилото за активиране или деактивиране на двигателя се контролира от директивата SecRuleEngine.

  • Добавете директива SecRuleEngine в setup.conf и рестартирайте Apache Web Server

SecRuleEngine On

Има три стойности за SecRuleEngine:

  • On – за да активирате Rule Engine
  • Изключено – за деактивиране на Rule Engine
  • DetectionOnly – активирайте Rule Engine, но никога не изпълнява действия като блокиране, отказ, пускане, разрешаване, прокси или пренасочване

След като Rule Engine е включен – Mod Security е готов да се защити с някои от често срещаните видове атаки.

Обща защита срещу атака

Сега уеб сървърът е готов да се защити с общи типове атаки като XSS, SQL инжектиране, нарушаване на протокол и т.н., тъй като инсталирахме Core Rule и включихме Rule Engine. Нека да тестваме няколко от тях.

XSS Attack

  •  Отворете Firefox и получите достъп до приложението си и поставете маркер в края или URL адреса
  •  Следете modsec_audit.log в папката apache / logs

Ще забележите искането на Mod Security block, тъй като съдържа етикет, който е коренът на XSS атаката.

Атака на обход на директорията: – Атаките с траверса на директорията могат да създадат много щети, възползвайки се от тази уязвимост и свързан със системата за достъп файл. Ex – / etc / passwd, .htaccess и т.н..

  •  Отворете Firefox и получите достъп до приложението си с обиколка на директория
  •  Следете modsec_audit.log в папката apache / logs

HTTP: // Localhost / ../…/boot

  • Ще забележите заявка за блокиране на Mod Mod, тъй като съдържа преместване на директория.

Промяна на банер на сървъра

По-рано в това ръководство научихте как да премахнете Apache и тип ОС, помощ за версията на директивата ServerTokens.

Нека да направим една стъпка напред, какво ще кажете да запазите името на сървъра, каквото пожелаете? Възможно е с директивата SecServerSignature в Mod Security. Виждате, че е интересно.

Забележка: За да използвате Mod Security за манипулиране на сървърен банер от заглавка, трябва да зададете ServerTokesn на Пълно в httpd.conf на уеб сървъра Apache.

  • Добавете директива SecServerSignature с желаното име на сървъра в setup.conf и рестартирайте Apache Web Server

SecServerSignature YourServerName

Ex:

[/ opt / apache / conf / crs] #grep SecServer modsecurity_crs_10_setup.conf
SecServerSignature geekflare.com
[/ opt / apache / conf / crs] #

Обща конфигурация

Нека да разгледаме някои от общите конфигурации като най-добра практика.

Конфигуриране на слушане

Когато имате множество интерфейси и IP адреси на един сървър, се препоръчва директива за слушане да бъде конфигурирана с абсолютен IP и номер на порт.

Когато оставите конфигурацията на апаш за слушане на всички IP адреси с някакъв номер на порта, това може да създаде проблем при пренасочване на HTTP заявка към друг уеб сървър. Това е доста често в споделената среда.

  • Конфигурирайте директивата за слушане в httpd.conf с абсолютен IP и порт като показания пример по-долу

Слушайте 10.10.10.1:80

Регистриране на достъпа

Важно е да конфигурирате правилно дневника за достъп във вашия уеб сървър. Някои от важните параметри за запис в дневника биха били времето, необходимо за обслужване на заявката, SESSION ID.

По подразбиране Apache не е конфигуриран да улавя тези данни. Трябва да ги конфигурирате ръчно, както следва.

  • За заснемане на времето, необходимо за обслужване на заявката и идентификатора на SESSION в дневник за достъп
  •  Добавете% T & % sessionID в httpd.conf съгласно директивата LogFormat

LogFormat "% h% l% u% t "% {Идентификатор на сесия} С" "% г" %>s% b% T" често срещани

Можете да се отнесете http://httpd.apache.org/docs/2.2/mod/mod_log_config.html за пълен списък на параметър, поддържан в директивата LogFormat в Apache Web Server.

Деактивиране Зареждането на нежелани модули

Ако сте компилирали и инсталирали с всички модули, има голям шанс да имате много модули, заредени в Apache, които може да не са необходими.

Най-добрата практика е да конфигурирате Apache с необходимите модули във вашите уеб приложения. Следните модули имат проблеми със сигурността и може да се интересувате от деактивиране в httpd.conf на уеб сървъра Apache.

WebDAV (Уеб базирано разпределено авторство и версия) Този модул позволява на отдалечените клиенти да манипулират файлове на сървъра и да са обект на различни атаки за отказ на услуга. За да деактивирате следния коментар в httpd.conf

#LoadModule dav_module модули / mod_dav.so
#LoadModule dav_fs_module модули / mod_dav_fs.so
# Включете conf / extra / httpd-dav.conf

Информационен модул Mod_info модулът може да изтече чувствителна информация, използвайки .htaccess, след като този модул се зареди. За да деактивирате следния коментар в httpd.conf

#LoadModule info_module модули / mod_info.so

Справка: Това не би било възможно без указания от следната връзка:

Това беше някои от най-добрите практики, които можете да използвате, за да защитите вашия уеб сървър Apache.

Ако сте нов за Apache HTTP, тогава бих препоръчал да вземете курс за администриране на Apache HTTP.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map