DailyLama wrote:Do you maybe have an detailed explanation of what is exactly going on so I can open a ticket with Kaspersky?
Kaspersky inspects and filters network traffic. For some reason, instead of using a simple filter driver, it opts to transparently redirect all network traffic through avp.exe at 127.0.0.1:1110
Let's say FileZilla does FTP with 93.184.216.34.
This is what normally happens, without a firewall:
- FileZilla establishes the control connection to 93.184.216.23
- Initially no source IP is set, it automatically gets assigned by the operating system. Let's say 10.0.0.123, which is a typical address for users behind a NAT router.
- Once the connection has established, FileZilla knows that it is possible to connect to 93.184.216.23 from 10.0.0.123, as returned by the getpeername() and getsockname() API functions
- To transfer a file or directory listing, a data connection needs to be established. Both source and destination IP of data connection must match the control connection to mitigate the FTP data connection stealing attack.
- FileZilla binds the source IP of the data connection to 10.0.0.123 [1] and connects to 93.184.216.23
This is with Kaspersky firewall running:
- FileZilla wants to establish the control connection to 93.184.216.23.
- Kaspersky redirects the connection to avp.exe on 127.0.0.1:1110 which in turn connects to 93.184.216.23
- This time around the source IP assigned by the operating system is 127.0.0.1
- Even though the connection is clearly redirected to destination IP 127.0.0.1, as can be seen in netstat output, getpeername() still returns 93.184.216.23
- FileZilla now knows that it is possible to connect to 93.184.216.23 from 127.0.0.1, as returned by the getpeername() and getsockname() API functions
- To transfer a file or directory listing, a data connection needs to be established. Both source and destination IP of data connection must match the control connection to mitigate the FTP data connection stealing attack.
- FileZilla binds the source IP of the data connection to 127.0.0.1 and tries to connect to 93.184.216.23
- Due to being the loopback address, no other addresses can be reached from 127.0.0.1, so the result is ENETUNREACH
So far the facts. Here's a bit of conjecture what happens: Even though the traffic is redirected, Kaspersky fakes the result of getpeername() so that the original destination IP is still reported. At the same time though it does not fake the output of the getsockname() API function.
[1] The binding is new since FileZilla 3.11.0-rc1. It is not only a security feature but also a necessary compatibility feature when running on a host implementing
RFC 4931.