Повышаем безопасность стека web-приложений (виртуализация LAMP, шаг 5/6)

Original author: Vivek Gite
  • Translation

Настройка web-сервера Lighttpd  на работу со статическими файлами сетевой файловой системы (NFS)


Пятый урок цикла статей по настройке web-стека LAMP на виртуальных машинах будет посвящен обслуживанию статических файлов.

lighttpd web-сервер отвечает за предоставление доступа через HTTP или HTTPS протокол к статическому контенту. В этом примере я собираюсь установить и использовать Lighttpd web-сервер, привязав DocumentRoot к vm05:/exports/static mounted смонитрованной в /var/www/static. Все приведенные ниже команды вам необходимо вводить исключительно на vm01 с IP-адресом 192.168.1.10.

Настройка NFS-клиента


С помощью yum-менеджера установим пакеты NFS-клиента:
# yum groupinstall "Network file system client"

Или чуть проще:
# yum install nfs-utils nfs4-acl-tools

Включим службы NFSv4-клиента:
# chkconfig rpcbind on
# chkconfig rpcidmapd on
# chkconfig nfslock on


/etc/idmapd.conf настройки nfs-клиента


Отредактируем файл конфигурации nfs-клиента
# vi /etc/idmapd.conf

Убедитесь, что параметры выставлены ​​в соответствии с доменным именем NFS-сервера:
Domain = cyberciti.biz
 
[Mapping]
 
Nobody-User = nobody
Nobody-Group = nobody

Сохраните и закройте файл. Запустим все службы NFS-клиента:
# /sbin/service rpcbind start
# /sbin/service rpcidmapd start
# /sbin/service nfslock start


Создание учетной записи пользователя


Мы будем запускать web-сервера Lighttpd  только из под пользователя apache. Что бы добавить учетную запись пользователя в Linux, введем следующие команды:
# /usr/sbin/groupadd -g 48 apache
# /usr/sbin/useradd -s /sbin/nologin -g 48 -u 48 -M -d /var/www apache
# /usr/bin/passwd -l apache


Монтируем файловую систему


Введите следующую команду:
# showmout -e vm05

Пример вывода:
Export list for v.txvip1:
/exports/html     192.168.1.10,192.168.1.11
/exports/static   192.168.1.10,192.168.1.11

Смонтируем /exports/static папку файловой nfs-системы к /var/www/static
# mkdir /var/www/static
# /bin/mount -t nfs4 -orsize=32768,wsize=32768,intr,hard,proto=tcp,sync vm05:/exports/static /var/www/static/

Отредактируем файл /etc/fstab:
# vi /etc/fstab


Монтирование файловой системы через /etc/fstab


Отредактируем /etc/fstab:
# vi /etc/fstab

Добавим следующую строку:
vm05:/exports/static /var/www/static nfs4 orsize=32768,wsize=32768,intr,hard,proto=tcp,sync

Сохраним и закроем файл. Убедимся, что netfs-служба включена:
# chkconfig netfs on

И, наконец, убедимся в том, что пользователь apache видит наши файлы
# su - apache
$ ls /var/www/static/
$ exit
#

Обратите внимание, что root-пользователь или любой другой пользователь не видит /var/www/ static из-за установленной нами политики безопасности. Это единственный lighttpd-пользователь, имеющий права на доступ к DocumentRoot.

Установка Lighttpd web-сервера


Подключите EPEL-репозиторий и установите web-сервер Lighttpd
# yum install lighttpd

Пример вывода консоли:
Loaded plugins: rhnplugin
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package lighttpd.x86_64 0:1.4.28-3.el6 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
==========================================================================
 Package          Arch           Version               Repository    Size
==========================================================================
Installing:
 lighttpd         x86_64         1.4.28-3.el6          epel         328 k
Transaction Summary
==========================================================================
Install       1 Package(s)
Total download size: 328 k
Installed size: 878 k
Is this ok [y/N]: y
Downloading Packages:
lighttpd-1.4.28-3.el6.x86_64.rpm                   | 328 kB     00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : lighttpd-1.4.28-3.el6.x86_64                           1/1
Installed:
  lighttpd.x86_64 0:1.4.28-3.el6
