Hi strange behaviour of iptables on a centos 7.0 machine: The following rule is in the iptables of said machine: [root at 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 at myserver ~]# The corresponding enty in /etc/sysconfig/iptables looks like: [root at myserver ~]# grep 175 /etc/sysconfig/iptables -A INPUT -s 175.44.0.0/16 -j DROP [root at 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 at 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 at myserver ~]# > > The corresponding enty in /etc/sysconfig/iptables looks like: > > [root at myserver ~]# grep 175 /etc/sysconfig/iptables > -A INPUT -s 175.44.0.0/16 -j DROP > [root at 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 at centos.org > https://lists.centos.org/mailman/listinfo/centos
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? -- john r pierce, recycling bits in santa cruz
On 8 Mar 2016 07:36, "anax" <anax at 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 at myserver ~]# iptables -L -v -n --line-numbers |grep 175\. > 9 9 456 DROP all -- * * 175.44.0.0/160.0.0.0/0> [root at myserver ~]# > > The corresponding enty in /etc/sysconfig/iptables looks like: > > [root at myserver ~]# grep 175 /etc/sysconfig/iptables > -A INPUT -s 175.44.0.0/16 -j DROP > [root at myserver ~]# > > The rule must be there since ages, because it has number 9 out of 76similar rules.> > Today, on the same machine (I rechecked it to make sure not to confoundmachines), 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 connectionsto 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 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 at 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 at myserver ~]# >> >> The corresponding enty in /etc/sysconfig/iptables looks like: >> >> [root at myserver ~]# grep 175 /etc/sysconfig/iptables >> -A INPUT -s 175.44.0.0/16 -j DROP >> [root at 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 at centos.org >> https://lists.centos.org/mailman/listinfo/centos > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centosHi Rob Thank you for your answer. I did really not consider that with firewalld. But when I check on the server I get: [root at 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 at myserver ~]# Also if I do: [root at myserver ~]# ps xa |grep firewall 12235 pts/0 S+ 0:00 grep --color=auto firewall [root at myserver ~]# so firewalld is really not active. suomi
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 at 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 at 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 03/08/2016 09:43 AM, James Hogarth wrote:> On 8 Mar 2016 07:36, "anax" <anax at 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 at 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 at myserver ~]# >> >> The corresponding enty in /etc/sysconfig/iptables looks like: >> >> [root at myserver ~]# grep 175 /etc/sysconfig/iptables >> -A INPUT -s 175.44.0.0/16 -j DROP >> [root at 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 at 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 at 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 at 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 at myserver ~]# >> >> The corresponding enty in /etc/sysconfig/iptables looks like: >> >> [root at myserver ~]# grep 175 /etc/sysconfig/iptables >> -A INPUT -s 175.44.0.0/16 -j DROP >> [root at 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 at centos.org > https://lists.centos.org/mailman/listinfo/centos >Hi James [root at myserver ~]# cat /etc/centos-release CentOS Linux release 7.2.1511 (Core) [root at myserver ~]# [root at 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 at myserver ~]# suomi