myhand

Рейтинг
278
Регистрация
16.09.2009
LEOnidUKG:
Это как я понял ответ на мой вопрос насчёт переброса?

1. ну да - никакой раздачи статики нет. просто прокси

2. вот этих вещей (переброса портов файерволом) - не хватает у вас на "window$":

148K 8363K DNAT tcp -- any any anywhere s1.chatukg.n et tcp dpt:http to:64.191.63.117:88

631K 32M DNAT tcp -- any any anywhere chatukg.net tcp dpt:http to:64.191.63.118:88

328 18088 DNAT tcp -- any any anywhere chatukg.net tcp dpt:http to:64.191.63.119:88

306 16696 DNAT tcp -- any any anywhere chatukg.net tcp dpt:http to:64.191.63.120:88

404 22611 DNAT tcp -- any any anywhere chatukg.net tcp dpt:http to:64.191.63.121:88

PS: Зачем так сделано - если честно - для меня большая загадка. Спросите Ваших админов - им

виднее.

LEOnidUKG:
Значит хотите сказать, что админы onkelhost.ru меня обманули и с таким конфигом статические данные не выдаются nginx?

1. Данный конфиг - просто проксирует запросы апачу.

2. Работать на реальном сервере он может из-за переброса портов, например

Чуть подробнее можно? Например, в реальном конфиге IP _одинаковы_?

myhand добавил 24.09.2009 в 12:03

LEOnidUKG:
Из всех правил я вижу связанное с 88 портом только эту строчку:

iptables -t nat -vL что говорит?

LEOnidUKG:

server {
listen 192.168.0.1:88;
access_log off;

location /
{
proxy_pass http://192.168.0.1:80;

Жирным я выделил порты, которые прописаны на реальном серваке.
Теперь вопрос...
Почему nginx слушает 88 порт, а Apache 80?
Почему тоже самое не работает на windows (в заголовках висит Apache)?

P.S. Я конечно по логике понимаю, что апатч должен быть на 88 порту, а nginx на 80 НО(!) почему такая схема работает на серваке?

Судя по этому конфигу (nginx работает как прокси, никакой "раздачи статики") - он работал бы,

если входящие запросы приходили на 192.168.0.1:88. Все это проксируется nginx'ом на 192.168.0.1:80.

Что именно вас смущает? GET / на 192.168.0.1:80 говорит "Server: nginx"?

hostin1234:
но уязвимость забавная, ей богу, берегитесь)

"Беречься" пока конкретно нечего - слишком уж у вас сумбурная

диагностическая информация.

Вы можете взять вашу "чистую" сборку связки apache+php и сравнить (md5,

например) с теми же бинарниками на работающей системе, когда есть

проблема. Так вы проверите что именно было изменено + не добавлено

ли еще что (например модуль какой апачу, если он не статический).

В любом случае, о решении проблемы было бы интересно прочесть ;-)

alesty:
Перенесли его на ВДС....и столкнулись с проблемой:
Независимо от настройки Аппача (perfork крутили реально во все стороны - кол-во серверов, простаивающих, клиентов, таймауты, кипалайвы и т.д) он благополучно валится - в один прекрасный момент (обычно, полчаса-час после перезапуска) запускаются все возможные воркеры, переходят в состояние "W"-Sending Reply и занимают 99% процессорного времени.
Хостер предлагал на платной основе решить нашу проблему методом ковыряния в кишках ДЛЕ - спасибо блин ему большое. Мы и сами с усами - в ДЛЕ поотключали абсолютно всё, что грузить может, повключали все кеши.

Интересно, а nginx крутили? "W" - это, я понимаю, апачи nginx'у отдают контент. Может именно с его настройками не так, забрать быстро контент не получается (буфера?).

hostin1234:
бинарники системы и пхп ЦЕЛЫЕ

Это проверялось, как я понимаю, с live cd? ибо если из системы - то, чем проверялось (md5sum, например) - вполне может быть протроянено.

В общем, буду удивлен, если кто-то поможет без более детальной информации - нужно смотреть.

Himiko:
и?
Не думаю, что таким образом можно подменить "выдачу" других скриптов.

Если вы подменили интерпретатор - можете добавить что угодно, к

тому, что он интерпретирует.

Himiko:
Что-то ни разу такого добра не видел) Если конечно это руткит какой-то не делает...

Не обязательно руткит.. например, используется php-cgi + suexec и скрипты PHP работают от того же пользователя, что владеет бинарником php-cgi.

Himiko:
Я про suexec не забывал) Я уже даже не привык, что у кого-то Apache собран без suexec).

В почти любом дистрибутиве это совершенно отдельные вещи. Например, если не делается виртуального хостинга - это вполне оправдано.

hostin1234:

апач во все выдаваемые страницы добавляет вредоносный код. физически в страницах кода этого нет.

решатся вопрос пересборкой апача и php, но на время.. 1-2 дня.

Если можете что-либо подсказать на этот счет - будем благодарны, в том числе и материально.

open_base_dir ON, php CLI 5.2.11, apache 2.2.13

PHP работает модулем? Или CGI+suexec?

Всего: 4890