[CentOS] Strange behaviour of iptables in centos 7

[James Hogarth]

On 8 March 2016 at 10:13, anax <anax at ayni.com> wrote:

>
>
> On 03/08/2016 10:59 AM, James Hogarth wrote:
>
>> On 8 March 2016 at 09:22, anax <anax at ayni.com> wrote:
>>
>>
>>>
>>> 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 ~]#
>>>
>>>
>>>
>>> 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 at 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.