Hi strange behaviour of iptables on a centos 7.0 machine: The following rule is in the iptables of said machine:
[root@myserver ~]# iptables -L -v -n --line-numbers |grep 175. 9 9 456 DROP all -- * * 175.44.0.0/16 0.0.0.0/0 [root@myserver ~]#
The corresponding enty in /etc/sysconfig/iptables looks like:
[root@myserver ~]# grep 175 /etc/sysconfig/iptables -A INPUT -s 175.44.0.0/16 -j DROP [root@myserver ~]#
The rule must be there since ages, because it has number 9 out of 76 similar rules.
Today, on the same machine (I rechecked it to make sure not to confound machines), I see the following extract of the ftplog:
<snip> 175.44.4.127 2915 175.44.26.128 2021 175.44.26.138 1322 175.44.6.186 1290 175.44.24.88 1219 175.44.4.199 1212 </snip>
saying that from this IP addresse there have been this many connections to the ftp server on that machine during the last two days, which means that the iptables haven't dropped the connection to the machine. As far as I know, the ftp server is behind the iptables. I also checked to see in man iptables, wheather the IP address is represented correctly.
What im I missing?
thanks in advance
suomi
On 03/08/2016 08:35 PM, anax wrote:
Hi strange behaviour of iptables on a centos 7.0 machine: The following rule is in the iptables of said machine:
[root@myserver ~]# iptables -L -v -n --line-numbers |grep 175. 9 9 456 DROP all -- * * 175.44.0.0/16 0.0.0.0/0 [root@myserver ~]#
The corresponding enty in /etc/sysconfig/iptables looks like:
[root@myserver ~]# grep 175 /etc/sysconfig/iptables -A INPUT -s 175.44.0.0/16 -j DROP [root@myserver ~]#
The rule must be there since ages, because it has number 9 out of 76 similar rules.
Today, on the same machine (I rechecked it to make sure not to confound machines), I see the following extract of the ftplog:
<snip> 175.44.4.127 2915 175.44.26.128 2021 175.44.26.138 1322 175.44.6.186 1290 175.44.24.88 1219 175.44.4.199 1212 </snip>
saying that from this IP addresse there have been this many connections to the ftp server on that machine during the last two days, which means that the iptables haven't dropped the connection to the machine. As far as I know, the ftp server is behind the iptables. I also checked to see in man iptables, wheather the IP address is represented correctly.
What im I missing?
You mention iptables - but no mention of firewalld - they both use the same kernel mechanism, but it is important that both CANNOT be active! If you configure and use firewalld you can query ># iptables -L and see what is installed, however I have no idea if this exposes the entire set of firewall statements - others that better understand this space, feel free to weigh in. CentOS 7 has firewalld enabled by default, thus the choice to use iptables directly means that firewalld must be disabled. HTH
thanks in advance
suomi _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 03/08/2016 08:50 AM, Rob Kampen wrote:
On 03/08/2016 08:35 PM, anax wrote:
Hi strange behaviour of iptables on a centos 7.0 machine: The following rule is in the iptables of said machine:
[root@myserver ~]# iptables -L -v -n --line-numbers |grep 175. 9 9 456 DROP all -- * * 175.44.0.0/16 0.0.0.0/0 [root@myserver ~]#
The corresponding enty in /etc/sysconfig/iptables looks like:
[root@myserver ~]# grep 175 /etc/sysconfig/iptables -A INPUT -s 175.44.0.0/16 -j DROP [root@myserver ~]#
The rule must be there since ages, because it has number 9 out of 76 similar rules.
Today, on the same machine (I rechecked it to make sure not to confound machines), I see the following extract of the ftplog:
<snip> 175.44.4.127 2915 175.44.26.128 2021 175.44.26.138 1322 175.44.6.186 1290 175.44.24.88 1219 175.44.4.199 1212 </snip>
saying that from this IP addresse there have been this many connections to the ftp server on that machine during the last two days, which means that the iptables haven't dropped the connection to the machine. As far as I know, the ftp server is behind the iptables. I also checked to see in man iptables, wheather the IP address is represented correctly.
What im I missing?
You mention iptables - but no mention of firewalld - they both use the same kernel mechanism, but it is important that both CANNOT be active! If you configure and use firewalld you can query ># iptables -L and see what is installed, however I have no idea if this exposes the entire set of firewall statements - others that better understand this space, feel free to weigh in. CentOS 7 has firewalld enabled by default, thus the choice to use iptables directly means that firewalld must be disabled. HTH
thanks in advance
suomi _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Hi Rob
Thank you for your answer. I did really not consider that with firewalld. But when I check on the server I get:
[root@myserver ~]# systemctl status firewalld firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled) Active: inactive (dead) [root@myserver ~]#
Also if I do:
[root@myserver ~]# ps xa |grep firewall 12235 pts/0 S+ 0:00 grep --color=auto firewall [root@myserver ~]#
so firewalld is really not active.
suomi
On 3/7/2016 11:35 PM, anax wrote:
saying that from this IP addresse there have been this many connections to the ftp server on that machine during the last two days, which means that the iptables haven't dropped the connection to the machine. As far as I know, the ftp server is behind the iptables. I also checked to see in man iptables, wheather the IP address is represented correctly.
which table is that rule in? INPUT, or a table invoked by input? are there rules affecting inbound FTP connections before that rule?
On 03/08/2016 09:13 AM, John R Pierce wrote:
On 3/7/2016 11:35 PM, anax wrote:
saying that from this IP addresse there have been this many connections to the ftp server on that machine during the last two days, which means that the iptables haven't dropped the connection to the machine. As far as I know, the ftp server is behind the iptables. I also checked to see in man iptables, wheather the IP address is represented correctly.
which table is that rule in? INPUT, or a table invoked by input? are there rules affecting inbound FTP connections before that rule?
Hi John
Thanks for your answer.
The complete output of iptables is:
[root@myserver ~]# iptables -L -v -n --line-numbers Chain INPUT (policy ACCEPT 30M packets, 6401M bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT udp -- * * 127.0.0.1 0.0.0.0/0 udp dpt:53 2 11 1133 ACCEPT udp -- * * 192.168.97.0/24 0.0.0.0/0 udp dpt:53 3 254K 17M ACCEPT udp -- * * 212.90.206.128/27 0.0.0.0/0 udp dpt:53 4 40M 2816M udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 recent: SET name: dnslimit side: source mask: 255.255.255.255 5 7717K 549M DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 recent: UPDATE seconds: 10 hit_count: 20 name: dnslimit side: source mask: 255.255.255.255 6 823K 65M udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 STRING match "|0000ff0001|" ALGO name bm FROM 50 TO 65535 recent: SET name: dnsanyquery side: source mask: 255.255.255.255 7 337K 27M DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 STRING match "|0000ff0001|" ALGO name bm FROM 50 TO 65535 recent: CHECK seconds: 10 hit_count: 3 name: dnsanyquery side: source mask: 255.255.255.255 8 0 0 udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 STRING match "|e28098|" ALGO name bm FROM 50 TO 65535 9 9 456 DROP all -- * * 175.44.0.0/16 0.0.0.0/0 10 1059 73305 DROP all -- * * 58.251.0.0/16 0.0.0.0/0 11 1099 77004 DROP all -- * * 74.63.0.0/16 0.0.0.0/0 12 1133 78600 DROP all -- * * 36.248.0.0/16 0.0.0.0/0 13 1130 77455 DROP all -- * * 14.222.0.0/16 0.0.0.0/0 14 1112 76977 DROP all -- * * 113.247.0.0/16 0.0.0.0/0 15 1397 95745 DROP all -- * * 112.90.0.0/16 0.0.0.0/0 16 11137 747K DROP all -- * * 5.39.0.0/16 0.0.0.0/0 17 57 4687 DROP all -- * * 185.29.0.0/16 0.0.0.0/0 18 8861 654K DROP all -- * * 37.59.0.0/16 0.0.0.0/0 19 133 7344 DROP all -- * * 165.228.0.0/16 0.0.0.0/0 20 1104 76908 DROP all -- * * 58.254.0.0/16 0.0.0.0/0 21 1076 75445 DROP all -- * * 99.157.0.0/16 0.0.0.0/0 22 215 14708 DROP all -- * * 201.10.0.0/16 0.0.0.0/0 23 1073 74411 DROP all -- * * 5.34.0.0/16 0.0.0.0/0 24 1124 80611 DROP all -- * * 46.29.0.0/16 0.0.0.0/0 25 1867 123K DROP all -- * * 104.232.0.0/16 0.0.0.0/0 26 113K 15M DROP all -- * * 195.186.1.162 0.0.0.0/0 27 1077 74817 DROP all -- * * 112.111.0.0/16 0.0.0.0/0 28 1091 75748 DROP all -- * * 122.13.0.0/16 0.0.0.0/0 29 51 3528 DROP all -- * * 42.157.0.0/16 0.0.0.0/0 30 1367 87949 DROP all -- * * 78.188.0.0/16 0.0.0.0/0 31 60 3447 DROP all -- * * 218.161.0.0/16 0.0.0.0/0 32 727 83807 DROP all -- * * 218.203.0.0/16 0.0.0.0/0 33 1043 72394 DROP all -- * * 96.250.0.0/16 0.0.0.0/0 34 7332 507K DROP all -- * * 89.163.0.0/16 0.0.0.0/0 35 59 4240 DROP all -- * * 203.101.0.0/16 0.0.0.0/0 36 1063 73252 DROP all -- * * 117.204.0.0/16 0.0.0.0/0 37 1081 74869 DROP all -- * * 114.80.0.0/16 0.0.0.0/0 38 1387 104K DROP all -- * * 14.215.0.0/16 0.0.0.0/0 39 1273 87578 DROP all -- * * 14.152.0.0/16 0.0.0.0/0 40 2823 204K DROP all -- * * 46.105.0.0/16 0.0.0.0/0 41 1088 352K DROP all -- * * 66.85.0.0/16 0.0.0.0/0 42 6108 391K DROP all -- * * 220.181.0.0/16 0.0.0.0/0 43 1253 86598 DROP all -- * * 37.99.0.0/16 0.0.0.0/0 44 1092 75717 DROP all -- * * 88.206.0.0/16 0.0.0.0/0 45 950 66684 DROP all -- * * 62.76.0.0/16 0.0.0.0/0 46 2965 188K DROP all -- * * 109.86.0.0/16 0.0.0.0/0 47 1154 79964 DROP all -- * * 89.236.0.0/16 0.0.0.0/0 48 1107 77559 DROP all -- * * 77.47.0.0/16 0.0.0.0/0 49 2768 161K DROP all -- * * 93.170.0.0/16 0.0.0.0/0 50 1100 76600 DROP all -- * * 94.180.0.0/16 0.0.0.0/0 51 1721 111K DROP all -- * * 61.160.0.0/16 0.0.0.0/0 52 1234 85650 DROP all -- * * 59.38.0.0/16 0.0.0.0/0 53 1060 73687 DROP all -- * * 118.67.0.0/16 0.0.0.0/0 54 1166 82448 DROP all -- * * 119.146.0.0/16 0.0.0.0/0 55 1134 79042 DROP all -- * * 116.25.0.0/16 0.0.0.0/0 56 1045 72968 DROP all -- * * 116.24.0.0/16 0.0.0.0/0 57 1050 73085 DROP all -- * * 116.23.0.0/16 0.0.0.0/0 58 1053 73047 DROP all -- * * 116.22.0.0/16 0.0.0.0/0 59 1106 77294 DROP all -- * * 116.21.0.0/16 0.0.0.0/0 60 1058 73551 DROP all -- * * 116.20.0.0/16 0.0.0.0/0 61 1048 72969 DROP all -- * * 116.19.0.0/16 0.0.0.0/0 62 1066 74472 DROP all -- * * 116.18.0.0/16 0.0.0.0/0 63 1111 76650 DROP all -- * * 116.17.0.0/16 0.0.0.0/0 64 1016 70316 DROP all -- * * 116.16.0.0/16 0.0.0.0/0 65 1171 80275 DROP all -- * * 113.106.0.0/16 0.0.0.0/0 66 945 65996 DROP all -- * * 61.11.0.0/16 0.0.0.0/0 67 1132 78418 DROP all -- * * 112.74.0.0/16 0.0.0.0/0 68 1039 72295 DROP all -- * * 121.26.0.0/16 0.0.0.0/0 69 3714 258K DROP all -- * * 202.78.0.0/16 0.0.0.0/0 70 2 112 DROP all -- * * 219.138.0.0/16 0.0.0.0/0 71 1229 86598 DROP all -- * * 114.246.0.0/16 0.0.0.0/0 72 32 4234 DROP all -- * * 222.98.0.0/16 0.0.0.0/0 73 52 3101 DROP all -- * * 190.103.0.0/16 0.0.0.0/0 74 1926 116K DROP all -- * * 222.186.0.0/16 0.0.0.0/0 75 214 14906 DROP all -- * * 114.66.0.0/16 0.0.0.0/0 76 259 15456 DROP all -- * * 191.252.0.0/16 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 37M packets, 15G bytes) num pkts bytes target prot opt in out source destination 1 3676 300K DROP udp -- * * 0.0.0.0/0 112.90.0.0/16 udp dpt:53 2 1845K 149M DROP udp -- * * 0.0.0.0/0 140.205.0.0/16 udp dpt:53 3 907K 73M DROP udp -- * * 0.0.0.0/0 42.120.0.0/16 udp dpt:53 [root@myserver ~]#
so, the 9th resource record is in the INPUT Chain, as it should be. The first 8 resource records should prevent a DDoS attack to the DNS port. As you can see there are no special resource records to enable FTP connections.
suomi
On 8 Mar 2016 07:36, "anax" anax@ayni.com wrote:
Hi strange behaviour of iptables on a centos 7.0 machine: The following rule is in the iptables of said machine:
[root@myserver ~]# iptables -L -v -n --line-numbers |grep 175. 9 9 456 DROP all -- * * 175.44.0.0/16
0.0.0.0/0
[root@myserver ~]#
The corresponding enty in /etc/sysconfig/iptables looks like:
[root@myserver ~]# grep 175 /etc/sysconfig/iptables -A INPUT -s 175.44.0.0/16 -j DROP [root@myserver ~]#
The rule must be there since ages, because it has number 9 out of 76
similar rules.
Today, on the same machine (I rechecked it to make sure not to confound
machines), I see the following extract of the ftplog:
<snip> 175.44.4.127 2915 175.44.26.128 2021 175.44.26.138 1322 175.44.6.186 1290 175.44.24.88 1219 175.44.4.199 1212 </snip>
saying that from this IP addresse there have been this many connections
to the ftp server on that machine during the last two days, which means that the iptables haven't dropped the connection to the machine. As far as I know, the ftp server is behind the iptables. I also checked to see in man iptables, wheather the IP address is represented correctly.
What im I missing?
Please provide the full iptables listing as a snippet from one section is not useful.
Keep in mind iptables does not go by the most specific entry but rather the first matching rule hit.
If there are any rules prior to this drop that would permit the traffic then of course the traffic would be permitted.
Also 7.0? Please get that system updated asap as you are missing many important (and higher) issues being fixed.
On 03/08/2016 09:43 AM, James Hogarth wrote:
On 8 Mar 2016 07:36, "anax" anax@ayni.com wrote:
Hi strange behaviour of iptables on a centos 7.0 machine: The following rule is in the iptables of said machine:
[root@myserver ~]# iptables -L -v -n --line-numbers |grep 175. 9 9 456 DROP all -- * * 175.44.0.0/16
0.0.0.0/0
[root@myserver ~]#
The corresponding enty in /etc/sysconfig/iptables looks like:
[root@myserver ~]# grep 175 /etc/sysconfig/iptables -A INPUT -s 175.44.0.0/16 -j DROP [root@myserver ~]#
The rule must be there since ages, because it has number 9 out of 76
similar rules.
Today, on the same machine (I rechecked it to make sure not to confound
machines), I see the following extract of the ftplog:
<snip> 175.44.4.127 2915 175.44.26.128 2021 175.44.26.138 1322 175.44.6.186 1290 175.44.24.88 1219 175.44.4.199 1212 </snip>
saying that from this IP addresse there have been this many connections
to the ftp server on that machine during the last two days, which means that the iptables haven't dropped the connection to the machine. As far as I know, the ftp server is behind the iptables. I also checked to see in man iptables, wheather the IP address is represented correctly.
What im I missing?
Please provide the full iptables listing as a snippet from one section is not useful.
Keep in mind iptables does not go by the most specific entry but rather the first matching rule hit.
If there are any rules prior to this drop that would permit the traffic then of course the traffic would be permitted.
Also 7.0? Please get that system updated asap as you are missing many important (and higher) issues being fixed. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Hi James
Thanks very much for your answer.
the full iptables list is in my reply to John.
But you are correct, I must update the system. This may fix the isssue.
suomi
On 03/08/2016 09:43 AM, James Hogarth wrote:
On 8 Mar 2016 07:36, "anax" anax@ayni.com wrote:
Hi strange behaviour of iptables on a centos 7.0 machine: The following rule is in the iptables of said machine:
[root@myserver ~]# iptables -L -v -n --line-numbers |grep 175. 9 9 456 DROP all -- * * 175.44.0.0/16
0.0.0.0/0
[root@myserver ~]#
The corresponding enty in /etc/sysconfig/iptables looks like:
[root@myserver ~]# grep 175 /etc/sysconfig/iptables -A INPUT -s 175.44.0.0/16 -j DROP [root@myserver ~]#
The rule must be there since ages, because it has number 9 out of 76
similar rules.
Today, on the same machine (I rechecked it to make sure not to confound
machines), I see the following extract of the ftplog:
<snip> 175.44.4.127 2915 175.44.26.128 2021 175.44.26.138 1322 175.44.6.186 1290 175.44.24.88 1219 175.44.4.199 1212 </snip>
saying that from this IP addresse there have been this many connections
to the ftp server on that machine during the last two days, which means that the iptables haven't dropped the connection to the machine. As far as I know, the ftp server is behind the iptables. I also checked to see in man iptables, wheather the IP address is represented correctly.
What im I missing?
Please provide the full iptables listing as a snippet from one section is not useful.
Keep in mind iptables does not go by the most specific entry but rather the first matching rule hit.
If there are any rules prior to this drop that would permit the traffic then of course the traffic would be permitted.
Also 7.0? Please get that system updated asap as you are missing many important (and higher) issues being fixed. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Hi James
[root@myserver ~]# cat /etc/centos-release CentOS Linux release 7.2.1511 (Core) [root@myserver ~]#
[root@myserver ~]# uname -a Linux myserver.mydomain.com 3.10.0-327.4.4.el7.x86_64 #1 SMP Tue Jan 5 16:07:00 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [root@myserver ~]#
suomi
On 8 March 2016 at 09:22, anax anax@ayni.com wrote:
On 03/08/2016 09:43 AM, James Hogarth wrote:
On 8 Mar 2016 07:36, "anax" anax@ayni.com wrote:
Hi strange behaviour of iptables on a centos 7.0 machine: The following rule is in the iptables of said machine:
[root@myserver ~]# iptables -L -v -n --line-numbers |grep 175. 9 9 456 DROP all -- * * 175.44.0.0/16
0.0.0.0/0
[root@myserver ~]#
The corresponding enty in /etc/sysconfig/iptables looks like:
[root@myserver ~]# grep 175 /etc/sysconfig/iptables -A INPUT -s 175.44.0.0/16 -j DROP [root@myserver ~]#
The rule must be there since ages, because it has number 9 out of 76
similar rules.
Today, on the same machine (I rechecked it to make sure not to confound
machines), I see the following extract of the ftplog:
<snip> 175.44.4.127 2915 175.44.26.128 2021 175.44.26.138 1322 175.44.6.186 1290 175.44.24.88 1219 175.44.4.199 1212 </snip>
saying that from this IP addresse there have been this many connections
to the ftp server on that machine during the last two days, which means that the iptables haven't dropped the connection to the machine. As far as I know, the ftp server is behind the iptables. I also checked to see in man iptables, wheather the IP address is represented correctly.
What im I missing?
Please provide the full iptables listing as a snippet from one section is not useful.
Keep in mind iptables does not go by the most specific entry but rather the first matching rule hit.
If there are any rules prior to this drop that would permit the traffic then of course the traffic would be permitted.
Also 7.0? Please get that system updated asap as you are missing many important (and higher) issues being fixed. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Hi James
[root@myserver ~]# cat /etc/centos-release CentOS Linux release 7.2.1511 (Core) [root@myserver ~]#
[root@myserver ~]# uname -a Linux myserver.mydomain.com 3.10.0-327.4.4.el7.x86_64 #1 SMP Tue Jan 5 16:07:00 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [root@myserver ~]#
A joyful thing to see ;)
As for your issue itself - the rules seem sound to drop any packets arriving at the server from that /16 network.
Are you sure that the iptables rule was added before the transfer logs you see?
That it didn't happen that someone (or some process) saw abuse of ftp and then inserted the DROP rule afterwards?
Remember position isn't always useful to gauge age of the rule since you can insert anywhere ... and only 9 packets have been matched by that rule in the full output...
On 03/08/2016 10:59 AM, James Hogarth wrote:
On 8 March 2016 at 09:22, anax anax@ayni.com wrote:
On 03/08/2016 09:43 AM, James Hogarth wrote:
On 8 Mar 2016 07:36, "anax" anax@ayni.com wrote:
Hi strange behaviour of iptables on a centos 7.0 machine: The following rule is in the iptables of said machine:
[root@myserver ~]# iptables -L -v -n --line-numbers |grep 175. 9 9 456 DROP all -- * * 175.44.0.0/16
0.0.0.0/0
[root@myserver ~]#
The corresponding enty in /etc/sysconfig/iptables looks like:
[root@myserver ~]# grep 175 /etc/sysconfig/iptables -A INPUT -s 175.44.0.0/16 -j DROP [root@myserver ~]#
The rule must be there since ages, because it has number 9 out of 76
similar rules.
Today, on the same machine (I rechecked it to make sure not to confound
machines), I see the following extract of the ftplog:
<snip> 175.44.4.127 2915 175.44.26.128 2021 175.44.26.138 1322 175.44.6.186 1290 175.44.24.88 1219 175.44.4.199 1212 </snip>
saying that from this IP addresse there have been this many connections
to the ftp server on that machine during the last two days, which means that the iptables haven't dropped the connection to the machine. As far as I know, the ftp server is behind the iptables. I also checked to see in man iptables, wheather the IP address is represented correctly.
What im I missing?
Please provide the full iptables listing as a snippet from one section is not useful.
Keep in mind iptables does not go by the most specific entry but rather the first matching rule hit.
If there are any rules prior to this drop that would permit the traffic then of course the traffic would be permitted.
Also 7.0? Please get that system updated asap as you are missing many important (and higher) issues being fixed. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Hi James
[root@myserver ~]# cat /etc/centos-release CentOS Linux release 7.2.1511 (Core) [root@myserver ~]#
[root@myserver ~]# uname -a Linux myserver.mydomain.com 3.10.0-327.4.4.el7.x86_64 #1 SMP Tue Jan 5 16:07:00 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [root@myserver ~]#
A joyful thing to see ;)
As for your issue itself - the rules seem sound to drop any packets arriving at the server from that /16 network.
Are you sure that the iptables rule was added before the transfer logs you see?
That it didn't happen that someone (or some process) saw abuse of ftp and then inserted the DROP rule afterwards?
Remember position isn't always useful to gauge age of the rule since you can insert anywhere ... and only 9 packets have been matched by that rule in the full output... _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Hi james I am absolutely sure, that the rule in question has been insertet into iptables more than a year ago, because I am (hopefully) the only one with root access to this server. There is no fail2ban on the server, which could have introduced the rule into iptables automatically.
I have written the ruby program to extract the snippet of the ftp-log yesterday and have taken notice of the iptables missbehaviour this morning.
suomi
On 8 March 2016 at 10:13, anax anax@ayni.com wrote:
On 03/08/2016 10:59 AM, James Hogarth wrote:
On 8 March 2016 at 09:22, anax anax@ayni.com wrote:
On 03/08/2016 09:43 AM, James Hogarth wrote:
On 8 Mar 2016 07:36, "anax" anax@ayni.com wrote:
Hi strange behaviour of iptables on a centos 7.0 machine: The following rule is in the iptables of said machine:
[root@myserver ~]# iptables -L -v -n --line-numbers |grep 175. 9 9 456 DROP all -- * * 175.44.0.0/16
0.0.0.0/0
[root@myserver ~]#
The corresponding enty in /etc/sysconfig/iptables looks like:
[root@myserver ~]# grep 175 /etc/sysconfig/iptables -A INPUT -s 175.44.0.0/16 -j DROP [root@myserver ~]#
The rule must be there since ages, because it has number 9 out of 76
similar rules.
Today, on the same machine (I rechecked it to make sure not to confound
machines), I see the following extract of the ftplog:
<snip> 175.44.4.127 2915 175.44.26.128 2021 175.44.26.138 1322 175.44.6.186 1290 175.44.24.88 1219 175.44.4.199 1212 </snip>
saying that from this IP addresse there have been this many connections
to the ftp server on that machine during the last two days, which means
that the iptables haven't dropped the connection to the machine. As far as I know, the ftp server is behind the iptables. I also checked to see in man iptables, wheather the IP address is represented correctly.
What im I missing?
Please provide the full iptables listing as a snippet from one section
is not useful.
Keep in mind iptables does not go by the most specific entry but rather the first matching rule hit.
If there are any rules prior to this drop that would permit the traffic then of course the traffic would be permitted.
Also 7.0? Please get that system updated asap as you are missing many important (and higher) issues being fixed. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Hi James
[root@myserver ~]# cat /etc/centos-release CentOS Linux release 7.2.1511 (Core) [root@myserver ~]#
[root@myserver ~]# uname -a Linux myserver.mydomain.com 3.10.0-327.4.4.el7.x86_64 #1 SMP Tue Jan 5 16:07:00 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [root@myserver ~]#
A joyful thing to see ;)
As for your issue itself - the rules seem sound to drop any packets arriving at the server from that /16 network.
Are you sure that the iptables rule was added before the transfer logs you see?
That it didn't happen that someone (or some process) saw abuse of ftp and then inserted the DROP rule afterwards?
Remember position isn't always useful to gauge age of the rule since you can insert anywhere ... and only 9 packets have been matched by that rule in the full output... _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Hi james I am absolutely sure, that the rule in question has been insertet into iptables more than a year ago, because I am (hopefully) the only one with root access to this server. There is no fail2ban on the server, which could have introduced the rule into iptables automatically.
I have written the ruby program to extract the snippet of the ftp-log yesterday and have taken notice of the iptables missbehaviour this morning.
suomi
Best thing to do then is try and grab a packet capture when this happens ...
But it's clearly something odd otherwise.
-
anax -
James Hogarth -
John R Pierce -
Rob Kampen