☰

Экстремальные объемы исходящего порта 80

tag-icon • tag-icon centos iptables
Экстремальные объемы исходящего порта 80

У меня серьезная проблема с моим сервером, который тратит слишком много исходящей пропускной способности впустую. Серверная ОС — CentOS 6.4 x64 с ядром 2.6.32-431, если это имеет значение.

Вот краткий файл журнала tcpdump:

20:10:17.448636 IP 76.200.77.222.broad.pt.fj.dynamic.163data.com.cn.57827 > svgmain.http: Flags [.], ack 463681, win 65520, options [nop,nop,sack 1 {460801:462241}], length 0
20:10:17.448698 IP svgmain.http > 76.200.77.222.broad.pt.fj.dynamic.163data.com.cn.57827: Flags [.], seq 468001:469441, ack 0, win 123, length 1440
20:10:17.454074 IP svgmain.http > 76.200.77.222.broad.pt.fj.dynamic.163data.com.cn.57827: Flags [.], seq 469441:470881, ack 0, win 123, length 1440
20:10:17.637167 IP 76.200.77.222.broad.pt.fj.dynamic.163data.com.cn.57827 > svgmain.http: Flags [.], ack 465121, win 65520, options [nop,nop,sack 1 {466561:468001}], length 0
20:10:17.637221 IP svgmain.http > 76.200.77.222.broad.pt.fj.dynamic.163data.com.cn.57827: Flags [.], seq 470881:472321, ack 0, win 123, length 1440
20:10:17.637230 IP svgmain.http > 76.200.77.222.broad.pt.fj.dynamic.163data.com.cn.57827: Flags [.], seq 472321:475201, ack 0, win 123, length 2880
20:10:17.638062 IP 76.200.77.222.broad.pt.fj.dynamic.163data.com.cn.57827 > svgmain.http: Flags [.], ack 468001, win 65520, length 0
20:10:17.638078 IP svgmain.http > 76.200.77.222.broad.pt.fj.dynamic.163data.com.cn.57827: Flags [.], seq 475201:478081, ack 0, win 123, length 2880
20:10:17.642977 IP 76.200.77.222.broad.pt.fj.dynamic.163data.com.cn.57827 > svgmain.http: Flags [.], ack 470881, win 65520, length 0
20:10:17.642988 IP svgmain.http > 76.200.77.222.broad.pt.fj.dynamic.163data.com.cn.57827: Flags [P.], seq 478081:480961, ack 0, win 123, length 2880

Есть еще тысячи записей, и это съедает 100 ГБ или больше в день. Я пробовал несколько разных правил брандмауэра. Мои правила iptables:

-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -p tcp -m tcp --dport 80 -j fail2ban-HTTP
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -s 198.101.197.171/32 -p tcp -m tcp --dport 3306 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m limit --limit 2/sec --limit-burst 2 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -j DROP
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -o eth0 -p tcp -m tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT
-A fail2ban-HTTP -j RETURN
-A fail2ban-SSH -j RETURN

Я системный администратор-любитель, поэтому не знаю всех тонкостей предотвращения подобных атак.

iftop показывает произвольные IP-адреса, которые меняются в зависимости от получателей данных, nethogs показывает /usr/bin/httpd как процесс, занимающий полосу пропускания. iotop не показывает никакой активности, хотя и сообщает мне, что никакие реальные файлы не читаются.

Мысли?

решение1

Хорошо, у вас есть:

  • большой объем трафика отправляется с вашего HTTP-порта
  • nethogs показывает, что ваш httpd-демон отправляет его
  • IP-адрес назначения — это различные компьютеры в Интернете.
  • iotop ничего не показывает (это значит, что он кэширован в памяти)

Мой диагноз: вы используете веб-сервер.

Проверьте журналы доступа к веб-серверу, чтобы узнать, к чему люди обращаются. Это нормальный трафик? Рассмотрите возможность использования CDN для снижения исходящей пропускной способности.

О, в журналах ничего нет?

  • Вы уверены, что httpd регистрирует события именно там, где вы думаете?
  • Попробуйте остановить httpd, перехватить трафик, затем перезапустить httpd, чтобы вы могли пойматьначинатьзапроса.
  • Если они загружают огромные файлы, журналы могут не появиться, пока загрузка не будет завершена.
  • Используете apache? Попробуйте включить server-statusмодуль, чтобы можно было спросить httpd, что он делает.

Связанный контент