Конфигуриране на Apache Server - Страница 6

Apache отлетя. Отново (. Помощ! Имам целия сайт на него.

Приложение AddType/x-httpd-php3 phtml php3 php
ScriptAlias ​​/ __ php_dir __/"C:/php /"
Приложение за действие/x-httpd-php3 "/__php_dir__/php.exe"

Опции ExecCGI

Заявеният URL /__php_dir__/php.exe/index.php не е намерен на този сървър.

В pxp5 направете следното:

LoadModule php5_module e: /webserver/php/php5apache2_2.dll
Приложение AddType/x-httpd-php php php3 php4 php5 phpml

Откъс от книгата "Тайните на хакерите. Защита на уеб приложенията - извън кутията"

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

Apache
Apache си изгради добра репутация заради високата сигурност и производителност, които демонстрира през целия си живот, особено в последно време. Например, започвайки с версия 1.3, все още не е открит нито един случай сървърът да е бил компрометиран от препълване на буфер, водещо до неоторизирано изпълнение на команди. Подобно на 1IS на Microsoft с петата на Ахил - допълнителна функционалност като уеб-базиран печат или индекс сървър, който може да компрометира цялата система (вижте раздела IIS за повече подробности) - недостатъците на сигурността на сървъра на Apache се крият и в допълнителните му компоненти, наречени модули . Разработчиците на сайтове за електронна търговия се стремят да създават динамични страници, които привличат потребителя не само с най-модерните многоцветни „лъкове“, но и отчитат неговите цветови предпочитания. За да се „научи“ Apache да работи с динамични страници, е необходимо да се прибегне до използването на допълнителни модули. Чрез тези модули нападателите проникват в системите. Помислете за някои сравнително скорошни примери за хакване на сървъра Apache.

Изглед на директория в режим Multiview
Популярност 7
Лесно 10
Опасност 6
Степен на риск 7.6

[rohan] $ echo -e "GET/some_directory? M = D HTTP/1.0 \ n \ n" | \
> nc 192.168.42.17 80

Индекс на/some_directory

Разглеждане на директории с използване на дълги URL адреси
Популярност 7
Лесно 8
Опасност 6
Ниво на риск 7

[apache] $ ./configure --disable-module = dir --disable-module = autoindex

Достъп до файлове чрез mod_rewrite
Популярност 5
Простота 4
Опасност 9
Степен на риск 6

RewriteRule /more-icons/(.*)/home/httpd/icons/$ l

Пример за правило без уязвимост:

RewriteRule /more-icons/(.*)/icons/$ l

Противодействие: достъп до файлове чрез mod_rewrite
За да премахнете този недостатък, достатъчно е да напишете правилно стойността на параметъра RewriteRule (вижте примерите по-горе).

Проникване през mod_auth_ * sql
Популярност 6
Лекота 7
Опасност 9
Ниво на риск 7

Противодействие: проникване на mod_auth_ * sql
Пакетът mod_auth_ * sql трябва да бъде актуализиран. Спрете и след това рестартирайте уеб сървъра на Apache след надстройката, за да влязат в сила промените.

Apache httpd 2.0
Какво ще бъде в бъдеще за Apache? Серията 2.0, която в момента е в бета тестване, вероятно ще бъде пусната от разработчиците на „голямо пътуване“ скоро. Една от най-големите промени, въведени в серия 2.0, е поддръжката за филтриране или подобряване на способността за обединяване на множество модули за анализиране на URL адреси. Като се имат предвид проблемите, които измъчват модули като mod_rewrite през месеците на разработване на нов сървърен ред, може да се предположи, че незащитените модули или грешки ще се появят в новата йерархия. Поне две от грешките, които позволяват нарушение на DoS, вече са открити и отстранени в близката до версията версия на серията 2.0. DoS хакове са най-примитивните и най-често срещаните видове хакове, но потребителите на уеб сървъри биха искали да се пазят по всякакъв възможен начин.

Microsoft Internet Information Server (IIS)
Като една от най-разпространените уеб сървърни платформи в Интернет, идеята на Microsoft е била атакувана многократно през последните години. IIS е изложен на недостатъци като пробиване на изходния код с помощта на реда: $ DATA, изтичане на информация чрез примерни скриптове като showcode.asp, привилегировани команди в заявки към вътрешния интерфейс с бази данни (MDAC/RDS), да не говорим вече за просто препълване на буфера (IISHack). Въпреки че всички тези недостатъци вече са отстранени в текущата версия на IIS (към момента на писане, IIS 5), от време на време на сървъра се откриват нови. Най-сериозните недостатъци в системата за сигурност IIS, както вече идентифицирани, така и фиксирани и все още чакащи в крилата, обикновено могат да бъдат причислени към една от двете групи.

• Хакване на отделни компоненти на IIS.
• Хакване на самия сървър IIS.

Хакване на IIS компоненти
IIS използва многобройни библиотеки с динамични връзки (DLL), които работят с основния процес на сървъра inetinfo. exe, предоставете на последния поддръжка за определени функции (скриптове от страна на сървъра, индексиране на съдържание, уеб-базиран печат и др.). За да използвате функционалността, съдържаща се в DLL, просто поискайте файл със съответното разрешение от 1IS. Например заявяването на файл с разширение .printer (независимо дали файлът действително съществува или не) ще доведе до извикване на DLL, която знае как се обработват заявките за печат в мрежата.

---