nf_ct_ftp: dropping packet: partial matching of `227 '

DISCUSSION Marcelo Ricardo Leitner 2 participants 2 messages Apr 17, 2016 7 messages not in the archive

Share & tools

A message that is not in the archive (sent off-list or not yet received): [email protected]

Marcelo Ricardo Leitner

author

2016-04-17 02:09 UTC #6 lore raw

Cc'ing netfilter@ too
Thread: https://lists.fedoraproject.org/archives/list/[email protected]/thread/CLNQ6O6OGNEJAFFSNV56KU6P2JAPM5YU/

Em 16-04-2016 10:52, Reindl Harald escreveu:

Quoted 21 lines

Am 15.04.2016 um 10:16 schrieb Reindl Harald:
Quoted 13 lines
Am 14.04.2016 um 23:53 schrieb Marcelo Ricardo Leitner:
Quoted 12 lines
Quoted 6 lines
Quoted 1 line
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.
Quoted 5 lines
Quoted 1 line
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

Quoted 5 lines

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.

So you can still reproduce it? 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.

Unfortunately the pr_debug()s available on that area aren't much helpful for this problem.

And which kernel is this?

Marcelo

A message that is not in the archive (sent off-list or not yet received): [email protected]

Reindl Harald

2016-04-17 08:38 UTC #8 lore raw

Am 17.04.2016 um 04:09 schrieb Marcelo Ricardo Leitner:

Quoted 30 lines

Cc'ing netfilter@ too
Thread:
https://lists.fedoraproject.org/archives/list/kernel-TuqUDEhatI4ANWPb/1PvSj/[email protected]/thread/CLNQ6O6OGNEJAFFSNV56KU6P2JAPM5YU/
Em 16-04-2016 10:52, Reindl Harald escreveu:
Quoted 24 lines
Am 15.04.2016 um 10:16 schrieb Reindl Harald:
Quoted 14 lines
Am 14.04.2016 um 23:53 schrieb Marcelo Ricardo Leitner:
Quoted 13 lines
Quoted 7 lines
Quoted 1 line
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.
Quoted 5 lines
Quoted 1 line
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:

Quoted 7 lines

Quoted 3 lines
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? :-)

Quoted 1 line

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

Quoted 8 lines

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

Quoted 4 lines

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

_______________________________________________
kernel mailing list
[email protected]
http://lists.fedoraproject.org/admin/lists/[email protected]