Консультации Портала - Консультация #185774

Задать вопрос Консультации Пользователи Форум

Задать вопрос экспертам

Консультация № 185774

08.04.2012, 11:46

69.99 руб.

0 15 1

Компьютеры Программное обеспечение Операционные системы

Здравствуйте!
Возникает непонятная проблема с Fedora 8, может кто-то сталкивался.
Сервер работает, всё хорошо, я его постоянно пингую:
-
Reply from xxx.xxx.xxx.xxx: bytes=32 time=2ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=3ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=2ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=2ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=2ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=2ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=2ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=2ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=2ms TTL=58
-
Внезапно пинги начинают тормозить:
Reply from xxx.xxx.xxx.xxx: bytes=32 time=2ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=2ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=9ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=8ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=8ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=8ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=10ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=7ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=7ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=9ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=2ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=5ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=12ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=11ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=9ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=8ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=8ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=9ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=10ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=10ms TTL=58
-
А затем и вовсе пропадают:
Reply from xxx.xxx.xxx.xxx: bytes=32 time=20ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=20ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=21ms TTL=58
Request timed out.
Request timed out.
Request timed out.
-
Сервер в ауте. Делаю следующее:
service httpd stop
Пинги тут же восстанавливаются:
Request timed out.
Reply from xxx.xxx.xxx.xxx: bytes=32 time=3ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=2ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=2ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=2ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=2ms TTL=58
Reply from xxx.xxx.xxx.xxx: bytes=32 time=2ms TTL=58
-
service httpd start
Всё работает до следующего раза (может 10 минут, а может 3 дня).
При этом нагрузка на сервер в момент удлинения пингов не возрастает.
-
Вопрос: что это может быть? И какое отношение Apache имеет к пингам?

Обсуждение

Неизвестный

08.04.2012, 12:08

общий

Apache в error.log в момент недоступности что-нибудь пишет?

давно

Хватов Сергей

Академик
20764
1861

08.04.2012, 12:11

общий

Адресаты:

Может, кто и сталкивался, только Fedora 8 уже 4 года как не поддерживается. Через месяц уже версия 17 выйдет.
Вы бы обновились.
P.S. У меня самого в одном месте Fedora 10 до сих пор работает. Но если с ней (или с железом) что-нибудь произойдёт - разбираться не буду и установлю свежую. Это будет проще, результат - предсказуемее и в случае проблем будет с кем посоветоваться.

давно

Олег Калашников

Руководитель
2
547

08.04.2012, 12:50

общий

Действительно, заметил в логах, что возникает ошибка:
zend_mm_heap corrupted
После чего пропадают пинги.
Сделал следующее:
1. Увеличил в php.ini значение output_buffering с 4096 до 8192 (нашёл рекомендацию в интернете)
2. Обновил Zend Optimizer с версии 3.3.3 до версии 3.3.9.
Посмотрим, как сейчас будет...

Неизвестный

08.04.2012, 13:50

общий

08.04.2012, 14:12

Адресаты:

Добрый день!
Я не совсем, если честно, понимаю каким образом может апатч, работающий на прикладном уровне (7-м) модели ISO/OSI, или же одноименном в стеке протокола TCP/IP (4-м), как и собственно препроцессор PHP, влиять на работу сети вообще? Есть предположение, что то сообщение, которое вы привели, есть следствие другого сбоя. Для начала, думаю, стоит посмотреть логи messages/kern.log/dmesg по этому поводу. Возможно, что ядро зафиксировало какие-то проблемы с сетью, или с каким-либо модулем.....кстати какой модели у вас сервер? Возможно драйвер сетевой сбоит....припоминаю, что на одном-двух серверах одной модели, из нескольких десятков, была подобная проблема: север один прекрасный момент переставал быть доступен по сети. Зайдя на него через ILO на KVM, можно было увидеть, что с сервером все "в порядке", и в логах ничего необычного нет, и mii-tool и ifconfig, а также и порты каталиста показывают, что порт поднят, и "не дергался". Даже tcpdump фиксирует, что сервер принимает широковещательные arp- и юникастовые icmp-сообщения от маршрутизатора, но в ответ ничего не шлет. Временным решением было перезапустить сеть через /etc/init.d/network restart. Окончательно же вылечилось это по обращению в службу hp, которые посоветовали установить специальный сетевой драйвер для этой модели сервера, который можно было найти на их сайте.
Что касается обновления на более позднюю версию ОС...то считаю, что в этом есть, конечно, смысл, но не факт, что это поможет решить проблемы, если они вызваны аппаратным обеспечением. К примеру, у нас в конторе используется множество серверов с ОС RHEL 3.8, 4.7, несмотря, на то что уже есть 6-я версия. Конечно, есть некоторые неудобства, при эксплуатации данных ОС, но это пока терпимо :)

