Am 17.04.2016 um 04:09 schrieb Marcelo Ricardo Leitner:
Cc'ing netfilter@ too
Thread:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject....
Em 16-04-2016 10:52, Reindl Harald escreveu:
>
> Am 15.04.2016 um 10:16 schrieb Reindl Harald:
>> Am 14.04.2016 um 23:53 schrieb Marcelo Ricardo Leitner:
>>>>> Otherwise it won't be able to expect the new connection
>>>>
>>>> sounds reasonable, on the other side the client yesterday had troubles
>>>> to make passive ftp connections with "connection refused" as
far as
>>>> the
>>>> admin was able to tell on the phone
>>>>
>>> It could be that the drop happened and an auxiliary connection was
>>> attempted before the retransmission of the 227 reply, so your firewall
>>> didn't know about it and actively blocked the connection. If it had
>>> silently dropped the new connection request, the client probably would
>>> retransmit the SYN after a bit.
>>>
>>> Now why the cameras are triggering it, good question
>>
>> not the cameras - a ordinary client with filezilla, that one with 227 in
>> his IP address, the cameras blow their images without any problem on the
>> FTP server
>
> maybe i made it not clear enough:
>
> there is no "my firewall" between that is just iptables directly on the
> machine running pure-ftpd and so it's killing outgoing localhost traffic
> - that is very weird
Okay but expected :) because even if conntrack is running on the system
itself that is running the service, it ignores that fact and still acts
like just a man-in-the-middle.
but partial packets on the local system? :-)
So you can still reproduce it?
not in a way that would make it easy to debug, some days are log floods
and that for years now and most time there is nothing - until last week
i thought that would be something to attackers related but then i had a
customer with borken PASV ftp and his IP address 100 times in the log
with that message
If so, I don't see another way to debug
this but to unload nf_conntrack_ftp and take a traffic capture without
limiting the packet size (don't use -s option), because I'm afraid that
otherwise conntrack will drop the packet and we won't even see it in the
capture.
Look for a packet containing a "227 " in the beginning of TCP payload.
That should be our guy.
Feel free to send it only to my email if you prefer.
hmm - if i could reproduce it in a way "i want it now" and somewhere
else than a production server
Unfortunately the pr_debug()s available on that area aren't much
helpful
for this problem.
And which kernel is this?
i have always the latest Fedora kernel running
4.4.7-300.fc23.x86_64