Что заставляет сервер блокировать доступ в Интернет

я запускаю 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, но вывод подробный и закодированный. Я не знаю, что искать. Есть идеи, что проверить дальше? Я создаю новую виртуальную машину и перейду на нее, но сейчас я действительно хочу выяснить, что ее вызывает. И еще одно .. эта машина три года работает нормально. Я применил все обновления, поэтому сервер актуален.

0
задан 3 July 2019 в 02:13
3 ответа

Я предлагаю протестировать небольшой маршрутизатор SOHO, если вы можете, или удалить DPI из своего маршрутизатора.

Поскольку он работает в локальной сети, а не через глобальную сеть, пожалуйста, знайте, что какой-то корпоративный класс маршрутизатор выполняет DPI, глубокую проверку пакетов и может испытывать трудности при прохождении большого количества трафика.

У меня была аналогичная проблема со старым Cisco ASA и почтовым сервером клиента, который случайно отбрасывал некоторые входящие электронные письма.

Тот факт, что вы перезагружаетесь и проблема исчезает, легко объяснить, поскольку сервер больше ничего не принимает и косвенно выгружает маршрутизатор

1
ответ дан 4 December 2019 в 13:20

Действия по устранению проблемы:

  • Запустите tcpdump и проверьте трафик.

  • Вы видите входящие пакеты TCP-SYN ? Если нет или вы видите входящие TCP-SYN пакеты и повторно отправленные TCP-SYN-ACK - проверьте сетевое устройство перед вашим сервером.

  • Вы видите входящие TCP-SYN пакетов, но не вижу ответов. Проверьте брандмауэр с помощью iptables-save -c . Порядок правил очень важен. Вы используете fail2ban? Также проверьте маршруты с помощью команд ip route get from iif и ip route get from . Он должен отображать допустимые маршруты.

  • Проблема может быть вызвана переполнением таблицы conntrack. Проверьте вывод dmesg и conntrack -S .

  • Проблема может быть вызвана превышением лимита открытых сокетов (обычно это полузакрытые сокеты). Используйте ss и nstat , чтобы проверить это.

  • Внимательно изучите вывод команды nstat -az . В нем перечислено огромное количество показателей и счетчиков ошибок.

  • Увеличьте ведение журнала сервера. Проверьте журналы ошибок. Следующим этапом устранения неполадок является использование инструмента strace для отслеживания выполнения системных вызовов.

1
ответ дан 4 December 2019 в 13:20

Некоторые инструкции по устранению неполадок:

Запустите netstat , чтобы увидеть соединения и процессы, которые связаны с каждым сокетом:

sudo netstat -nlpt

Убедитесь, что процесс соответствует тому, что, по вашему мнению, должно прослушиваться и обслуживаться (Apache)

Проверьте системные ограничения с помощью ulimit, чтобы увидеть, достигнуто ли максимальное количество процессов:

ulimit -a

Попробуйте получить доступ к веб-серверу с localhost (ваш сеанс ssh), используйте wget или curl.

Просмотрите память, процессор и системный журнал. Используйте top для первого и tail -f / var / log / syslog или соответствующей команды в вашей системе. Сделайте это сразу после перезагрузки и при доступе к веб-серверу.

0
ответ дан 4 December 2019 в 13:20

Теги

Похожие вопросы