Соглашусь с вами, возможно ihttpd - это лишнее, но все же для того, чтоб потестировать возможности, и набраться побольше опыта стоит поэксперементировать...
К тому же, он позволяет вынести биллинг на субдомен, и убрать из адреса /manager/, без всяких танцев с бубном вокруг сервера...
Да и хорошей справки по этому делу, как прикрутить биллинг через Nginx в интернете нет... Может кому то будет полезно...
rpaf был установлен заранее, исключил его упоминание из статьи...
neodev добавил 17.12.2011 в 08:08
Некоторые фиксы:
При возникновении варнинга: [warn] VirtualHost 127.0.0.1:8080 overlaps with VirtualHost 127.0.0.1:8080, the first has precedence, perhaps you need a NameVirtualHost directive В httpd.conf апача добавляем:
NameVirtualHost 127.0.0.1:8080
и в директиву server {} добавляем фикс доступа к phpMyAdmin
location /myadmin/ { proxy_pass http://127.0.0.1:8080/myadmin/; proxy_redirect http://my.host.com:8080/ /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr;}
Либо выносим его на отдельный субдомен:
server { listen 88.198.69.214:80; server_name pma.serucity.host.com; location / { proxy_pass http://127.0.0.1:8080/myadmin/; proxy_redirect http://pma.serucity.host.com:8080/ /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; }}
Виртуалхост в Apache будет примерно следующий:
<VirtualHost 127.0.0.1:8080> ServerName pma.serucity.host.com ServerAdmin root@host.com Alias /myadmin/ /usr/share/phpmyadmin/ DirectoryIndex index.php Options -Indexes</VirtualHost>
Либо переносим его в root директорию:
<VirtualHost 127.0.0.1:8080> ... DocumentRoot /usr/share/phpmyadmin/ ...</VirtualHost>
Соответственно, настройка proxy_pass в конфиге nginx:
proxy_pass http://127.0.0.1:8080/;
А еще лучше, вообще отключаем phpmyadmin, зачем он нам нужен на биллинг сервере? :)
neodev добавил 17.12.2011 в 08:10
Решил поднять отказоустойчивую систему вида "Кластер"... Начал потихоньку изучать все нюансы... 🍿
neodev добавил 17.12.2011 в 08:24
Я стремлюсь к этому =) Были бы исходники всех модулей Billmanager, не было бы проблем, дописать и поднастроить... Но там все статические пути, редиректы не пойми куда и зачем, и другая неживая ересть...
Так же остается проблема с проксированием на 1500 порт до ihttpd cgi скриптов из папки mancgi, видимо ihttpd не корректно определяет IP из "proxy_set_header X-Real-IP", и в логах никакой полезной информации нет. так что приходится искать обходные пути... 😡
Суппорт ответил по этом:
А вот интересно, компания, где была приобретена лицензия, там знают как они сделали этот биллинг? Или у них есть исходники биллинга, для детального изучения его внутренностей?
Эта единственная загвоздка, которая мешает полностью отключить Apache.
neodev добавил 17.12.2011 в 08:28
Вроде этого не упоминалось в статье, что биллинг и хостинг на одном сервере...
Биллинг находится на отдельном сервер... База биллинга на этом же сервере...
Отписал же,
через nginx легче настроить лимиты, и парсить логи на превышение лимитов...+ бан ip фаерволом.
Прикрыл уязвимость, через local-infile=0 в my.cnf. :)
Himiko, можем списаться в ICQ? #306183
neodev добавил 12.11.2011 в 07:58
Эта функция запрещена на уровне юзера в php.ini : disabled_functions
exec('cat /etc/passwd'); - как самый простой способ при апач-префорк, есть баг в curl, который обходит это, и symlink уязвимость... ;)
Himiko, странно, но у меня воссоздать случай, описанный вами не получилось.
1. http://s017.radikal.ru/i411/1111/36/21d61e4dcbf4.jpg
2. http://s017.radikal.ru/i428/1111/1d/6571465b6b5e.jpg
3. http://s001.radikal.ru/i195/1111/08/52d31fb15413.jpg
При этом:
Disabled PHP Functions: putenv, popen, exec, system, passthru, proc_open, shell_exec, system_exec, shell, escapeshellarg, escapeshellcmd, proc_close, ini_alter, dl, show_source, enable_dl, proc_nice, apache_get_modules, virtual, getmyinode, apache_get_version, apache_getenv, apache_note, apache_setenv, ini_restore, openlog, syslog, highlight_file, symlink, ini_get_all, posix_uname, pcntl_fork, proc_terminate, proc_getstatus, pclose, proc_get_status, chgrp, posix_mkfifo, posix_setuid, posix_setsid, posix_setpgid, posix_kill, apache_child_terminate, pfsockopen, posix_getpwuid, posix_getgrgid, disk_free_space, diskfreespace, disk_total_space, posix_getegid, posix_geteuid, posix_getuid, posix_getgid
Open base dir: .
neodev добавил 12.11.2011 в 07:42
Я сам для себя не являюсь клиентом, еще раз поясняю, что mxneo мой сайт, и хостинг nghost тоже.
neodev добавил 12.11.2011 в 07:48
Я никак не отношусь к ТС. На моём сайте был обнаружен вредоносный js код атакующий его сайт.
neodev добавил 12.11.2011 в 07:52
P.S. поправки!
В ВиртуалХосте домена нашел директивы: AssignUserID
Это при отключенном PHP.
Видимо этот баг ISP пофиксили...
Himiko, спасибо большое за выявленную уязвимость. Буду искать способ фиксить.
Файл surf.html содержал в себе коды счетчиков liveinternet, Rambler Top100 и другие, для накрутки показов через такие системы как WebSurf.ru
neodev добавил 12.11.2011 в 05:26
Apache работает как MPM-ITK, в этом режими даже права 777 на изменяемом файле не нужны для его редактирования через php Shell.
При понижении прав на изменяемый файл ниже 0444 - статика не читается Nginx, "403 Forbidden".
neodev добавил 12.11.2011 в 05:04
Тут не настройки сервера, а дыра в php скрипте...
neodev добавил 12.11.2011 в 05:09
Уважаемый, почему вы считаете что сервер плохо настроен?
Слова человека, из переписки, который напрямую залил файл через форму загрузки, подобрал имя файла в папке uploads, и который говорит что это дырка в сервере, не могут приниматься всерьез.
Он смог навредить только одному аккаунту. До соседей на сервере никак нельзя достучаться, а от кривых рук администраторов сайтов, не знающих про безопасность и права доступа никто не застрахован. И еще раз повторяю что сайтом mxneo управляли несколько человек, а не только я...
С уважением, Дмитрий.
Приветствую!
Собственно, зарегистрировался, чтобы дать несколько объяснений случившемуся...
Я владелец сайта mxneo.ru и хостинга nghost. Что могу сказать по этому поводу? Абуза от дц поступила, были приняты меры по исправлению данной ситуации...
Так же, выкладываю переписку, которая произошла поздее, после случившегося инцидента: http://pastebin.com/Ae3XwEvR
Из переписки видно, кулцхакеры через кривой скрипт залили шелл, и собственно, рулили сайтом и аккаунтом на хостинге...
Я знал про существование этого файла, и собственно я и администраторы сайта использовали его для накрутки счетчиков через web serf системы, но то что он был изменен вне моего ведома информации небыло. Так как на папку небыло прав записи, записали вредоносный скрипт предоставленный ТС в данный файл, так как на него были поставлены права доступа 777.
