Назад | Перейти на главную страницу

Много TIME_WAIT с одного IP-адреса

Я видел много вопросов от людей, обеспокоенных большим количеством TIME_WAIT в netstat. У меня аналогичная проблема, но все TIME_WAIT приходят с одного IP-адреса. Я получаю более 200 следующих строк:

tcp6 0 0 myip: 80 otherip: ##### TIME_WAIT

Является ли получение 200+ таких устройств с одним и тем же IP-адресом для другой поездки плохим признаком чего-то? У меня работает несколько сайтов, но с низким трафиком. Со всеми сайтами я получаю менее 200 посещений в день, зарегистрированных через Google Analytics. Я использую Apache в качестве сервера. У меня была эта проблема и в другое время, исходящая от разных IP-адресов. Когда это происходит, я проверяю netstat в ответ на контрольные проверки, которые я установил с помощью Rackspace. Обычно это предупреждения или критические ошибки, связанные с загрузкой сервера и памятью, а иногда и с длительным временем ответа от моего сервера.

Также было несколько раз, когда MySQL переставал работать, когда это происходило. У меня 1 ГБ ОЗУ плюс 1 ГБ места для подкачки.

Изменить: я немного больше поискал и просмотрел файлы журнала Apache. Я очень обеспокоен сейчас, потому что было множество POST-обращений к wp-login.php для Wordpress (почти 4000 из них), поэтому я предполагаю, что кто-то пытается взломать пароль. Что еще я могу с этим сделать, кроме смены пароля?

Прежде всего, просто хочу уточнить, что TIME_WAIT не имеет ничего общего со стороны ОС, и ответственность за закрытие этих сокетов лежит на приложении.

Обычно сокеты входят в такие состояния, когда данные не принимаются в течение установленного периода времени, а ОС просто не может прервать соединение такого типа без разрешения приложения, поэтому сокет остается открытым в ожидании тайм-аута или ответа от внешних хостов. В вашем случае, например, apache, это обычно происходит, когда клиент запрашивает данные и никогда полностью не закрывает сокет.

Поэтому для дальнейшей отладки этой проблемы запустите

netstat -antulp | grep -i time_wait

Проверьте pid приложения, которое не закрыло сокет.