Connection to FTP server often fails using FTP client ruleset [M387] [v6]

Comodo Internet Security - CIS Resolved/Outdated Issues - CIS
21

If you switch off CIS FW and it works it’s not ‘router’ or anything else related.
I think CIS has an issue allowing back the data connection.

Did you use stealth-ports wizard and set it to block all?
Can you try to see if ‘alert for incoming’ makes any difference?

If you set block all can you create a global incoming rule that should allow the traffic.

Allow + Log → TCP → In → Source (IP FTP Server) Source Port Any → Destination Any → Destination port Any.
Based on this the connection should work, or else at least get logged.

Please also set your global ‘block’ rules to ‘Log’ so you might see what else is getting blocked down the road.

22

I have just tried this with Filezilla and Total CMD, works fine if I make a global exception rule allowing FTP source IP port 20 in.

23

When I switch Steal-Ports to alert it doesn’t even ‘alert’ for an incoming connection it just allows tcp 20 → high port in to the FTP programs.

24

@ Ronny: Thanks very much Ronny for clarifications. ?IPv6 issue?

@ LAR: did your global rule allow port 20 inbound? Easy to confuse with port 21 (passive mode port)

25

Here is the Global Rule that I have tried:

Global Rule:

Allow Total Commander FTP Access:

Action: Allow
Protocol:TCP
Direction: In
Description: Allow Active FTP Access

Source Address: Any
Destination Address: Any
Source Port: A Single Port: 20
Destination: Any

26

Did you use stealth-ports wizard and set it to block all? - Yes

Can you try to see if ‘alert for incoming’ makes any difference? - No Difference

Allow + Log → TCP → In → Source (IP FTP Server) Source Port Any → Destination
Any → Destination port Any.

Based on this the connection should work, or else at least get logged. - Doesn’t Work

I’ve attached my logs from the above testing.

[attachment deleted by admin]

27

Your FTP Server seems to switch ports after using port 20 we can clearly see that ‘high ports → high ports’ are dropped from the same FTP address.


2013-05-11 19:39:24  	Windows Operating System  	Blocked  	In  	TCP  	69.49.96.8  	20474  	98.x.y.z  	54168 
2013-05-11 19:38:36  	Windows Operating System  	Blocked  	In  	TCP  	69.49.96.8  	20474  	98.x.y.z  	54168 
2013-05-11 19:38:23  	C:\Program Files\Total Commander\TOTALCMD.EXE  	Allowed  	In  	TCP  	69.49.96.8  	20  	98.x.y.z  	54171

Please try with an Allow + Log IP Source IP ftp ( 69.49.96.8 ) port any destination any dport any.
Please also post a screenshot of the TotalCMD application rule for firewall, that might also block if set to restricted.

28

I tried setting my Global Rule as you described above. It doesn’t work with either of the servers I use (Register.com or RoadRunner). The RoadRunner server let me connect, but I couldn’t upload any files. PASV mode works for both without a problem. I’ve attached my screenshot and recent log.

[attachment deleted by admin]

29

Can you delete the Application rule for TC and let it learn by alert instead of ‘profile’?
I think it’s almost 100% caused by the FTP server switching to highport - highport traffic being blocked by the default profile used on the application.

30

I removed my TC Rule. I tried to connect and allowed TC when prompted by the FW alert. Same problem. Usually it won’t connect, but if it does, I can’t upload any files.

31

Did you give it a ‘template’ allow or just a single allow/remember?

Please try my previous Global rule + the same rule under the application.
Because the server uses more then just source 20 it needs an extra ‘allow’ rule

32

I had given it an Allow/Remember. With your Global Rule and “Allowed Application”, it works. Would this be more secure than just using PASV mode?

33

With your rule in both places (application and global), it works as well.

34

No PASV mode is always better, you don’t have to allow a session incoming that is initiated ‘from’ the FTP server.
With PASV YOU initiate all sessions so no ‘holes’ from outside → inside needed.

35

Thanks, I doesn’t seem a bug to me.
The FTP server should have stayed on source 20 for as far as I know.

If it changed over builds they probably fixed a state issue as the previous builds should not have allowed this in combination with these rules (ftp-client + global block all).

36

Thanks, Ronny! So, would your recommendation be to use PASV mode (to make things easier)? If the security is good, this is what seems to work best in my situation.

37

Yes sorry I misinformed you, what Ronny says is clearly true from a client point of view. My knowledge in this area is limited that’s why I called in help :slight_smile:

What I’m still not understanding here is:
a) why the FTP server is trying to initiate a new data connection (it is a new connection, rright?) at all
b) why two FTP servers are doing so outside what appears to be the FTP standard

A reference on what is supposed to happen: here.

38

Interestingly I have just found that if I enable ‘use mlsd for data connections’ on advanced tab of the specific connection, TC connects to my server in active mode here

39

I would set the security first and then the ‘easier’ part. PASV is more secure seen from a client side.

40

I havemlsd enabled and it still doesn’t connect. Since I only use my FTP server once a week (usually), PASV mode will suffice. I can leave my CIS settings alone and set TC to use PASV mode. It works fine this way. Thanks for telling me about the PASV settings in TC. I’ve never messed with the FTP settings before. This stuff is all new to me.