давно

Олег Калашников

Руководитель
2
547

08.04.2012, 14:06

общий

Цитата: 194436

Я не совсем понимаю каким образом может апатч влиять на работу сети вообще?

Я тоже не совсем понимаю. Но факт остаётся фактом. После рестарта Апача пинги возобновляются...

Я произвёл некоторые действия (см. выше в мини-форуме), послежу пару дней за работой. Если это не поможет, буду думать, что может быть ещё...

давно

Олег Калашников

Руководитель
2
547

08.04.2012, 21:27

общий

Ситуация повторилась. В момент долгих пингов dmesg показал следующее:
TCPv6: Possible SYN flooding on port 80. Sending cookies.

В конфиг /etc/sysctl.conf указал:
net.ipv4.tcp_syncookies=0

Выполнил команду:
echo 0 > /proc/sys/net/ipv4/tcp_syncookies

Перезапустил сервер.
Наблюдаю дальше...

давно

Олег Калашников

Руководитель
2
547

08.04.2012, 22:03

общий

Полазил в интернете и добавил ещё вот такие опции в sysctl.conf:
net.ipv4.tcp_synack_retries = 3
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_fin_timeout=15
net.ipv4.tcp_keepalive_intvl=5
net.ipv4.tcp_keepalive_probes=3
net.ipv4.tcp_mtu_probing=1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack=0
net.ipv4.tcp_max_syn_backlog=1280
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.all.secure_redirects=0
net.ipv4.conf.all.rp_filter=1

давно

Олег Калашников

Руководитель
2
547

08.04.2012, 22:47

общий

И ещё к этому же вопросу.
Никакие изменения конфига не произвели нужного эффекта. Длинные пинги сохраняются.
При этом, выполнив команду tcpdump |grep udp обнаружил кучу вот таких запросов:
----
22:44:24.598980 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
22:44:24.598994 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
22:44:24.599007 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
22:44:24.599020 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
22:44:24.599033 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
22:44:24.599046 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
22:44:24.599059 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
22:44:24.599071 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
22:44:24.599084 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
22:44:24.599096 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
22:44:24.603768 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
22:44:24.603804 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
22:44:24.603819 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
22:44:24.603833 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
22:44:24.603846 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
22:44:24.603859 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
22:44:24.603872 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
22:44:24.603885 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
22:44:24.603897 IP xxx.xxx.xxx.xxx > jd.yurteh.net: udp
---
Возникает вопрос: что бы то значило? И что с этим делать?

давно

Олег Калашников

Руководитель
2
547

08.04.2012, 22:59

общий

Закрыл все исходящие соединения по UDP. Пинги пошли отличные.
Значит, кто-то грузит сеть исходящими UDP-пакетами.
Копаю дальше...

P.S. Пишу для истории, чтобы можно было сформировать ответ.

давно

Олег Калашников

Руководитель
2
547

08.04.2012, 23:09

общий

Исходящие шли по протоколу UDP с 53 порта (DNS). Закрыл его. Всё работает отлично.
Вопрос: чем чревато закрытие исходящих соединеней порта 53 UDP?

давно

Олег Калашников

Руководитель
2
547

08.04.2012, 23:14

общий

это ответ

Здравствуйте, Калашников О.А.!
Проблема заключается в том, что нагружается какой-то порт огромным количеством отправляемых или получаемых пакетов.