Complete!


Настройка web-сервера Lighttpd


Отредактируем /etc/lighttpd/lighttpd.conf введя следующие команды:
# mv /etc/lighttpd/lighttpd.{conf,default.bak}<br />
# vi /etc/lighttpd/lighttpd.conf

Впишем следующие настройки:
## Настройка статики для http://static.cyberciti.biz
 
server.modules              = (
                               "mod_expire",
                               "mod_access",
                               "mod_accesslog",
                               "mod_setenv",
                               "mod_extforward"
)
 
server.errorlog            = "/var/log/lighttpd/error.log"
accesslog.filename         = "/var/log/lighttpd/access.log"
index-file.names            = ( "index.html", "index.htm", "default.htm" )
 
server.tag                 = "lighttpd"
server.network-backend = "linux-sendfile"
 
## разрешать доступ только для lan-запросов ##
server.port = "80"
server.bind = "192.168.1.10"
 
server.document-root = "/var/www/static"
server.pid-file = "/var/run/lighttpd.pid"
 
server.username = "apache"
server.groupname = "apache"
 
## вся статика кешируется на 30 дней от первого доступа ##
$HTTP["url"] =~ "^/" {
   expire.url = ( "" => "access 30 days" )
}
 
### Логировать реальный ip-адрес пользователя ###
### 192.168.1.{1,2} == nginx resverse proxy server ##
extforward.headers = ("X-Forwarded-For")
extforward.forwarder = (
      "192.168.1.1" => "trust",
      "192.168.1.2" => "trust"
)
 
##
## mimetype mapping
##
include "conf.d/mime.conf"

Сохраним и закроем файл

Настройка iptables для доступа к web-серверу


Отредактируйте файл /etc/sysconfig/Iptables, добавив следующие параметры (убедитесь, что они прописаны до окончательных LOG и DROP настроек INPUT-цепочки):
## разрешить доступ только из локальной сети ##
-A INPUT -m state --state NEW -p tcp -s 192.168.1.0/24 --dport 80 -j ACCEPT

Сохраняем, закрываем. Перезапускаем iptables:
# /sbin/service iptables restart
# /sbin/iptables -L -v -n


Включаем Lighttpd

Запускам Lighttpd web-сервер следующей командой:
# chkconfig lighttpd on
# service lighttpd start

