Я вижу много установленных подключений к моему серверу apache с ip 188.241.114.22, что в конечном итоге приводит к зависанию apache. После перезапуска службы все работает нормально. Я пробовал добавить правило в iptables
-A INPUT -s 188.241.114.22 -j DROP
но, несмотря на это, я продолжаю видеть соединения с этого IP. Я использую CentOS и добавляю правило вроде thie:
iptables -A INPUT -s 188.241.114.22 -j DROP
Сразу после сохранения я использовал: service iptables save
Вот результат iptables -L -v
Chain INPUT (policy ACCEPT 120K packets, 16M bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- any any lg01.mia02.pccwbtn.net anywhere 0 0 DROP all -- any any c-98-210-5-174.hsd1.ca.comcast.net anywhere 0 0 DROP all -- any any c-98-201-5-174.hsd1.tx.comcast.net anywhere 0 0 DROP all -- any any lg01.mia02.pccwbtn.net anywhere 0 0 DROP all -- any any www.dabacus2.com anywhere 0 0 DROP all -- any any 116.255.163.100 anywhere 0 0 DROP all -- any any 94.23.119.11 anywhere 0 0 DROP all -- any any 164.bajanet.mx anywhere 0 0 DROP all -- any any 173-203-71-136.static.cloud-ips.com anywhere 0 0 DROP all -- any any v1.oxygen.ro anywhere 0 0 DROP all -- any any 74.122.177.12 anywhere 0 0 DROP all -- any any 58.83.227.150 anywhere 0 0 DROP all -- any any v1.oxygen.ro anywhere 0 0 DROP all -- any any v1.oxygen.ro anywhere Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 186K packets, 224M bytes) pkts bytes target prot opt in out source destination
Команда iptables -A INPUT добавляет новое правило в конец цепочки INPUT. Iptables работает по принципу первого совпадения, поэтому вполне вероятно, что у вас есть правило, разрешающее доступ к порту 80 ранее в цепочке.
Сохраните состояние ваших iptables с помощью
service iptables save
затем отредактируйте /etc/sysconfig/iptables
файл и переместите -A INPUT -s 188.241.114.22 -j DROP
над линией, разрешающей порт 80. Сохраните файл и запустите
service iptables restart
Как и большинство списков доступа брандмауэра (ACL), записи читаются сверху вниз. Люди, которые плохо знакомы с брандмауэрами с отслеживанием состояния (как на основе хоста, так и на основе сети), часто делают запись, проверяющую список доступа, который применяется для аналогичных правил, которые будут соответствовать тем же критериям, ДО того, как вводится правило. Это часто делается, когда администратор брандмауэра помещает разрешающее правило после запрещающего правила и ему интересно, почему он все еще не может получить соединение с хостом.
Мой совет - проверьте свой список доступа и посмотрите, совпадает ли что-нибудь с вашим утверждением, перед тем, как вы пытаетесь сделать это. Правило отказа, вероятно, должно быть в верхней части списка, поскольку для вас важно заблокировать этот трафик. Просто укажите, какой хост вы хотите заблокировать.
Согласно предоставленной вами информации правило, которое блокирует этот IP-адрес, похоже, существует, и до этого ничего не принимало трафик в более общем смысле (если вы не скопировали только его часть).
Попробуйте также заблокировать ВЫХОД на этот IP:
iptables -I OUTPUT -d <dst-ip> -j DROP
Дайте нам свой iptables -L -v
. Готов поспорить, у вас есть правило, которое принимает подстановочный знак перед вашим новым правилом.
РЕДАКТИРОВАТЬ: Возможные мысли включают в себя то, что эти соединения генерируются из-за компрометации на вашем компьютере или что несколько хостов обращаются к тому же доменному имени, и вы этого не замечаете, потому что (просто дважды проверьте).
Что ж, поскольку с вашим сетевым фильтром это скорее темная проблема (по крайней мере, в вашем объяснении), вы можете использовать ip route, чтобы удалить этот хост: sudo ip route add unreachable 188.241.114.22
. Это также будет более удобным для ЦП, так как таблица маршрутов использует либо хэш, либо дерево для хранения большого количества маршрутов (а не список для продолжения при поступлении пакета).