В результате анализа ситуации непосредственно на сервере, стало ясно, что отсылается большое количество пакетов по порту 53 UDP.
После закрытия этого порта на исходящие соединения пинги стали стабильные.

Неизвестный

08.04.2012, 23:24

общий

53 udp - это днс сервер, у не патченного bind был эксплоит, который позволял досить.

53 исходящие - если у вас нет днс, который разрешает внешие звпросы, то ни чем. Вы уверены что проблема именно в этом?

У вас стоит memcached или другой мэнеджер сессий?

давно

Хватов Сергей

Академик
20764
1861

08.04.2012, 23:29

общий

Адресаты:

Вообще-то Основной протокол для ДНС как раз udp, а tcp используется только в особых случаях, например при обмене зон, так что закрывать его плохо. Я подробностей протокола не помню, возможно. что без udp он работать и продолжит, только с большими задержками и большим трафиком.
Единственное, что смущает - вы запускали tcpdump с name resolving. Это, случайно, не он сам столько запросов к name-server инициализировал?

Потому как исходящему трафику особо взяться неоткуда. Вряд ли ваш днс позволяет рекурсивные запросы "со стороны"
Надеюсь, в логах apache имена клиентов тоже не резолвятся.

давно

Олег Калашников

Руководитель
2
547

08.04.2012, 23:46

общий

Цитата: 384024

Вы уверены что проблема именно в этом?

Да, уверен. Закрываю 53 порт, пинги тут же пошли нормальные. Открываю - канал забивается исходящими UDP-пакетами на IP 193.23.181.38.
На сервере поднят DNS BIND. Вот я и думаю, безболезненно ли закрывать этот порт?

В данный момент заблокировал IP-адреса 193.23.181.0/24. Всё тихо, всё работает, пинги стабильные.
Но не факт, что с другого адреса возникнет такая же атака.

Цитата: 384024

не патченного bind был эксплоит, который позволял досить

.
На сервере стоит bind 9.5.0-29.P2.fc8.

Цитата: 384024

У вас стоит memcached или другой мэнеджер сессий?

Я не знаю, что такое менеджер сессий. Но memcached точно не установлен.

Я запустил так:
tcpdump |grep udp

Неизвестный

09.04.2012, 11:13

общий

Адресаты:

Добрый день!
Ну вот, уже и появились первые результаты...как я и думал, апатч здесь скорее всего в виде одной из "жертвы", на которую "покушаются" злоумышленники в виде ботнетов.
Как нам всем известно, за счет чего достигается, в первую очередь, эффект атаки DoS на конкретный хост? За счет того, что за очень малый промежуток времени хосту приходит огромное количество пакетов с флагом tcp-syn на открытие tcp-сессии. Если tcp-порт открыт, на который удаленная сторона прислала данные пакет, то система под потенциально новую сессию выделяет определенный блок памяти до определенного timeout'а (tcb помоему называется - гуглить просто лень). В итоге у нас имеет место классическая утечка памяти, и сбой сетевой подсистемы, причем сама ОС остается работоспособной. При DDoS'e же сам эффект достигается за счет того, что злоумышленники "кладут" канал до хоста, забивая его "паразитным трафиком" и не важно открыт тут порт или нет....
На мой взгляд, ваш bind это также одна из "жертв". Посмотрите что покажет команда netstat -natp | grep -i 'syn_' , дабы увидеть на какие сокеты по tcp пытаются соединиться удаленные IP (флаг p в команде выведет процессы, открывшие сокет).
На вашем месте, я бы отключил все не использующиеся сетевые сервисы, смотрящие в глобальную сеть через chkconfig, поскольку это чревато, дальнейшими возможными отказами сервисов на этой машине.

Форма ответа

Отправка постов/ответов доступна только зарегистрированным и подтвержденным пользователям.

Если Вы уже зарегистрированы на Портале - войдите в систему, если Вы еще не регистрировались - пройдите простую процедуру регистрации.