Врубаем браузер и ломимся на наш сервер:
http://192.168.1.10/


Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 11

    0
    А можно узнать URL оригинальной статьи? Прошу прощения, если он где-то указан, но я не заметил.
      0
      ссылки в топиках-переводах — после иконок шаринга в социалка и до имени автора статьи/перевода. В нашем случае это ссылка на автора Vivek Gite. Это для данной статьи. В конце статьи-оригинала на cyberciti.biz такое же меню навигации по частям. Чего, тоже по русски ни фига не понимаете? Понимаю. Однажды установил с дуру русский фотошоп и заплакал.
      +1
      В отдельно взятых случаях я бы еще подстраховал разработчиков и выставил дефолтный content-type как force-download:
      [root@localhost conf.d]# cat /etc/lighttpd/conf.d/mime.conf | grep '""'
      #  ""              =>      "application/octet-stream",
        ""              =>      "application/force-download",
      


      Увы не могу ничего сказать на тему стабильности работы подобной схемы на Lighttpd, проверял работоспособность только на nginx. Наши реалии таковы, что зачастую разработчики не умеют и не хотят правильно работать с файлами, обычно от незнания специфики веб-серверов на которых работают/могут работать их разработки, отсюда и получаем что допускаются к загрузке расширения с пробелами в конце (очень частый случай, когда при проверке в какой нить функции IsImage делается trim/rtrim а при сохранении нет) или же загрузка файлов только с расширением (например .jpg — смертельный файл для проекта в связке nginx + клиент на IE), а отдача всей статики кроме разрешенной с force-download их от этого убережет.
        0
        да, я тоже не понял в чем сакраментальный смысл ставить lighttpd и прятать его за nginx, если сам nginx замечательно (вероятно что даже лучше) справляется со статическими файлами
          0
          Пофигу что там будет стоять, на сколько я понял замысел автора. Дело в сатанинском разграничении доступа к файлам этого vm05 на стороне vm05. И тюнинг этой vm05 будет происходить исключительно на vm05, по этому там стоит исключительно файловый сервис раздачи статики. lighttpd или nginx — пофигу. А верхний nginx — это точка входа для всех хостящихся наших проектов. Такой вот балансировщик сервисов.
          Тут сделан большой задел с некоторой избыточностью для дальнейшего горизонтального масштабирования каждого из звеньев цепи.
          На сколько я понял ваш вопрос: «нафига нам городить все эти виртулаки?» Исключительно атомарности ради, мониторинга для и дальнейшей секьюризации во имя.
            0
            нет, вопроса «нафига городить виртуалки» у меня не возникает — сами все крутим как раз в виртуалках

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

              0
              Во первых это перевод how-to, а не must-to. А во вторых, я бы рад был apache заменить на nginx + php-fpm, ну вот теперь представьте себе какой-нибудь 0day-эксплойт или специалиста по опрокидыванию nginx (то что мы с ними не знакомы — не означает, что их нет). И вот он пришел, а у нас — везде один и тот же софт, та же самая его версия. Он ломает верхний сервис, а все нижние — на такой же системе крутятся. А он пришел только ради каких-то файлов на vm05. В нашей схеме он хоть покорчится, какое-то время.
              Про несовместимость легкости настройки и безопасности было сказано прежде в цикле этих статей. Смотрите, у г-на «дизайнера всея руси» Тютёмы Л. есть слоган: «Долго. Дорого. О-у-энно». Суть этого слогана в том, что в разработке сайтов есть три кита:

              * скорость производства конечного продукта
              * стоимость продукта и стоимость владения им
              * качество

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

              А вы публично про свой проект не рассказывали на хабре? Помнится вы по комментам какой-то PHP-продакшен хаус с облаками и нагрузками. «Слейте», пжалста, в общих чертах, как решили свои задачи в вашей компании, если это не NDA. Если NDA — слейте в личку. ))
                +1
                > И вот он пришел, а у нас — везде один и тот же софт, та же самая его версия. Он ломает верхний сервис, а все нижние — на такой же системе крутятся. А он пришел только ради каких-то файлов на vm05. В нашей схеме он хоть покорчится, какое-то время.

                =)
                вероятность поймать 0day-эксплойт в двух разных софтах в два раза вероятнее, чем в одном.
                ну да ладно, это через шишки само прийдет

                к сожалению пока это NDA. вероятно архитектура будет пересмотрена в ближайшее время и тогда можно будет в двух словах поделиться и проблемами и решениями.

                PS: для статики сразу делайте отдельную внешнюю точку входа чтобы все обслуживалось с субдомена напрямую. тем более, что полшага для этого уже сделано
                  0
                  Слушайте, я тут переводчик или что? 8) Не совсем поняд про внешнюю точку. Всмысле спразу отдельную машину под статику или вы про imX.example.com?
                    +1
                    переводчик конечно =)

                    сразу про static.example.com с отдельным ip. просто раз уж тут архитектура построения серверов тесно переплетается с архитектурой проекта, то лучше сразу закладываться на то, что вся статика живет на отдельном домене: по-началу (до упора в ширину канала) разница будет только в скорости подгрузки файлов браузером (даже если физически машина будет та же, что и балансер), а потом в принципе будет проще унести статику в CDN
                    а вот проксировать статику user->nginx->сервер-статики->файл ну совсем не комильфо: явно лишнее звено которое будет забивать канал
                      0
                      Я вот об отдельном ip под статику не думал прежде. Мне казалось, что он (браузер) до такого не доходит и только переживал, как бы раскидывать на пару-тройку доменов static(1...×+1).example.com, что бы они продолжали кешироваться. А о переносе части картинок в CDN (у нас новостные ресурсы) полагал исходить из «возраста» файла изображения, т.к. CDN может и разорить.
                      Канал забивать не будет, это точно. Скорее в дисковую систему упремся, т.к. сейчас и до 7Мб/сек передача не дотягивает при дисковой «предельной» скорости, на сегодняшний день, большей в разы.

        Only users with full accounts can post comments. Log in, please.