Я использую API на сервере. Клиент опрашивает сервер запросами API 8-10 раз в секунду. Я знаю, что это плохая практика, и стараюсь заставить клиента измениться. Но пока что через некоторое время сервер блокирует доступ в интернет. Я не могу видеть за пределами своей внутренней сети и не могу видеть ее из внешнего мира. Он работает, и я могу подключиться по ssh с другого сервера в моей внутренней сети. Я перезапускаю apache, и это не помогает. Это всегда исправляет перезагрузка, поэтому я предполагаю, что это не брандмауэр. Похоже, что-то обнаруживает попытку DDOS-атаки и отключает доступ в Интернет извне.
На сервере работает Centos 7 со всеми последними исправлениями и обновлениями. Я исправляю это правильно, ограничивая доступ к API, но я хочу понять, что происходит внутри. Есть ли утилита, работающая как часть Centos по умолчанию, которая делает это?
Спасибо за понимание. Вот отрывок из моих журналов доступа ... вы видите, что он бьет нас 8 раз в секунду.
xx.73.83.167 - - [25/Jun/2019:13:47:59 -0700] "POST /auth HTTP/1.0" 200 215 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:47:59 -0700] "POST /auth HTTP/1.0" 200 215 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:47:59 -0700] "POST /measurements HTTP/1.0" 200 67 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:47:59 -0700] "POST /measurements HTTP/1.0" 200 67 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:47:59 -0700] "POST /auth HTTP/1.0" 200 215 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:47:59 -0700] "POST /auth HTTP/1.0" 200 215 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:47:59 -0700] "POST /measurements HTTP/1.0" 200 67 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:47:59 -0700] "POST /measurements HTTP/1.0" 200 67 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:48:00 -0700] "POST /auth HTTP/1.0" 200 215 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:48:00 -0700] "POST /auth HTTP/1.0" 200 215 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:48:00 -0700] "POST /pwi HTTP/1.0" 200 165 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:48:00 -0700] "POST /measurements HTTP/1.0" 200 67 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:48:00 -0700] "POST /auth HTTP/1.0" 200 215 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:48:00 -0700] "POST /auth HTTP/1.0" 200 215 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:48:00 -0700] "POST /measurements HTTP/1.0" 200 67 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:48:00 -0700] "POST /measurements HTTP/1.0" 200 67 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:48:00 -0700] "POST /auth HTTP/1.0" 200 215 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:48:01 -0700] "POST /auth HTTP/1.0" 200 215 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:48:01 -0700] "POST /measurements HTTP/1.0" 200 67 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:48:01 -0700] "POST /measurements HTTP/1.0" 200 67 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:48:01 -0700] "POST /auth HTTP/1.0" 200 215 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:48:01 -0700] "POST /auth HTTP/1.0" 200 215 "-" "Java/11.0.3"
xx.73.83.167 - - [25/Jun/2019:13:48:01 -0700] "POST /pwi HTTP/1.0" 200 165 "-" "Java/11.0.3"
Спасибо!
ОБНОВИТЬ:
Это случилось еще трижды. Когда я пытаюсь зайти на сервер с помощью браузера, я получаю сообщение об ошибке «Сервер не найден». Я могу подключиться к серверу через внутреннюю сеть. Все работает. Порты открыты в firewalld. Я перезапускаю apache, без помощи. Перезапускаю firewalld, не помогает. Перезагружаюсь, все исправляется. Какой-то процесс где-то блокирует внешний доступ в Интернет. Я предполагаю, что после перезагрузки это не может быть внешний коммутатор или брандмауэр? Виртуальные машины - это VMware, поэтому они запускают пул сетевых адаптеров, поэтому другие системы также испытали бы это, если бы это была проблема с сетевым адаптером? Какие еще журналы я могу проверить? Кто-то предложил dmesg, но вывод подробный и закодированный. Я не знаю, что искать. Есть идеи, что проверить дальше? Я создаю новую виртуальную машину и перейду на нее, но теперь я действительно хочу выяснить, что ее вызывает. Еще кое-что .. эта машина три года работает нормально. Я применил все обновления, поэтому сервер актуален.
Шаги по устранению проблемы:
Запустить tcpdump и проверьте трафик.
Вы видите входящие TCP-SYN пакеты? Если нет или вы видите входящие TCP-SYN пакетов и повторно отправлено TCP-SYN-ACK - проверьте сетевое устройство перед своим сервером.
Вы видите входящие TCP-SYN пакетов, но не вижу ответов. Проверьте брандмауэр с помощью iptables-save -c. Порядок правил очень важен. Вы используете fail2ban? Также проверьте маршруты с помощью ip route get <server-ip> from <client-ip> iif <iface> и ip route get <dst> from <server-ip> команды. Он должен показывать действительные маршруты.
Проблема может быть вызвана переполнением таблицы conntrack. Проверить вывод dmesg и conntrack -S.
Проблема может быть вызвана превышением лимита открытых сокетов (обычно это полузакрытые сокеты). Использовать ss и nstat чтобы проверить это.
Тщательно исследуйте вывод nstat -az команда. В нем перечислено огромное количество метрик и счетчиков ошибок.
Увеличьте логирование сервера. Проверьте журналы ошибок. Следующим шагом устранения неполадок является использование strace инструмент для отслеживания выполнения системных вызовов.
Я предлагаю протестировать небольшой маршрутизатор SOHO, если вы можете, или удалить DPI со своего маршрутизатора.
Поскольку он работает в локальной сети, а не через глобальную сеть, имейте в виду, что некоторые маршрутизаторы корпоративного класса выполняют DPI, глубокую проверку пакетов и могут испытывать трудности, когда через них проходит большое количество трафика.
У меня была аналогичная проблема со старым Cisco ASA и почтовым сервером клиента, который случайным образом отбрасывал некоторые входящие электронные письма.
Тот факт, что вы перезапускаете и проблема исчезает, легко объяснить, поскольку сервер больше ничего не принимает и косвенно выгружает маршрутизатор.
Некоторые инструкции по устранению неполадок:
Бегать netstat чтобы увидеть соединения и процессы, связанные с каждым сокетом:
sudo netstat -nlpt
Убедитесь, что процесс соответствует тому, что, по вашему мнению, следует слушать и обслуживать (Apache)
Проверьте системные ограничения с помощью ulimit, чтобы узнать, достигнуто ли максимальное количество процессов:
ulimit -a
Попробуйте получить доступ к веб-серверу с localhost (ваш сеанс ssh), используйте wget или завиток.
Проверьте память, процессор и системный журнал. Использовать верхняя для первого и хвостового -f / var / log / syslog или соответствующей команды в вашей системе. Сделайте это сразу после перезагрузки и при доступе к веб-серверу.